When I join a session that has the google tiles, it pops in and out and causes the controls to become jittery.
Is there a way to limit the number of times it reloads the tiles? I’d prefer if it may take a little longer on the initial load and then just keep all the tiles present but it seems to be continuously calling the api to load the tiles and that delay is causing the game to hitch.
That’s a little odd. I wouldn’t expect tile loading to present itself as jitters or hitches.
There’s a great deal of work within the tile loading code to keep it off the main thread and as parallelized as possible. In addition, when tiles are loaded, there are two caching mechanisms we use…
A memory cache that hold recent tiles that we don’t have to unload immediately. This is configured with a Cesium3DTileset’s
Maximum Cached Bytes property
An on disk cache that stores recent urls fetched from the network. You can see this on your machine here,
Based on these, you shouldn’t see duplicate API calls for previously viewed tiles. (although we do revalidate google tiles when reused from the disk cache, but this should be very minimal traffic)
Can you give us more detail about your machine specs and what’s in the scene you’re viewing?
Also, as a baseline, do you see these performance problems in our cesium-unreal-samples level? (12_GoogleMapsTiles)
So, I am using 2 3D tilesets, the one the player walks on is the default bing tiles and the distant one is the google 3D tiles. I am using the raster overlay to cut a hole so they don’t overlap but the tiles keep flickering in and out and the google tile will still periodically render for a few seconds inside the overlay where it should be excluded.
We are using pixelstreaming to connect to the client and the controls on the pixelstreaming side are hitching and stuttering when we are running a level that uses cesium. I tested this on other levels that don’t have cesium tiles and there is no stuttering.
Maybe this is some kind of issue with the network connection when the api calls are loading in the tiles or something but the stuttering only seems to occur when pixelstreaming from a level running cesium.
I will take some time to load the cesium samples on one of our servers and run it through the pixelstreaming server to see if I still experience issues.
I can’t currently see what the RAM and processor are put we are running a google cloud compute server with a Nvidia T4 GPU.
Thanks for the follow up.
I’m not very familiar with integration with pixelstreaming / google cloud compute, but I’d imagine for any “stream from a remote machine” type experience, it’s very likely that network performance could easily get coupled with end user frame rate.
Here’s one theory…
Google 3D Tiles are a particularly data dense tileset, at least in comparison to Cesium World Terrain. In addition, the Cesium tile streaming logic engine tries to load tiles as fast as possible by default. The VM you are running on may be experiencing download spikes.
There’s a way to throttle how fast Cesium downloads though. In Cesium3DTileset, there’s a property called
Maximum Simultaneous Tile Loads that defaults to 20. Set this to lower (maybe 10?) and you should see significantly slower loading times. If you needed to debug by freezing downloads completely, you can enable
Any update on this? My end goal is to run via pixel streaming - but I’ve been doing my development locally for now. Now you’ve got me worried that when I upload to the pixel streaming service, we’ll start getting glitchy performance.
The bottleneck would be at the server end, right? Not the clients’ network. (As the tiles are streamed by the UE app running on the server). So, we might be able to fix things by ensuring fat enough pipes into and out of the server?
I haven’t had time to test it yet. I made the change he suggested but I haven’t gone through the process to benchmark it.
The only other issue I have is the tiles seem to load first then remove themselves from the raster overlay exclusion area so I keep gettings overlapping tiles popping and out.
I’ll try to post of video of it soon.