You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Ensure GLB data is padded to 8-byte alignment so that validation checks pass - #80
In order for data validation checks pass when using 3d-tiles-validator, it is required that the tile bytelength is packed to 8-byte boundary.
In order to do this, we must pad the potentially unbounded gltf file so that the validation check pass.
In the latest discussions it is clarified that padding should be added to the end of the .b3dm tile instead od padding the binary gltf file.
What the spec requires (so the validator stops complaining):
Tile byteLength: must be aligned to 8 bytes.
GLB inside b3dm: must start and end on an 8-byte boundary (relative to the start of the b3dm). This is in addition to glTF’s own 4-byte chunk rules.
JSON sections (Feature/Batch tables): the JSON must end on an 8-byte boundary and is padded with space bytes (0x20).
Binary sections (Feature/Batch tables): must start and end on an 8-byte boundary and are padded with 0x00.
What is done:
Because the b3dm header is 28 bytes (28 ≡ 4 mod 8), the usual trick is:
Feature Table JSON length ≡ 4 mod 8 (e.g., "{}" + 2 spaces → 4 bytes), so that 28 + FTJSON ends on an 8-byte boundary.
All following sections (FT binary, BT JSON, BT binary) end on 8-byte boundaries (pad with 0x00 for binaries, 0x20 for JSON).
That guarantees the GLB starts on an 8-byte boundary.
Additionally ensure the GLB length is a multiple of 8, or pad with 0x20 after the .glb data
The 'children' array should contain at least 1 element checkin:
According to this discussion, the children array should not be empty. Instead, it should not be defined.
Updated TilingStage to create it only if it exists in order to clear the warning in the validator.
Created separate commit so that you can cherry-pick if needed.
Fixed BUFFER_VIEW_TARGET_MISSING warning:
bufferView.target should be set for vertex or index data.
(external) Obj2Gltf converter does not define bufferView.target property for UvAccessor and this creates a warning hint in the validator.
The only suspicious thing here is that the author of ObjConvert commented out this line so it could have some other repercussions.
Having in mind that this is not deal-breaker, and just a hint, i might be ok to skip this commit if you find it suspicious too.
I personally, did not find any issues with the tiles created using this fix
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
In order for data validation checks pass when using 3d-tiles-validator, it is required that the tile bytelength is packed to 8-byte boundary.
In order to do this, we must pad the potentially unbounded gltf file so that the validation check pass.
In the latest discussions it is clarified that padding should be added to the end of the .b3dm tile instead od padding the binary gltf file.
What the spec requires (so the validator stops complaining):
What is done:
That guarantees the GLB starts on an 8-byte boundary.
Additionally ensure the GLB length is a multiple of 8, or pad with 0x20 after the .glb data
this should fix #77 and #46