Malformed GLTF data in Cesium OSM Buildings?

Cesium ion
1

Hi there,

I am testing QGIS implementation of 3D Tiles and opening OSM buildings dataset triggers some errors about malformed GLTF data:

“BIN Chunk end does not aligned to a 4-byte boundary.”

This happens for example in these tiles:

“Insufficient storage space for Chunk1(BIN data). At least Chunk1 Must have 4 or more bytes, but got 0.”

This happens here: https://assets.ion.cesium.com/asset_depot/96188/OpenStreetMap/2023-01-02/root.b3dm?v=16

These errors are reported from the underlying tinygltf library which fails to load those tiles. The errors seem valid, at least the first one also gets picked by an independent implementation (https://gltf-viewer.donmccurdy.com/).

Is tinygltf being too picky, or should the OSM Buildings dataset get fixed?

2

Hi,

Can you please show the errors you are seeing in the console. Also to gather more information, what is your use case to load Cesium OSM buildings in QGIS? The OSM dataset is a 3d tiles dataset so are you trying to convert that to a gltf?

Thanks,
Ankit

3

Hi Ankit

For more context - I am one of the developers working on bringing 3D Tiles to QGIS, thanks to a grant from Cesium (Cesium Announces First Ecosystem Grant Recipients – Cesium). I do not have any specific use case for Cesium OSM buildings dataset, other than making sure it works fine when users try to load it in QGIS. I am not trying to convert the dataset to gltf - the 3D Tiles dataset references b3dm/gltf files which the QGIS client tries to open, but fails in some cases.

The errors I am getting (the double quoted text in my first post) are coming from tinygltf library which is used to load 3D Tiles content in QGIS.

4

Hi,

Thank you for the detailed reporting. At first glance, it does seem like it may be an issue, I have asked the team to take a look at this for you.

Thanks,
Ankit

5

Hi Martin,

The first errors look to be valid - Cesium OSM Buildings is violating the spec here. Though there’s also no technical reason (to my knowledge) that the binary buffer must end with proper alignment when no other data follows it. Which I guess is why other clients currently load this without any trouble and we didn’t notice the spec violation.

The root.b3dm is a little more subtle. It’s intentional that this tile have no content. The spec says (in section 4.4.3.3):

When the binary buffer is empty or when it is stored by other means, this chunk SHOULD be omitted.

That’s not a “must”, so it’s allowed (though discouraged) and if tinygltf is flagging it as an error then it is technically in the wrong here.

I’ll try to get these all cleaned up for the next Cesium OSM Buildings update, but it may be a little while yet. If there’s an easy way in the meantime to make the glTF parser tolerant of these kinds of problems, I’d recommend doing that. It’s a tricky issue, with advantages and disadvantages on both sides, but in general I think visualization clients should do their reasonable best to work with the data they’re given, even if it technically contains spec violations. They shouldn’t act as validators, because most users are using data created by someone else and have no ability to fix it.

6

Thanks for the detailed reply, Kevin!

The tinygltf library author is quite receptive to PRs, so it may be possible to get this fixed on the client side - I just wasn’t sure if you were aware of that…