Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
javagl opened this issue Jun 11, 2020 · 1 comment

Comments

@javagl
Copy link
Collaborator

javagl commented Jun 11, 2020

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

@mramato
Copy link
Contributor

mramato commented Jun 12, 2020

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants