CesiumGS / cesium-unity

Bringing the 3D geospatial ecosystem to Unity
https://cesium.com/platform/cesium-for-unity/
Apache License 2.0
319 stars 75 forks source link

Map Tiles Terrain suddenly stops trying to load at times #466

Open electrum-bowie opened 3 weeks ago

electrum-bowie commented 3 weeks ago

It happens from time to time, but sometimes it gets even worse, like staying still for 5-10 seconds just to load what's in front of you.

The app uses 18 simultaneous tile loads, and loads very fast most of the time, but it's really game-breaking for the terrain to completely stop loading sometimes.

I've tried recording some footage, but all I could capture now is somewhat minimal compared to the times it stops loading for seconds.

https://github.com/CesiumGS/cesium-unity/assets/88616437/a9e93d48-d825-4f98-959d-bc51bcf30bef

kring commented 3 weeks ago

It looks like you're using Google Photorealistic 3D Tiles. Is that correct?

I don't know for sure what is happening here, but my guess is it's just a result of the structure of the tileset. The Google tileset extensively uses what are called "external tilesets", which are basically big chunks of dynamically-loaded metadata about the tile hierarchy. When you move to a new area, you may need to load a new one of these external tilesets. This takes a bit of time, but it also necessarily prevents more detailed tiles inside the external tileset from loading until the external tileset load itself completes. It's even possible, when loading at a particular distance from the globe, to trigger the need for quite a lot of these in rapid succession, because the external tilesets generally occur at a particular level of detail.

If I have that right, there's unlikely to be a simple solution to this within Cesium for Unity. Attempting to predict movement and preload the external tilesets could help. That's something we plan to do at some point, but it's a big feature.

Improving load performance in general could help, and we're planning to do some work in that area in the short term. The early work on that is here: https://github.com/CesiumGS/cesium-native/pull/779

But it's also worth taking a scan through the logs, too, if you haven't already. Perhaps there's something more obvious going wrong during these pauses, and the log would provide a hint?

electrum-bowie commented 3 weeks ago

Yes, Photorealistic Google 3D Tiles.

I thought the performance was the issue too, I believed there was no memory left so cesium had to free some before trying to load again.

After many optimizations and testing, it seems that even with 50-70% CPU usage, 1gb of free allocated memory, and 50-70 fps on Standalone, and even with lower Quality Range ( I forgot the name of the setting, but the one that lowered the LOD for further distances ) set to 30-50, it still has times when loading pretty much stops, and instantly switches to the highest detail when stopped moving...

So if I move for longer periods, the Terrain pretty much stops loading completely ( sometimes ), if I stop moving, it INSTANTLY loads from the worst quality ( extremely blurry ) to the best Quality available - it felt exactly like the terrain continued to load correctly, but only rendering the quality shown like 20 seconds ago, when I started flying.

Also, the logs are clean, there are no errors in the console, not even from my own scripts.

kring commented 3 weeks ago

it felt exactly like the terrain continued to load correctly, but only rendering the quality shown like 20 seconds ago, when I started flying.

Hmm... stranger bugs have happened, but I'd be pretty surprised if something like that were happening. However, when you're moving quickly, it often happens that by the time the data necessary for rendering the scene from one position is loaded, the camera has moved elsewhere and none of that data is relevant anymore. When you stop moving, the data loaded now will still be relevant a few hundred milliseconds from now when it's loaded, so it appears to load much more quickly. I suspect that's what you're seeing, but it's hard to be sure.

CesiumJS has a nice feature where it automatically lowers the LOD when moving quickly. The lower detail both loads quicker and covers a larger area, so, unintuitively, it actually increases the visible detail while moving. Implementing something like that in cesium-native / Cesium for Unity could help a lot with what you're seeing. There's an issue to track it here: https://github.com/CesiumGS/cesium-native/issues/86

csciguy8 commented 3 weeks ago

I wonder if it's stalled on main thread loading? (lots and lots of tiles loaded, but not finished quite yet)

This is the very last part of the loading pipeline that creates the engine's (Unity) resources and we're budgeting only 5ms per frame to handle this. This time budget is set here.

Hard to know for sure without some detailed logs of our loading queues. Even harder to test because it doesn't look currently configurable outside of code. Could be a nice option to add next to maximumSimultaneousTileLoads?

electrum-bowie commented 3 weeks ago

it would be an amazing option to have, yes.

kring commented 3 weeks ago

This is the very last part of the loading pipeline that creates the engine's (Unity) resources and we're budgeting only 5ms per frame to handle this.

5ms per frame is quite a bit of time, though. Unless the frame rate is extremely low for some reason, I don't think this could be the cause of the "nothing loads until I stop moving" behavior that @electrum-bowie is seeing.

electrum-bowie commented 3 weeks ago

FPS is really good, 40-70 fps on standalone VR

electrum-bowie commented 3 weeks ago

(while it happens)

electrum-bowie commented 2 weeks ago

( ignore the AR background ) https://www.capcut.com/s/Cfj6jvPPAJpOXik9/

electrum-bowie commented 2 weeks ago

https://www.capcut.com/s/CbkXWSovjto11cg7/