[Public WebGL] Fixing the OES_texture_float mess

[Mark Callow <callow.mark@artspark.co.jp>]

OES_texture_float and OES_texture_half_float say that some implementations may support rendering to these types. However the rest of the WebGL specification contains requirements that make the FP rendering somewhat less than useful. To whit:

1. Color parameters to blendColor and clearColor are clamped to [0,1].
2. Fragment shader outputs are theoretically clamped to [0,1].

    [I write "theoretically" in #2 because the default OpenGL desktop
    behavior is to only clamp the outputs when the color buffer has a
    fixed-point format. WebGL implementations would have to explicitly
    change OpenGL state to conform with the WebGL/OpenGL ES 2.0 spec's
    and get clamping. I do not know if any actually do this or if there
    is a conformance test for FP rendering that might notice
    non-spec-compliance.]
    
    To fix this I propose to create two new extensions: EXT_color_buffer_half_float
    and WEBGL_color_buffer_float
    which modify the spec. language appropriately. These are now in the
    registry.
    
    Why are there 2 extensions? color_buffer_float functionality does
    not exist on mobile devices which is why there is no OES or EXT
    extension. Desktop does not require RGB16F to be color renderable
    but that format is part of EXT_color_buffer_half_float which is
    available on some mobile devices. Having 2 extensions allows
    implementations to advertise extensions appropriate to the hardware
    they are running on.
    
    Why different suffices? half_float mirrors an existing OpenGL ES
    extension. float is unique to WebGL. 
    
    These extensions require the implementation to also support
    OES_texture_half_float and OES_texture_float respectively.

How to fix texture{_half}_float? I propose to modify the extensions to say that when FP rendering is supported the matching color_buffer extension must be enabled when the texture extension is enabled. This is solely to avoid breaking existing applications. If not for this, I would remove mention of FP rendering.

Other issues:

• both extensions add the same query for the framebuffer attachment component type. I do not think this causes any problems. If an implementation appears that supports both extensions, the query can be used from either or both.
• When the extensions are enabled the behavior of BlendColor and ClearColor are altered as is the clamping behavior of the fragment shader. Only applications actually doing FP rendering will notice the changes and they will want the changes so I do not believe this will be a problem. Even with the extensions enabled, the behavior for fixed-point color buffers will not change. Therefore it seems unnecessary to add new BlendColor and ClearColor commands to the extension objects.
• WEBGL_color_buffer_float is currently written as mirroring OpenGL ES EXT_color_buffer_half_float with changes to drop the 16F types and introduce 32F types. I have decided that this use of mirroring is not appropriate and have prepared a version that instead says it is written against the WebGL EXT_color_buffer_half_float. Once I incorporate changes resulting from comments to this mail, I will submit this revised version for promotion to draft status.
  

    Feedback please.

Regards

    -Mark

--

注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情報の使用を固く禁じております。エラー、手違いでこのメールを受け取られましたら削除を行い配信者にご連絡をお願いいたし ます.

NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies.