[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Public WebGL] Fixing the OES_texture_float mess
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:
- Color parameters to blendColor and clearColor are clamped to
[0,1].
- 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.