-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
Crash in GltfPipeline when loading two viewers with models #7688
Comments
Any ideas ? |
@benjaminmur no sorry, we haven't had a chance to investigate this yet. My guess is some object is being shared between the two viewers when it shouldn't be. If you have time to look into it, we would be happy to review a pull request! Otherwise I'm not sure how soon we'll be able to prioritize this. |
This sounds like a pretty bad regression, do we know what version it popped up in? We should probably tag this next release. |
We upgraded to the 2.0 version of gltf-pipeline then, so it makes sense that if something broke it would be during that release. |
Thank you for making this a priority ! It worked in 1.49 and we built some main features out of this capability. |
This also only appears to be a problem for untextured models (at least groundvehicle loaded fine if I use that instead) |
Yes i confirm. If you load a second viewer, with no timer, but with an untextured model, it crashes too ! Or, with timer and textured models. |
Looking at the original Sandcastle example @OmarShehata has in his issue description, these look like two separate but related bugs. Not sure if it will be the same root cause but we definitely need to check both cases when we fix this. |
This is a glTF caching issue. The note in this Model.js comment almost predicts this issue: https://github.com/AnalyticalGraphicsInc/cesium/blob/master/Source/Scene/Model.js#L178-L189 To demonstrate that this is the issue, just add this line in Model.js:1393:
This fixes both issues presented above. When GltfPipeline loads a model, it actually edits the glTF object itself (for example here https://github.com/AnalyticalGraphicsInc/gltf-pipeline/blob/master/lib/addDefaults.js#L118). Two viewers loading the same model will interfere and this will manifest in various ways. To fix this, we could:
I think 2 would be better, would use less memory, and would likely load faster. Assuming it's not too hard to have Model.js wait until the glTF being loaded finishes loading, since it's already set up to load resources across multiple frames. |
Thanks for tracking this down @OmarShehata! 1 is definitely safer and probably easier, 2 looks trivial at a glance, but I wonder if it will just cause another edge case in the future. I don't have a strong preference either way. |
One fix is to not remove pipeline extras. This is what we did in 1.49 as well for probably the same reason. @mramato's Sandcastle works now. @OmarShehata's has lighting differences though |
The lighting differences are fixed in #7796. |
Congratulations on closing the issue! I found these Cesium forum links in the comments above: https://groups.google.com/d/msg/cesium-dev/MjFBDuFwF28/AZGHfV15AwAJ If this issue affects any of these threads, please post a comment like the following:
|
Thank you very much ! I've just try with the 1.57 Cesium version and it works just fine ! Thank you so much for solving this issue ! |
Reported on the forum. If you create two Cesium viewers, each with glTF models loaded in, you get this crash:
Sandcastle
This only happens when the second viewer is not created immediately. So it seems to be some kind of race condition?
It's throwing this error because during model load, the
buffer.extras._pipeline.source
array has a byte length of 0.It's certainly a less common use case, but given that we do have an official example of using two viewers I thought it was worth documenting.
The text was updated successfully, but these errors were encountered: