[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Proposal for WEBGL_render_to_float



Jeff, thanks for putting together this extension proposal and
uncovering more of the underlying issues.

It does seem to me that the number of extensions defining
floating-point texture behavior in WebGL is getting out of hand, and
that the limitations imposed by this proposal are too harsh. Let's
discuss it in a higher-bandwidth format on the next working group
conference call (tomorrow).

The discovery that
https://www.khronos.org/registry/gles/extensions/EXT/EXT_color_buffer_float.txt
forbids blending when any of the color buffers are fp32 is correct,
and surprising. Since
https://www.khronos.org/registry/gles/extensions/EXT/EXT_color_buffer_half_float.txt
doesn't impose this restriction I would like to understand why that
restriction is present, and whether it can be lifted.

-Ken



On Wed, Feb 18, 2015 at 2:31 PM, Florian Bösch <pyalot@gmail.com> wrote:
> On Wed, Feb 18, 2015 at 3:15 PM, Florian Bösch <pyalot@gmail.com> wrote:
>>
>> I'd like to add that I strongly disapprove of the mess this is getting,
>> and I'd like to suggest that adding more and more extensions to cover float
>> this-or-that seems like a bad thing to do. How about an extension to end all
>> float extensions, that contains an interface that lets one query every
>> imaginable aspect related to floating point textures?
>
>
> I'd like to elaborate a bit on that point.
>
> So far we have no less than 7 extensions that deal with floating point
> textures:
>
> - OES_texture_float
> - OES_texture_half_float
> - OES_texture_float_linear
> - OES_texture_half_float_linear
> - EXT_color_buffer_half_float
> - WEBGL_color_buffer_float
> - EXT_color_buffer_float (fair bit of overlap with the former two, except
> blending)
>
> And now the suggestion is to add 2 more (bringing it to 9):
>
> - WEBGL_render_to_half_float
> - WEBGL_render_to_float
>
> But because these don't cover clearing we're talking about adding 2 more
> (for a total of 11)
>
> - WEBGL_clear_half_float
> - WEBGL_clear_float
>
> Of course these don't cover blending, which may further differentiate into
> blendFunc and blendColor, so we'd be adding 4 more (for a total of 15)
>
> - WEBGL_blend_func_half_float
> - WEBGL_blend_func_float
> - WEBGL_blend_color_half_float
> - WEBGL_blend_color_float
>
> I suppose there could be further implementation differences requiring even
> more extensions.
>
> I think this is a problem for several reasons:
>
> 1) It makes handling floating point textures messy for users because some of
> these extensions overlap in functionality, others, in some circumstances
> implicitely enable each other, etc.
> 2) It makes handling floating point textures messy for implementors because
> following the rules imposed by multiply-overlapping-implicitely-enabling
> extensions on the implementation behavior becomes quite the exercise.
>
> I believe it would be better to have one extension, that covers everything
> related to floating point textures and offers its own interface to deal with
> them. It would offer:
>
> - All the floating point enumerants
> - Flags indicating a capability (such as extension.float32.blendable)
> - If that's desired it could offer float-versions of functions such as
> clear, blendFunc, blendColor, readPixels, etc.
>

-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------