Collision detection and response: Terrain Following

COLLISION DETECTION AND RESPONSE: TERRAIN FOLLOWING.

This demonstration uses the mini framework as explained in the previous document to respond to collision detection data, as provided by the main framework, to implement terrain following or gravity.

The demonstrations itself uses a technique used throughout other examples, where geometry is created and rendered, and another set of geometry, called “walkable” , is really only triangles with norml data, position and normal data only, and not sent through the rendering pipeline, but kept in memory and used to specifically indicate “walkable” areas in the scene, the wlakable areas may be connected to form staircases, hills, can be uneven, contain multiple levels, doesn’t matter, the only secret to this technique is the “walkable” triangles need to be relatively small, as in considered a world scale meter in these examples are about 5.8 units, the triangles need to be smaller than 5.8 units in length, there can literally be millions of these triangles, and they can be in arrays of walkable quads, forming staircases, walkways, floors hills, mountains etc…the mini framework and main framework will calculate the midpoint of the walkable geometry for each walkable array, using standard math concepts (add all points for given walkable, divide by total points) and then it also calculates the radius of the walkable, so if a walkable is outside of the radius from the camera, it will not be checked at all, if it is within reach, (above, or same level as camera), all the triangles will be checked in each of those walkables that are in range, if the quad itself is in range, so there are 2 range checks, 1 that checks if the entire array should be checked, and 1 that checks each triangle to see if the triangle needs to be checked for an intersect, as checking all always is just not the right way to do it! So this is super fast, and basically boils down to buckets (that radius is specified as a default value, and is about 30 units (taken as an example value, can be more or less), so any walkable triangles (of walkables that are already in reach only) that are within 30 world units will be checked (for intersect)), and a line drawn/cast from the camera downwards, if it intersects, the closest (meaning the shortest distance to the camera is calculated, because there could be multiple intersects [which this demonstration demonstrates, levels above and below levels!]) walkable is used as the terrain to walk on, or collide against, there is one more important calculation that takes place, when a walkable quad is within a very short distance of the camera, (about 5.8 units) the normal of the quad that intersects is used, and a sliding vector calculated perpendicular to that colliding normal, so that the camera appears to slide or move along the terrain it is colliding with, or walking on. This same principal is applied in the wall slide example, which will be explained in the next demonstration. This then allows the camera to follow uneven terrain, staircases, multiple levels up and down, doesn’t matter, the only thing is, the framework requires geometry (walkable) that contains position and normal data, in triangle format, to indicate where the walkable terrain is. That is usually very easily exported using blender, *(side note, there is a Python Blender export script that automatically exports walkable and wall geometry with the correct OBJ settings in the background that could be used to do this, as long as the objects are named according to a naming standard in Blender, i.e a walkable , must be called eg. Level1_Walkable, and Level1_Wall)

The other important note is, it is much simpler and efficient if the walkables are exported as “Cells” or parts of greater geometry, which will then increase the effeciency of the bucketing method of checking quads. Only buckets that are within range, will be checked, and only quads within those buckets that are in a certain range will be checked for intersect. And from all that intersect, the closest to the camera (intersection subject) is used as the final point(including normal) where collision will occur, and this method is maintained with each frame, so the terrain is folowed as it slopes.

Mini Framework Documentation:

Previous Example:

Code Example: CollisionDetectionGravity

ScreenR Demo:

Pictures: 

[1]

[2]