What’s the gold standard here? For example I’m building out square dungeons. It’s built with modular tile floors/walls. Is it better for each tile to have collision or just make the floor 1 big blocking volume?
Hey there @Krileon! This is somewhat dependent on your game. Simplicity and performance wise, if you’re going to have a predefined dungeon size that would have a sensible bounds, having a singular collision is fine if you would absolutely always need to walk on it with no other criteria.
However, scalability wise, having multiple collisions would be best for “Infinite” dungeons as floating point precision problems can occur when getting far from the center of that massive collision.
Though there are lots of caveats here depending on your game, like having varying verticality to your map, or holes, infinite generation, etc. Navigation is another concern altogether that changes these answers.
1 Like
My dungeon is a bunch of predefined rooms stitched together. The tiles are 400x400 and rooms are probably no bigger than 20x20. So far I’ve just been using blocking volumes to block them out. Each room will have its own collisions though so as the dungeon gets larger there’s not a huge concern there regarding collision center. I don’t plan on having holes or anything in the rooms, but I suppose if I did I’d just block the hole with another blocking volume.
On the flip side what would be the downsides to have large amounts of individual collision boxes?
As long as you manage the amount of them loaded and rendered at any one time, the only real concern is actually managing them. Frustum and occlusion culling will handle the (rendering concerns) rooms you cannot see at any point, but managing their loading could be important if the defined area is large enough. I would estimate world partition would handle this just fine, but you could also handle level instances if you wanted fine grain control, but I feel that’d be premature optimization, especially if the players can double back through the dungeon.
It’s all top-down like a standard ARPG like Diablo, POE, etc.. so what the camera can see is pretty limited.
I was going to give world partition a try, but it just sits at 0% forever and never converts the level. Will maybe try that again once I’m on 5.7.1 (am on 5.6 atm). Players can absolutely double back through the dungeon so I’ve no idea how well all that’d work to be honest. The dungeon is also stitched together and runtime with premade rooms and hallways.
My draw calls seam to be ok with just StaticMeshActors placed all over and converted to nanite so I guess it’s nothing to worry about, lol.
The migration tool for swapping worlds to world partition sometimes fails, it’s usually best to create a new level starting with WP enabled, which could probably be fine since your world is generated at runtime. World partition with smaller cell sizes should be almost ideal for something like this, and make it really easy to manage barring any large set-rooms that require some custom cell loading.
Since your game is top down and not infinitely generating, your performance concerns (for the level) should be rather minimal, especially if the assets you’re loading in are reused frequently. If you do need more optimizations, HISM would be the next step.
I’m not all too familiar with world partition though. What happens if AI are still in a previous cell? I’d basically only want visual culling, which as it stands seams to already be working. I was looking at world partition mainly for the static mesh actor auto-performance feature “Runtime Cell Transformers”, but I’m not entirely sure it’d be applicable to me. Everything seams to already be batching my static meshes as adding more walls doesn’t increase my draw calls.
That depends on your WP cell size and how you have your characters configured, but like any actor on the unloaded cell, they would unload (by default), but you can force AI to load the cell they are on if you wanted them to stay active for some reason.
If you can load the whole dungeon at once and it meets your performance requirements, you don’t need to worry about WP. As I understand it, RCT is just ISM integrated with WP and isn’t expressly necessary for your use case but does offer performance gains if you needed it, though Nanite does a good chunk of what HISM would do.
1 Like
Ah, ok. I think I’ll avoid WP for now as I’m not sure it’s really applicable to my current dungeon setup. Thank you for all the great info!
1 Like