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

gltf model load error #8285

Closed
leation opened this issue Oct 15, 2019 · 10 comments
Closed

gltf model load error #8285

leation opened this issue Oct 15, 2019 · 10 comments

Comments

@leation
Copy link

leation commented Oct 15, 2019

test gltf model:https://github.com/leation/mydata/blob/master/Bee.glb.

Cesium.js:254066 An error occurred while rendering. Rendering has stopped.
undefined
TypeError: Cannot read property 'parents' of undefined
TypeError: Cannot read property 'parents' of undefined
at createRuntimeNodes (http://localhost:8888/test/cesium/Cesium.js:153548:33)
at createResources (http://localhost:8888/test/cesium/Cesium.js:153704:9)
at Model.update (http://localhost:8888/test/cesium/Cesium.js:154606:21)
at PrimitiveCollection.update (http://localhost:8888/test/cesium/Cesium.js:135195:27)
at updateAndRenderPrimitives (http://localhost:8888/test/cesium/Cesium.js:242236:27)
at executeCommandsInViewport (http://localhost:8888/test/cesium/Cesium.js:242075:13)
at updateAndExecuteCommands (http://localhost:8888/test/cesium/Cesium.js:241883:13)
at render (http://localhost:8888/test/cesium/Cesium.js:242534:9)
at tryAndCatchError (http://localhost:8888/test/cesium/Cesium.js:242554:13)
at Scene.render (http://localhost:8888/test/cesium/Cesium.js:242622:13)

@mramato
Copy link
Contributor

mramato commented Oct 15, 2019

@leation thanks for the bug report!

https://gltf-viewer.donmccurdy.com/ loads this model without any issues so I can't think of a good reason Cesium shouldn't load it either. However it looks like there are some errors in it, you can see these by dragging/dropping it into the glTF Validator here: http://github.khronos.org/glTF-Validator/

@lilleyse or @likangning93 anything obvious going on here? Perhaps this is a trivial fix?

@emackey
Copy link
Contributor

emackey commented Oct 15, 2019

The Bee model fails validation due to duplicate keyframes on the last animation time.

Looks like Unity fails to load the model in KhronosGroup/UnityGLTF#476 with a slightly more helpful error message:

Unity does not allow you to put two keyframes in with the same time

Perhaps there's a newer version of the Bee model where this was fixed in the glTF file?

@leation
Copy link
Author

leation commented Oct 16, 2019

Thank you very much.

@leation
Copy link
Author

leation commented Oct 16, 2019

@mramato,@emackey,when I use https://gltf-viewer.donmccurdy.com/ to load the Bee.glb,I found it's has three animations,is this the reason that Cesium can't load Bee.glb?
Image text

@emackey
Copy link
Contributor

emackey commented Oct 16, 2019

No, the 3 animations are not the problem. See in the lower-left where the red box says 642 errors in the file? That's the problem.

Digging into those error messages yesterday, I had found that there are many moving parts on the bee, and each part in each of the 3 animations has a duplicate animation frame on the end. Specifically, the last and second-to-last keyframes appear at the exact same time, which is illegal in glTF. Three and Babylon don't choke on it, but Cesium and Unity do, and as you can see the glTF Validator also fails the file.

It looks like this file was exported by an older Microsoft glTF writer, and I vaguely remember there may have been a bug fixed some time ago related to duplicated keyframes at the ends of animations. Where did you get this file? Can you export a new copy with a newer version of the exporter?

@leation
Copy link
Author

leation commented Oct 17, 2019

@emackey thanks for your detailed explanation.This Bee.glb file is one demo model file of the windows10 3d viewer .As you explained,probably,the Bee.glb file's format is not rigorous.

@leation
Copy link
Author

leation commented Oct 17, 2019

@emackey thanks very much. just I try to use gltf-import-export to convert the Bee.glb to gltf file,the command is: gltf-import-export Bee.glb -o Bee.gltf.Then I use Cesium to load this Bee.gltf,happily,it's works,maybe gltf-import-export can solver error of the Bee.glb.but if I try to use blender to convert glb file to gltf file,it's not work,mayby blender has same bug.
Image text

@emackey
Copy link
Contributor

emackey commented Oct 17, 2019

Glad you got it working.

It occurred to me that I was reacting to the validation failures, but I didn't actually stop to trap Cesium's actual problem in the debugger. Turns out the two are not the same.

It looks like Cesium is having trouble with the model's skeleton, and this issue may be related to (or possibly duplicate with) issue #8175.

@Lemonjay
Copy link

@emackey thanks very much. just I try to use gltf-import-export to convert the Bee.glb to gltf file,the command is: gltf-import-export Bee.glb -o Bee.gltf.Then I use Cesium to load this Bee.gltf,happily,it's works,maybe gltf-import-export can solver error of the Bee.glb.but if I try to use blender to convert glb file to gltf file,it's not work,mayby blender has same bug.
Image text
I tried,it‘s not work

@emackey
Copy link
Contributor

emackey commented May 20, 2020

Although this issue is closed, the Bee is still marked as a bug (no pun intended!) in issue #8759.

I believe what's happening is that Cesium is computing a bounding sphere around the original mesh, and not accounting for the skin deformations of the mesh. That's paired with another artifact of the model scale: small models are sometimes built to "centimeter" scale, where a scaling factor of 0.01 is applied to the whole model. But scaling doesn't affect skinned meshes directly, it affects them by scaling the skeleton instead, which the bounding sphere is not aware of.

So the bee's mesh, with skinning applied to it, is scaled down to 1/100th of its former size. The camera is then placed 100 times further away from the bee than it should be, and kept away.

I believe the correct answer is that the bounding sphere needs to somehow account for sizing applied by skinning.

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

No branches or pull requests

4 participants