It would be useful if there was some way of defining how many tiles load in from from your viewpoint/camera (in M/KM?). This would help with bandwidth, load times, quota longevity and improve performance etc.
Looking through the settings I’m not sure if there is a way to already do this? Is there>?
Many thanks
There’s currently not a way to do this. We often get this request, but it would be much less useful than people think. The reason is twofold.
First, it wouldn’t reduce bandwidth and load times as much as you might expect. Because of 3D Tiles’ hierarchical LOD structure, tiles in the distance are bigger and lower resolution, and there are far fewer of them. So skipping them entirely would only reduce the total number of tiles a little bit. It wouldn’t make a big difference.
Second, setting a distance in M/KM wouldn’t actually work that well. The view distance you need is highly dependent on the camera height. For applications with a fixed camera height you might get away with it, but most applications have a mix of near and far views, so a single view distance wouldn’t work.
Internally, cesium-native has a thing called a fogDensityTable:
It’s a bit inscrutable, which is why we haven’t exposed it up through Cesium for Unreal, but the basic idea is that objects that are really far away don’t need to be rendered, and the meaning of “really far away” is a function of camera height. So potentially tweaking that could help achieve your goal. But again, the gains to be had here are quite modest. I’d roughly estimate you could achieve maybe a 10-20% reduction in tile loads by bringing in the view distances, not more than that. And at the cost of having mountains vanish in the distance.
Ok, thanks understood.
I have a camera orbiting around a city centre, how can I ensure tiles are loaded in time (at the required screen space error setting) so that when the camera moves around buildings are loaded in correctly?
There’s no perfect answer to that. If you’re trying to record a video, just make sure you use UE’s Sequencer. It will automatically make sure all tiles are loaded for a frame before it snaps the frame.
But if it needs to be interactive, the best you can do is try to warm up the cache. Set the Maximum Cache Size Bytes property larger so that tiles don’t get unloaded (but not so high that your GPU runs out of memory), and then fly around letting tiles load. Revisiting those same areas again will then be much faster.
There’s also a disk cache, and warming that up will make a big difference. But unfortunately it currently isn’t helpful for the Google photogrammetry tiles (if you’re using those), because of the unusual cache header returned by the Google tiles. More details about that are here:
I have a highway model that needs to be loaded at a distance. For example, within a 20km range of the viewport, if viewed horizontally from a distance, all loads will be loaded, and the graphics memory will reach the upper limit of 24GB on the graphics card RTX4090.
English is not particularly good, please forgive me.
If the highway model is properly broken up into tiles at multiple resolutions by whatever tool created your 3D Tiles tileset, it shouldn’t be necessary to load the entire thing at full detail even if the entire thing is visible. How are you generating the tileset?
Because there are many tunnels on the road, I used “SceneCaptureComponent2D” to independently render the model of the highway visible, and then displayed it on the screen through “Widget”. Due to viewing along the horizontal line viewport, the highway model will automatically be loaded first, and then Bing Maps will be loaded, resulting in the loading time of Bing Map terrain images exceeding 30 seconds. The highway model has approximately 300 3Dtiles.
So you’re purposely forcing the entire highway model to load? That’s probably not going to work well if the model is large, as you’ve described. So I suggest not doing that, and if that was a solution to some other problem, perhaps there’s a better way to solve that problem.
There are two possible solutions now. The first is to provide coordinates to the table in advance, traverse the position and camera position through the table, and determine the distance loading; The second approach is to improve CesiumForUnreal by adding a static mesh component after vertebral body removal. The second method based on tile loading is more visually friendly, and we hope to improve this feature.