cesium-ion-rest-api-examples icon indicating copy to clipboard operation
cesium-ion-rest-api-examples copied to clipboard

Example model from REST tutorial seems to contain invalid glTF without compression

Open javagl opened this issue 5 years ago • 1 comments

This is a very specific issue, to be treated with low priority. Also, I'm currently still in the process of exploring and experimenting, so the error might be on my side - if I find out what's wrong, I'd close this issue ASAP.

When uploading the "Reichstag" model based on the tutorial from https://cesium.com/docs/tutorials/rest-api/ , then everything is fine. The asset ends up in the asset repo (ID 104606).

By default, the result is compressed with draco.

When disabling the compression, by inserting

  const response = await request({
      ...
      body: {
          name: 'Reichstag (uncompressed)',
          ...
          options: {
              ...
              geometryCompression: 'NONE',   <-------------- THIS LINE

the asset is still processed, tiled any displayed correctly (ID 111471).

However, in the un-compressed version, the GLB seems to be invalid. I have extracted the GLB for the compressed and the uncompressed version.

(I did this manually, locally, but in order to reduce the likelihood of me just doing things wrong, I also extracted the GLB with the b3dmtoglb command of the 3D tiles tools )

Dropping the compressed version into the glTF validator causes some warnings, but no errors (although I think that it won't validate the Draco-compressed data).

Dropping the un-compressed version into the glTF validator causes some warnings and an error

        {
            "code": "ACCESSOR_MAX_MISMATCH",
            "message": "Declared maximum value for this component (71) does not match actual maximum (65).",
            "severity": 0,
            "pointer": "/accessors/219/max/0"
        }

This seems to refer to indices, and thus, almost certainly won't cause any problems: Most viewers will not use the declared maximum. Also, the declared one is larger than the actual one. (If it was smaller than the actual one, this might be more problematic).

I have attached the final GLB, for quick checks. If there is anything else that could be helpful, just drop me a note.

Reichstag_uncompressed_withTools.zip

javagl avatar Jun 11 '20 16:06 javagl

Thanks @javagl this definitely looks like a clear cut bug. Even though the model loads in all of the most popular tools, we definitely want to produce content that validates cleanly. Thanks!

mramato avatar Jun 12 '20 14:06 mramato