The alignment requirements for the glTF data that is embedded in tile data, as it is currently described for B3DM (and similarly for I3DM) states
The binary glTF shall start and end on an 8-byte boundary so that glTF’s byte-alignment guarantees are met. The proper alignment for the start of the binary glTF data can be achieved by padding the Feature Table, or by padding the Batch Table if it is present. The alignment for the end of the binary glTF data can be achieved by padding the tile data with 0-bytes. The actual binary glTF data does not include possible trailing padding bytes. Clients must take into account the length from the binary glTF header, and use this length to determine the part of the tile data that actually represents the binary glTF.
This already had been clarified, to some extent, via https://github.com/CesiumGS/3d-tiles/pull/729 . But the statement that ... "the binary glTF shall start and end on an 8-byte boundary" still caused confusion. (It was at least confusing - one could argue that it was 'wrong'...). The point is: The binary glTF data does not end at an 8-byte boundary. It ends wherever it ends. Any padding bytes that have to be inserted (to achieve the byteLength%8==0 requirement) do not belong to the binary glTF, but only to the tile data. (This is what the second part of that paragraph elaborates).
This PR updates that paragraph (for B3DM and I3DM): It removes the "and end" part
The binary glTF shall start and end on an 8-byte boundary ...
And changes the statement
The alignment for the end of the binary glTF data ...
to
The alignment for the byteLength of the tile ...
(because this is what the alignment requirement refers to - it does not refer to the binary glTF data)
lilleyse
commented
3 months ago
The alignment requirements for the glTF data that is embedded in tile data, as it is currently described for B3DM (and similarly for I3DM) states
This already had been clarified, to some extent, via https://github.com/CesiumGS/3d-tiles/pull/729 . But the statement that ... "the binary glTF shall start and end on an 8-byte boundary" still caused confusion. (It was at least confusing - one could argue that it was 'wrong'...). The point is: The binary glTF data does not end at an 8-byte boundary. It ends wherever it ends. Any padding bytes that have to be inserted (to achieve the
byteLength%8==0requirement) do not belong to the binary glTF, but only to the tile data. (This is what the second part of that paragraph elaborates).This PR updates that paragraph (for B3DM and I3DM): It removes the "and end" part
And changes the statement
to
(because this is what the alignment requirement refers to - it does not refer to the binary glTF data)