Hello!
I know how to collide objects against a terrain heightfield, or a uniform triangle grid.
But how would I go about implementing collision detection with a terrain as an arbitrary triangle mesh?
For example with a height field you can't have tunnels or any kind of 'depth' to your scene.
One way I can think of is to use some sort of octree and split all the triangles. This should be fast, but for detailed terrain the size would get very big quickly.
Thanks!
Get a the min/max bounding box of the object you want to collide with the terrain. Now get all terrain triangles between those two points. Then you can do a per-triangle collision with them. Thats the very basic, non-optimized algorythm, but at least it works unaffected by the terrain size. Its a bit too late for me to show you any example code, I hope you can follow...?
Get a the min/max bounding box of the object you want to collide with the terrain. Now get all terrain triangles between those two points. Then you can do a per-triangle collision with them. Thats the very basic, non-optimized algorythm, but at least it works unaffected by the terrain size. Its a bit too late for me to show you any example code, I hope you can follow...?
"Now get all terrain triangles between those two points. " This is really where the complexity comes in, right? There needs to be some kind of spatial hierarchy to get the triangles.
"Now get all terrain triangles between those two points. " This is really where the complexity comes in, right? There needs to be some kind of spatial hierarchy to get the triangles.
Well, you can pre-sort the triangles in a 2d array like structure on the xz-plane (in dx, that is, xy in opengl if I'm not confused; its as if you where looking from above). Then you simply take the min-point as the index of the first triangle, and iteratively add +1 on both the x and z axis until you are at the max point, adding each triangle at the next point to the potential collision list. Whereas 1 is the density of your terrain, if its more dense you need more steps, though I quess you'd want to use a less dense approximation, seeing how the graphical representation of a terrain can get quite complicated in the nearest LOD. Does it appear more clear now?
Yes it does. So if I have a tunnel or a cave or whatever, I could have multiple triangles under the same terrain "cell"?
So if I have a tunnel or a cave or whatever, I could have multiple triangles under the same terrain "cell"?
Thats a little off my expertise, but from what I've heard and what I'd do is, that there is hole in the terrain where a cave entrance is, and the cave itself is a seperate mesh, not related to the terrain directly... Cliffs, overhangs, caves etc... are however a topic I haven't dealt with myself, so there might be different solutions there.
I'm not sure it's okay to bump this, but what about using multiple heightmaps stacked onto each other?
Also, maybe instead of using uniform grids, use a uniform voxel 'box" where each triangle is put into it's own voxel? Also I'm not even concerned about using LOD right now, first I wanna just get collision going in the case with overhangs/ cliffs etc
Just a note: It is also common to use Octree or BVH to quickly get a list of nearby triangles you need to test against ~ these are better than using just grid (especially if your terrain is more complex somewhere and less complex somewhere else.
I use a uniform grid. I mainly develop racing games and found that since the world is largely all on one plane, a grid works perfectly. It's very fast, minimal overhead for lookups etc, and I use the same grid for moving object collision detection.
