The 3d-tiles-validator complained about the total length of my i3dm tiles not being aligned to 8 bytes. I’m using URIs instead of binary glTF, so I added spaces to the URI until the requirement was fulfilled. But then the 3d-tiles-validator complains about not finding the URI instead, with this message for example: “Could not resolve GLB URI …/kapok3.glb from I3DM” (note the padded spaces).
Doesn’t the 3d-tiles-validator comply with the last section of this sentence from the i3dm format description?
“Otherwise, if the glTF field is a UTF-8 string, it shall be padded with trailing Space characters (0x20) to satisfy alignment requirements of the tile, which shall be removed at runtime before requesting the glTF asset.”
I don’t know yet if my i3dm files are accepted by Cesium due to other problems. But it would be nice to know if the validator finds other issues or stops at this.
Quick update: I found that padding the URI with char(0) instead of spaces works better, then 3d-tiles-validator stops complaining. Not consistent with the documentation though. Remains to see what Cesium says when I get the other stuff working…
You are right: The validator currently only handled the case that the URI was padded with
0x00 (zero) characters. But it did not handle the case of padding it with
0x20 (space) characters.
This is tracked at Validator fails to resolve GLB from I3DM with URI with spaces · Issue #276 · CesiumGS/3d-tiles-validator · GitHub
A PR for fixing it is at Handle URI with spaces in I3DM by javagl · Pull Request #277 · CesiumGS/3d-tiles-validator · GitHub
The point that you brought up in the ‘Quick update’ has to be sorted out. The current state of the linked PR would allow both,
0x20 as the padding. But according to the specification, the padding must consist of
0x20 (space) characters. So I think that padding the URI with
0x00 should cause a validation error.
(The reason why I’m hesitating and waiting for a confirmation here is roughly: People might already be padding with
0x00, either because buffers in tile data usually can be padded with
0x00, or (worse) because they tried to work around the invalid validator error message. These assets would then suddenly become invalid. Maybe it will only become a ‘WARNING’, to reduce the churn here…)
Thanks, good to have that confirmed. I agree that an error for 0x00 would be too much, a warning or maybe even an info would be better.
Just to close the loop here: The issue in the validator has been fixed via Handle URI with spaces in I3DM by javagl · Pull Request #277 · CesiumGS/3d-tiles-validator · GitHub and will be part of the next release.
Thanks Marco, good to hear!