If you’re merging all the stuff aren’t you losing a bunch of occlusion culling opportunities?
Actually we were only merging props on same plots that share same materials. Each plot is 10m x 10m only.
If you’re merging all the stuff aren’t you losing a bunch of occlusion culling opportunities?
Actually we were only merging props on same plots that share same materials. Each plot is 10m x 10m only.
why not put em in other scene and load it async?
These objects were not really in-scene objects. These were placed by the players, and there was no hard limit on how many objects can be placed in 1 city.
While it sounds impressive, It's not quite there. Your leaving a lot of VRAM and over-using your CPU for no reason. You should chunk this out into partitional scenes so you don't spend more time searching for relevant data than necessary. Especially if you have a large scene, You want to bring down your search speeds. Searching through 81,521 objects everytime you need something, which can be a lot of times, is expensive. If an area that only holds 100\~ plots of land, Then it would be far faster and more efficient to recreate stuff, Your hiccups your experiencing, are caused by this massive scene. Rebuilding meshes is very inexpensive, i rebuilt 400, 120,000,000 faced meshes at 500fps utilizing 3.5gb of VRAM, Rebuilding as you went up/down layers. This was isolated to its own scene for maximum efficiency.
Fair point on search cost, that's actually why step 3 exists. Before AOI culling the peak props loaded in memory at a time was 81k, post AOI it reduced to less than 3k. Also scene partition wasn't possible because plots & Meshes are not static, they are editable for the players. Many systems required referances to these plots and Meshes. Scene partitionning would have required us to rewrite a very large portion of the code.
Hang on - I'm in the middle of experimenting with different optimisation techniques myself (city-based game as well where props are aplenty... sigh) - that's an interesting philosophy. you're saying i should USE VRAM as a resource to burn to take the load off scripts that have to balance the loading/unloading? I've been worrying about VRAM usage (target is 30FPS Steam Deck) so I've been allergic to anythign that increases VRAM but certainly the "use it not stinge on it" does seem to make sense, now I think of it...
Just use DOTS?
In our case the bottleneck was network payload size and what's stored in memory. Plus the memory layout itself was not constant, since the props are placed by the players. DOTS is well optimized for constant memory layout.
The part of your reply that deserves more attention than the AOI itself: partitioning was blocked by the references, not by the props. Once a pile of systems hold direct references to plot objects, every streaming strategy turns into a rewrite, and that is the cost people skip over when they say just use additive scenes. The shape that stays open is keeping the plot as data with a stable id and treating the GameObject as a view built from it. Then AOI culling and scene partitioning stop being two architectures and become the same mechanism with a different radius. Since you actually shipped it: what did you do about a player parked right on an AOI boundary? Naive radius checks thrash there, and the fix (hysteresis, or a dwell timer before unload) never makes it into the write-ups.
Genuinely good question, I wasn't expecting to get one this specific. In our case AOI was grid based, not radius based, so there's no continuous threshold to hover near. Plus, Plots load as soon as they enter AOI, while unloading is lazy through a fixed-size object pool. That is similar to what hysteresis is trying to achieve.
You’re absolutely right
Are you running the remerge off of main thread?
Yeah, part of it was running on main thread. While it's possible to process the data in another thread, but read/write must happen on main thread and that too in a single call. The framedrop would happen when we were writting the combined mesh data. We searched for the async api for this, but found none.