WebGL OES_texture_float extension and framebuffers

[Agost Biro]

Hello,

I am working on a demo that targets the latest stable desktop Chrome and Firefox releases and could greatly benefit from rendering to floating point color buffers. While the WEBGL_color_buffer_float extension is not available in said browsers, I confirmed that after enabling the OES_texture_float extension, I can attach a floating point texture as a color buffer and output floating point values from the fragment shader to a color buffer without clamping them. However, the specification of the OES_texture_float extension is rather ambiguous and I would like to know if I can rely on the described functionality. Specifically, my questions are the following:

1. In theory, does an implementation have to support the WEBGL_color_buffer_float extension to implicitly enable it?

2. If I can successfully attach a floating point texture as a color buffer, can I expect the implementation to conform to the WEBGL_color_buffer_float specification, even if a call to 'gl.getExtension('WEBGL_color_buffer_float')' returns null?

3. The specifications says at one point that "new implementations should not implicitly support float rendering and applications should be modified to explicitly enable WEBGL_color_buffer_float". Should I expect Chrome and Firefox to change their current behaviour to conform to this rule?

Thanks in advance.

Best regards,

Agost Biro

[Mark Callow]

On Jan 15, 2015, at 11:22 AM, Agost Biro <agos...@gmail.com> wrote:

Hello,

I am working on a demo that targets the latest stable desktop Chrome and Firefox releases and could greatly benefit from rendering to floating point color buffers. While the WEBGL_color_buffer_float extension is not available in said browsers, I confirmed that after enabling the OES_texture_float extension, I can attach a floating point texture as a color buffer and output floating point values from the fragment shader to a color buffer without clamping them. However, the specification of the OES_texture_float extension is rather ambiguous ...

Yes it is. The native OES_texture_float extension that it is mirroring does not support floating-point rendering so neither should the WebGL version. However the initial implementations on desktop accidentally allowed it, because they failed to disable this standard desktop feature.

Specifically, my questions are the following:

1. In theory, does an implementation have to support the WEBGL_color_buffer_float extension to implicitly enable it?

Yes.

2. If I can successfully attach a floating point texture as a color buffer, can I expect the implementation to conform to the WEBGL_color_buffer_float specification, even if a call to 'gl.getExtension('WEBGL_color_buffer_float')' returns null?

I think this is a safe assumption for all current implementations of OES_texture_float. Many of the early ones that accidentally allowed float rendering clamped the fragment shader outputs and clear colors but I think they’re all fixed now.

3. The specifications says at one point that "new implementations should not implicitly support float rendering and applications should be modified to explicitly enable WEBGL_color_buffer_float". Should I expect Chrome and Firefox to change their current behaviour to conform to this rule?

I believe Firefox is, or has just finished, implementing WEBGL_color_buffer_float and EXT_color_buffer_half_float. I defer to them to answer your question about implicit support. Chrome has stated they have issues with the extensions and don’t plan to implement them, so they will continue with implicit support.

I suggest that applications attempt to enable WEBGL_color_buffer_float. If that fails, enable OES_texture_float and, if successful, attach a floating point texture to an FBO and check for frame buffer completeness. This sequence should work on any implementation to determine if float rendering can be used.

Regards

    -Mark

[Agost Biro]

Thank you!

Agost

[Mark Callow]

On Jan 19, 2015, at 12:31 PM, Mark Callow <khr...@callow.im> wrote:

…

It looks like Google Groups is doing something to the message that invalidates the PGP signature. This is the first time I have sent a signed message to a Google group so I do not know what the problem is. For now, please ignore the invalid signature.

Regards

    -Mark