Fails to decode meshopt when glTF has external bin file

[lilleyse]

The first tileset (.glb) works, the second tileset (.gltf + .bin) doesn't. Both use meshopt compression. There might be some ordering issue where it tries to decode meshopt before it resolves the external buffers.

box-rotated.zip
box-rotated-json.zip

LogCesium: Loading tileset from URL http://localhost:8070/v1/static/box-rotated-json/tileset.json
LogCesium: Loading tileset from URL http://localhost:8070/v1/static/box-rotated-json/tileset.json done
LogCesium: Warning: [2024-12-09 14:05:35.687] [warning] [ErrorList.h:107] Warning when loading http://localhost:8070/v1/static/box-rotated-json/tiles/0/0/0/0.gltf:
- The EXT_meshopt_compression extension has a bufferView that extends beyond its buffer.
- The EXT_meshopt_compression extension has a bufferView that extends beyond its buffer.
- The EXT_meshopt_compression extension has a bufferView that extends beyond its buffer.
- The EXT_meshopt_compression extension has a bufferView that extends beyond its buffer.
LogCesium: Warning: http://localhost:8070/v1/static/box-rotated-json/tiles/0/0/0/0.gltf mesh 0 primitive 0: Invalid position buffer

Georeferencing coordinates in case it's helpful:

• Latitude: 40.022374
• Longitude: -79.886655
• Height: 300

[kring]

Yeah, your explanation is correct. It looks like the problem is that TilesetContentManager calls loadTileContent, which decodes meshtop but doesn't load external buffers, followed by resolveExternalData, which loads external buffers but doesn't decode meshopt.

It can be fixed by calling GltfReader::postProcessGltf after external buffers are resolved. Or perhaps a little refactoring to avoid the need for a redundant postProcessGltf is in order!