Hi everyone !
1. A concise explanation of the problem you’re experiencing.
I have a webpage displaying a cesium viewer with some entities with 3D models.
When i try to instanciate a second cesium viewer, AFTER the first one is created, i experience a shader compile crash.
If the two viewers are instanciated at the load of the page, no errors.
It only appears if the second viewer is created a few seconds after the first one, or later.
2. A minimal code example. If you’ve found a bug, this helps us reproduce and repair it.
I tend to reproduce the same error in sandcastle.
It’s not exactly the same error message than the error in my website, but it’s the same behavior.
here’s a sandcastle:
You can comment the setTimeout, and uncomment the call to “add” method.
You’ll see that if the add method is called inline, no error.
If it’s called after 2s in the timeout, crash.
I think it’s the same error.
You can also notice that if the 3D models are not added to the second viewer, no error.
3. Context. Why do you need to do this? We might know a better way to accomplish your goal.
I need to have secondary viewpoint of the situation in a separate view.
4. The Cesium version you’re using, your operating system and browser.
npm Cesium 1.55, with explicit rendering on.
This crash didn’t happened in the cesium 1.49.
I hope you can find something for me.
Here’s my log in my website:
I’m getting a slightly different error when I try this locally:
DeveloperError: sub-region exceeds array bounds.
at new DeveloperError (http://localhost:8080/Source/Core/DeveloperError.js:43:19)
at getStringFromTypedArray (http://localhost:8080/Source/Core/getStringFromTypedArray.js:29:19)
at Function.ForEach.object (http://localhost:8080/Source/ThirdParty/GltfPipeline/ForEach.js:47:29)
at Function.ForEach.shader (http://localhost:8080/Source/ThirdParty/GltfPipeline/ForEach.js:342:28)
at parseShaders (http://localhost:8080/Source/Scene/Model.js:1593:17)
at Model.update (http://localhost:8080/Source/Scene/Model.js:4428:25)
Is this the error you’re getting in your application? It looks like this has more to do with model loading incorrectly. In this line:
The “buffer.extras._pipeline.source” has a length of 0 when the crash happens. It’s almost as if the GltfPipeline library is running into some kind of global conflict here. If you remove just the GroundVehicle models from the first viewer, no crash happens.
Hi and thanks for the answer !!
So some more details.
The errors i’ve join in the first post is the actual error i get into my application.
I have the “sub-region exceeds” error in the sandcastle as well.
As i said, i don’t get the same error in my app and in sandcastle, but it’s the same behavior.
If i remove the ground vehicul i still get the error.
I’ve noticed that the error is different regarding what model is loaded in the scene.
But still a gltfPipeline error…
I agree with the fact that it seems to be a “global conflict”.
I really don’t know what to do with this…Thanks for the help anyway !
I hope someone can get some clue about this.
I’m pretty sure dynamically creating many cesium viewers is not the standard use case.
Help me Obi Wan Kenobi you’re my only hope
I opened a bug report for it here:
I’m curious for your use case, is it possible to work around it by just creating the 2 viewers once your app initializes, hiding the second one and just showing it when you want to add it?
Thanks for the bug report.
I hope you’ll come to a solution.
For the use case, we want to create dynamically and destroy dynamically cesium viewers, from different point of view.
So it’s not only a matter of 2 viewers, but multiple viewers.
We can’t know in advance the number of viewers that will be created.
It’s also a matter of performance.
If we instanciate a pool of viewers, and showing only the ones that the user wants to display, we might have poor performance.
And it will also limit (of course, if it’s a pool) the number of viewers opened at a time. Wich is not what we want.
I know it’s an uncommon use case.
Thanks for your time !
Let’s keep in touch.
Ok problem solved with the Cesium 1.57 !
Thanks for the bugFix !