GLTFExporter: Prepare KHR_mesh_quantization support.

[Mugen87]

Related issue: #20474

Description

This PR makes the current restrictions in the exporter mentioned in #20474 (comment) more visible.

[donmccurdy]

Am I correct in understanding that this PR allows some models to be exported with KHR_mesh_quantization, but doesn't fix all of the cases mentioned by #20474 (comment), and so some meshes (that three.js can render, and KHR_mesh_quantization would allow) still won't export?

I'm not sure what you mean about making restrictions more visible. The code changes look OK to me — should we be adding the KHR_mesh_quantization extension automatically when it's needed, as well?

[Mugen87]

Am I correct in understanding that this PR allows some models to be exported with KHR_mesh_quantization, but doesn't fix all of the cases mentioned by #20474 (comment), and so some meshes (that three.js can render, and KHR_mesh_quantization would allow) still won't export?

No models using KHR_mesh_quantization that are imported via GLTFLoader can be exported with GLTFExporter even after this PR.

I'm not sure what you mean about making restrictions more visible.

Right now, the exporter throws an error when Int16Array and Int8Array are used. However, this is not the real problem when KHR_mesh_quantization should be supported.

Functions like isNormalizedNormalAttribute() have to be updated if the normal buffer attribute is already quantized. The routines for decoding existing quantized buffer attributes and encoding un-quantized data will introduce the actual complexity to the exporter in context of KHR_mesh_quantization. I think it's easier to review if these changes go in a separate PR.

[donmccurdy]

Sorry if I'm delaying this, the code in this PR looks fine and I have no objection to it, but I cannot tell what this change is supposed to do.

If the goal it to support KHR_mesh_quantization then perhaps we should wait until #20842 goes in? If you'd rather merge it now, feel free to do so.

[Mugen87]

This can be revisited after #20842. In this way, a merge of this PR will not produce conflicts.

[carstenschwede]

I also encountered this error with a particular model. Since #20842 has been merged in the meantime, is there any hope for KHR_mesh_quantization support?

@donmccurdy can gltf-transform be used to convert models to not utilize mesh quantization?

[donmccurdy]

@carstenschwede could you clarify what error you are seeing, under what conditions? I don't think there are any known problems with three.js loading a model using KHR_mesh_quantization and GLTFLoader, we just can't export them back out with GLTFExporter.

If you did need to remove KHR_mesh_quantization from a model, you could do that with the gltf-transform scripting API. I'll start a thread with what I think the code would be, in donmccurdy/glTF-Transform#233, feel free to comment there if that does or doesn't work for you!

[carstenschwede]

@donmccurdy I also only get the error while exporting, i.e. Error: THREE.GLTFExporter: Unsupported bufferAttribute component type: Int8Array, so removing the mesh quantization from the original model would help me modifying and exporting the model via THREE.js. Thanks a lot for the gltf-transform code, will test ASAP.

Update:
The gltf-transform script in donmccurdy/glTF-Transform#233 can be used to remove KHR_mesh_quantization in case you depend on exporting such models via THREE.js until GLTFExporter is updated. Thanks @donmccurdy!