Option to avoid using InterleavedBufferAttribute?

[Ben-Mack]

I'm integrating Meshopt into our Three.js app and stucked because my app use three-mesh-bvh which doesn't support InterleavedBufferAttribute.
Its readme stated:

InterleavedBufferAttributes are not supported on the geometry index or position attributes

Is there an easy way to tell gltfpack to not using InterleavedBufferAttribute? It would be great if gltfpack has an option for it.
It'll surely helps with other's code compatibility (afaik InterleavedBufferAttribute is not commonly used, so not much code supports it out of the box).

[Ben-Mack]

Related: gkjohnson/three-mesh-bvh#147

[zeux]

So gltfpack technically doesn't control this, as it doesn't have the concept of InterleavedBufferAttribute. However, due to glTF packing rules it by default packs the position array with a stride = 8 bytes with 6 bytes per component, which three.js GLTFLoader represents as InterleavedBufferAttribute. I've opened a thread around this design issue some time ago since the presence of multiple buffer types creates problems like this, but it won't be solved in the short time frame.

My general recommendation would be to change libraries in the ecosystem to support this. Sounds like there's already an issue for that in three-mesh-bvh.

One other workaround that you can apply is to convert the BufferAttribute for position data from Interleaved to non-interleaved after loading the geometry but before handing it off to three-mesh-bvh. It should be straightforward - just create a new object with the same length and copy the data over before handing it off.

Finally, I plan to implement a "conservative quantization" mode in gltfpack that doesn't use additional transformation matrices and as a consequence it wouldn't use InterleavedBufferAttribute objects. It would result in larger files, but sometimes it's an okay tradeoff to work around compat issues like that. When that gets added, a separate command line flag would be able to fix this problem as well, even though it's not the optimal solution.

[zeux]

Since conservative quantization is tracked separately offline and isn't very high on the priority list right now (... and doesn't obviously follow from this issue), I'm going to close this for now. My recommendation is still to implement full BufferAttribute support when possible and convert attribute data in user space otherwise. This can also be improved in the future depending on where mrdoob/three.js#17089 goes.

[jteppinette]

One other workaround that you can apply is to convert the BufferAttribute for position data from Interleaved to non-interleaved after loading the geometry but before handing it off to three-mesh-bvh. It should be straightforward - just create a new object with the same length and copy the data over before handing it off.

I have attempted to implement this work around. I was able to successfully convert each attribute from an InterleavedBufferAttribute to BufferAttribute that was able to be rendered properly. However, when running analysis on these geometries (bounding box/sphere or three-bvh-csg), the computations are incorrect. I determined that this was due to the quantization step as I was able to work around this by using the -noq flag in gltfpack.

Is it possible to "unquantize" the position/normal information in BufferAttribute?