b3dmToGlb leaves ending padding bytes in glb file about 3d-tiles-tools HOT 2 CLOSED

Until recently, the b3dmToGlb command did extract the GLB data from the B3DM, and (always) upgraded it with gltf-pipeline. In version 0.3.0 this was changed: The goal was to make sure that the b3dmToGlb function really extracts the true data, as-it-is.

But... yes, "as-it-is" currently means that it does include the padding bytes. And this may not be the smartest thing to do. I can not imagine a reason why someone would want these bytes in a GLB file. They are not part of the GLB itself. They are only required for the validity of the B3DM. But tools that only want the GLB data might choke on these unnecessary bytes.

This was already fixed in the 3d-tiles-validator, via CesiumGS/3d-tiles-validator#258 (with a stripPadding function). But the 3d-tiles-tools still extract that whole data.

I'm a bit on the fence about where exactly the padding bytes should be omitted. Reading B3DM data into a TileData object can be done like this:

    const tileData = TileFormats.readTileData(b3dmBuffer);
    const glbBuffer = tileData.payload;

This glbBuffer then is the GLB buffer, including the padding. And I think that it should still contain the padding, because ... that's what it is. But for the command-line functions that write GLB data to files, the padding bytes should definitely be omitted before writing the files. So there should probably be a "public" convenience function like that stripPadding from the validator, which is called before writing the actual file data.

I'll address that in a PR soon (including some other, minor issues).

from 3d-tiles-tools.

This might now already be fixed with #83 . The "roundtrip" of GLB->B3DM->GLB should now result in a GLB file without the padding bytes.

from 3d-tiles-tools.