- terrain.JPG (235.5 KiB) Viewed 9941 times
Here an image from my terrain, as i have quite the same problem.
This is a very low lod, but if we would zoom in to the detail the collision mesh should have for a game on the surface, we would see similar structures and details, just at higher frequencies.
(I'm currently working on making the meshing pipeline out of core, so i can generate such large data sets at all.)
Once i have this working, i can start work on generating a reduced mesh.
However, the problem with mesh reduction is:
At smooth regions (valleys) we can achieve aggressive reduction, so performance will be much better.
But at regions with structure and detail (mountains), we can't reduce so much. So at these regions perf. will be still worse, and we require a large buffer for many triangles.
Thus, mesh reduction won't give us a uniform, guaranteed speed up. So it's nice to see you plan to improve this. If the OOB is large, there is no guarantee that a fixed size buffer will be large enough for all cases, effectively forcing us to use 'small' game objects. (I don't think that's a big problem, but ofc. a more general solution would be better.)
For an alternative i could use tiles of heightmaps to represent most of the terrain.
But won't work for cliffs and caves. And i don't want to use heightmaps at all, because with a mesh i can represent the whole static world, including buildings.
So by using tiles of meshes, i can use a regular grid to find the tile, and then only one BVH per tile is needed to find all static collisions. I don't need multiple, overlapping acceleration structures for terrain, rocks, and buildings.
So i assume the 'one mesh for all' approach should be also the fastest solution in the end.
That's why i'm personally convinced that heightmaps are a thing of the past.
Though, there is more to this than just collision detection.
I was playing the Uncharted game, which really is a good example of actions i want to achieve with robotic ragdolls.
Climbing is an important mechanic for this game. Similar to Tomb Raider, the character can climb and handle along paths made from edges. It can also jump from a current path to another nearby path.
Likely they make those paths all manually during level design.
But it would be much more interesting if we could detect them at runtime, as part of the AI system.
Thus, for such things it would be necessary to have adjacency information for the mesh, so we can traverse it for AI purposes.
That's maybe a reason i would decide to make my own static mesh primitive, as you have suggested i probably should.
But not sure yet. Just mentioning it in case you consider to add full adjacency for future changes.