I have an 'infinate', procedurally generated map which is divided into section. 1024 in size. I am planning to use Terrain for the ground.
What Im wondering is what gives the best performance. Does it matter what size the Terrains are? Would it be better to have smaller terrains?
I have a grid of 3x3 sections (1024 size) which i swap out when the player leaves the center section. Would it be best to recycle the Terrain, swap the heightmap in it and change translation? Would it be better to divide my sections up into smaller Terrains?
And, by the way, thanks for your engine. I just gave up on my own and it was very easy to switch. Excuse me for repeating myself and bad wording, I'm on a phone and I need to put my kids to sleep .
There are a few reasons to prefer larger chunks over smaller chunks:
1) The terrain has constant-time lookup of triangles for collisions. Large terrains are just as fast as small terrains in pairwise tests. This is technically better than the log lookup time of the default broad phase which would be leveraged more with smaller chunks, though both are very fast.
2) The boundaries between triangles within a terrain are smoothed to avoid bumps. The boundaries between terrains are not. So, an object going across a terrain boundary may snag a little. Larger chunks mean fewer terrain boundaries.
3) There's a slight performance tax for having more objects in the broad phase even when they aren't moving or colliding. Having something like 81 instead of 9 terrains is pretty insignificant- handfuls of microseconds, probably- but at the scale of many thousands of static objects, you may notice the broad phase eating up a good chunk of the frame budget. Keeping the count low when convenient is a good idea. (Notably, some planned changes to the broad phase and collision detection pipeline should eventually make this a total non-issue. It may take me a while to get around to it, though.)
So having a 3x3 grid that recycles terrains as the player moves out of the current center chunk is indeed a fine approach.
Thank you for the reply. So, from what you're saying I will assume that I can use a float[,] sized 3072*3072 which I use for a singular Terrain. Update said array and change the Transform to represent my new offset when I shift the tiles.
If you wanted the engine to compute the bounding box for you, OnShapeChanged would indeed need to be triggered somehow (directly or doing something which forces it otherwise), or just call Terrain.UpdateBoundingBox() directly since that's all OnShapeChanged does for terrains at the moment.
Should you find the UpdateBoundingBox process to be a bottleneck, note that the BoundingBox property of a Terrain is settable. So, rather than recomputing the bounding box for a big chunk at runtime, it could be precomputed and loaded when needed.
Updating every height and updating the bounding box on a 3072x3072 block sequentially will probably drop a few frames, though. This could be mitigated by double buffering and only doing the swap after an asynchronous process finishes all the heavy lifting. If it ends up requiring more/smaller chunks to make this implementation convenient, the engine should be able to cope.
Thank you for the answer. I'm kind of obsessed with performance and memory allocation, as all game deveoplers should be. Since you're developing a physics engine, I am pretty certain you might be even more obsessed than I am. Hunting those extra microseconds.
Anyways, It seems to me that the most efficient way would be if I calced the bounding box myself while the heightmap segments are being generated. I'll check the source and see how it should be done.
.