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

[Public WebGL] Proposal for WEBGL_render_to_float



I have proposed a more restricted extension for supporting render-to-float functionality:
https://github.com/KhronosGroup/WebGL/pull/867

From the pull request:
---
This might be a more portable way to allow render-to-float behavior in WebGL. It's more restricted than WEBGL_color_buffer_float or EXT_color_buffer_half_float. It's implementable everywhere that supports render-to-float, including D3D9.

BLEND with floating-point is disallowed because of lack of support. EXT_color_buffer_float does not allow blending with float32s, and D3D9 only supports normalized uint8 glBlendColor-equivalent.

clear() is disallowed because many implementations clamp clearColor, (driver bugs) and/or limit clearColor to normalized uint8 values. (D3D9. Notably, 0.5f is not representable in normalized uint8) WebGL implementations can work around this by doing a full-screen blit, but this is much more expensive, and current best-practice is to no longer hide performance caveats.

For textures, the initial contents can be set at upload-time. If there is strong support for floating-point clears on drivers that can't support the full WEBGL_color_buffer_float/EXT_color_buffer_half_float extensions, we can add an extension just for floating-point clears. (similar in nature to OES_texture_float_linear)

We could split this into WEBGL_render_to_float and WEBGL_render_to_half_float, but we should only do so if there are platforms or configurations which require this differentiation. (That is, FLOAT and HALF_FLOAT_OES textures are supported, but only one of the two is renderable)
---

This should be able to address the concerns about supporting render-to-float without meeting the requirements of the actual render-to-float extensions.