Clarifications for GLB padding and alignment

[javagl]

The "Padding" section for B3DM and I3DM contained the statement

The binary glTF must start and end on an 8-byte boundary so that glTF's byte-alignment guarantees are met. This can be done by padding the Feature Table or Batch Table if they are present.

It was not perfectly clear how to ensure that the GLB data ends at an 8-byte boundary (on a low technical level - i.e. where to include which padding bytes, and how to handle them).

As an attempt to clarify that, the paragraph could be written as

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.

[lilleyse]

Thanks @javagl, this clarification makes sense to me.