-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
KHR_mesh_quantization feedback #1794
Comments
For 1, the extension is specified explicitly to only include the WebGL1 baseline and only including formats that are universally supported by native APIs as well. So it's a lowest common denominator if you will. We discussed some formats you mention, for example 10_10_10_2 is really interesting for normal encoding. However it's unclear how to implement this for WebGL1 decoders. For 2, see #1702 (specifically filter specification). The intention there is to save transmission size but decode the data at runtime; there are other ways to specify this to keep the data compressed in GPU/CPU memory but that is more complex for decoders to handle, requiring extra shader permutations to deal with various encoding combinations, e.g. normal/tangent. There are additional complications with tangent encoding. For example, it's tempting to standardize 2-component octahedral encoding for normals (note - it's crucial to not just reconstruct .z, two components + index are a reasonable idea but it's not as easy to decode on the GPU and it's not as efficient in terms of precision/bit), however tangents need an extra bit, and glTF has a 4-byte alignment requirement for attributes - so how to precisely encode normals & tangents in separate attributes without wasting too much space isn't clear. So, my perspective is that the extension is in the right place - it's easy for loaders to implement, and doesn't require special GPU support. I don't think we should conflate different representations of various attributes with that, and I don't see a good way to allow extra types such as 10_10_10_2 without requiring all existing JS loaders to implement a software decode fallback for WebGL1 (which is still the dominant API on the Web AFAIK?). |
Thanks, both rationales make sense! Not sure if glTF extensions process collects Questions&Resolves like GL/GLES extensions do, if it does, might be good material to cover there(?) |
There are other interesting vertex attribute types that GPUs support built-in:
GPUs can readily decode these where available. Should some of these vertex attribute formats also be made available for this extension?
A very good treatise to this scheme for quaternions is presented by Stephen McAuley at GDC 2015, 6:24 into the video.
Example code in
https://github.com/r-lyeh-archived/quant/blob/bad7fe2958a1304952d1677c7599c460da7c1c18/quant.hpp#L287
Should the spec include support for some of these kind of packings?
The text was updated successfully, but these errors were encountered: