So, we had run into some issues with our app randomly locking up on cesium levels. This only occurred on the servers we are running the app on. When we used a profiler, it showed there was a large spike in GPU usage and then it would drop to 0 and the program would freeze.
This only happens on levels running cesium tiles. The only way we were able to stop the freezing is to add the command line arg “-onethread”.
I am unsure why this worked but it did. It seems like maybe there is some thread that is causing issues but when it is executed sequentially it works fine.
Please let me know if there are any logs or additional info you might need.
I’m sorry that you’re experiencing issues with the Cesium plugin. From a glance, I can’t tell what could be causing the crash, but we can try to help with more information:
What versions of Unreal Engine and Cesium for Unreal are you using?
What device are you running your app on? Desktop? Mobile?
What tilesets are you using? For example, Cesium World Terrain? Google Photorealistic 3D Tiles?
Are there any common factors that occur before the freeze? For example,
Does the freeze happen after a certain amount of time that the level has been open?
Does the freeze happen in a particular area of the world?
Does the freeze happen after certain user inputs?
When the app freezes, does it eventually unfreeze? Or does the program seem to be suspended indefinitely?
Please feel free to include screenshots or add anything else that I might have missed. I know this is a long list of questions, but it’s all in the name of giving more informed help.
Once we establish some key information, we can troubleshoot from there. Thank you!
We are using 5.3.2
*Not sure what version of cesium, whatever is on the marketplace
We are running on a server and connecting via pixel streaming. The server is using a T4 GPU
We were initially using the google api tileset but switched to Cesium World Terrain with OSM buildings to test but it didn’t have any impact.
Only common factor that we could determine is moving quickly and erratically. There wasn’t a common interval when it would freeze. Happens anywhere in the world.
It freezes until the unreal thread times out and then it crashes.
Thanks for your response, and for looking deeper on your end! This is really helpful information. I’ve written up an issue on Github based on your description; we’ll post updates to the issue and this thread after we investigate more deeply.
I’m afraid we still need more information to troubleshoot your issue. In particular, can you:
Report the exact Cesium for Unreal version you’re using. When you open Unreal Engine, this is displayed at the bottom right corner of the Cesium window, like so:
When Unreal Engine crashes or unexpectedly closes, we expect to see a log of what happened. Do you see this log – can you locate and share it with us? These logs often contain valuable information for diagnosing the issue.
Along the same line, when this crash happens, do you see a call stack that shares what line the application crashes on?
Thanks for attaching the crash folder. It’s weird that there’s not much information on what went wrong
Still, I searched for this error online and I think there’s something to try. What Graphics API is your project using? Does changing it to DirectX 11 (or perhaps other modes) make a difference?
When changing the graphics api, are there any other changes that I need to make? I tried testing it and the tiles won’t load at all after I set it to DX11.
That’s strange @TeraDan, I’ve been able to switch the graphics API just fine. Just to confirm, you’re setting this in Default RHI under Platform > Windows, right?
Does this happen for any of the other rendering modes? And, do you have any messages or errors in the log? I wonder if the machine is simply unable to handle it.
But in any case, I found an Unreal forum thread that might describe what’s happening here. It’s about a memory leak with pixel streaming that ultimately shows the error message that you received in the crash dump.
It looks like there werePRs to address this, but they appear to have been merged. However, there’s a comment in the thread that suggests this tends to happen with runtime-created meshes:
It appears that this crash rarely occurs when using a cooked scene, unless there are meshes created at runtime.
So I guess it’s a matter of understanding why creating these meshes is causing errors with pixel streaming… which I have not been able to find any resources on
Another forum thread suggests setting g.TimeoutForBlockOnRenderFence to a large number like 9999999, though I don’t know about the implications of it. But it might be worth trying?
