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

[Public WebGL] Additional texture/vertex formats

I'm not sure if the following extensions are desirable (mainly a more compact form to store floating point data).

- OES_texture_half_float (717 of 948 mobile devices, 88% of desktops). 2 bytes per channel: http://www.khronos.org/registry/gles/extensions/OES/OES_texture_float.txt
- OES_vertex_half_float (783 of 948 mobile devices, 79% of desktops) 2 bytes per element: http://www.khronos.org/registry/gles/extensions/OES/OES_vertex_half_float.txt
- OES_vertex_type_10_10_10_2 (404 of 948 mobile devices, 46% of desktops) 4 bytes per attribute 3 element attribute: http://www.khronos.org/registry/gles/extensions/OES/OES_vertex_type_10_10_10_2.txt
- EXT_texture_type_2_10_10_10_REV (404 of 948 mobile devices, 24% of desktops) 1 byte per channel: http://www.khronos.org/registry/gles/extensions/EXT/EXT_texture_type_2_10_10_10_REV.txt

Caveats I see with these formats:
- 2_10_10_10 is not renderable (cannot be attached to an FBO) which reduces its usefulness somewhat
- we do not have half-float compatible array buffers, so the data cannot be handled in JS (other than handing it trough)
- It is unclear if half float textures can be rendertargets
- we do not have 2_10_10_10 array buffers, so the data cannot be handled in JS (other than handing it trough)
- 2_10_10_10 data formats cannot be transferred as JPEG or compressed PNG in the case of textures or as JSON in the case of vertices since it relies on non byte-aligned bit precise data, and parsing an image or JSON would invariably introduce issues with that.

Let me know what you think.