## 3d Terrain in a RTS/FPS

Apprentice
Posts: 19
Joined: 2005.11
Post: #1
Thinking caps on from this point forward!

I need some help on creating ways to do the 3d terrain in my Real-Time Strategy game or a first-person-shooter. I have two solutions so far: I could create a texture map and have each vertice on a grid look up the luminance value for it's corresponding pixel in the texture, and that value determine it's height - or have a randomly generated noise function that would determine the height of each vertice on a grid. Both are very similar, the noise function would probably be easier because I have no idea how to extract data from images (anybody know of how / where to find tutorials on this?)

Regardless, they both bring up the same question: How does the character/unit know it's height? Should I constantly query their height from the texture/noise map?

I'm brainstorming here, so any suggestions, ideas, pitfalls to be aware of, etc would be greatly appreciated.
Luminary
Posts: 5,143
Joined: 2002.04
Post: #2
I'm sure there is no game out there that doesn't use a big 2D array of height values.
Moderator
Posts: 916
Joined: 2002.10
Post: #3
OneSadCookie Wrote:I'm sure there is no game out there that doesn't use a big 2D array of height values.
I know that Tribes 1 terrain were generated procedurally.

I do not know how they are queried though.
Member
Posts: 161
Joined: 2005.07
Post: #4
I think using large 2D arrays of numbers is archaic. Why? You'd need to code two engines for collision detection - one for interacting with the ground, and another for interacting with level geometry, like stairs and walls and things. It's much simpler from a coding aspect to unify the two engines by converting the height map into a polygonal mesh like the rest of the geometry.

That's just one man's opinion though.
Apprentice
Posts: 19
Joined: 2005.11
Post: #5
Should I even ask how to do collision detections with a polygonal mesh?

Also, this might be along the same lines, but say in a RTS game the camera is tilted 45 degrees, so it's not looking straight down. If I wanted to click on a unit / draw a box around units that are on a 3d-terrain, that's no problem. Frustrum checking / ray + sphere collision. So I have them selected, and then I right-click on the ground to tell them to move somewhere. By right clicking, I can cast a ray from the camera, but how would I know where that ray interersects the ground on a 3d terrain?
Member
Posts: 161
Joined: 2005.07
Post: #6
bwalters Wrote:By right clicking, I can cast a ray from the camera, but how would I know where that ray interersects the ground on a 3d terrain?
The same way you'd handle the collision detection with the polygonal meshes (don't you love uniformity?): all of them involve detecting the intersection of a line segment (or a ray) and a triangle (a.k.a. a polygon). There are a bunch of online resources describing this type of collision detection, and it's pretty basic.

Once that's set up, it's as simple as looping through the triangles (or triangle strips) and testing it against the line segment.
Member
Posts: 161
Joined: 2005.07
Post: #7
Just a few examples of what to do with the line segment and triangle intersections:

1) If you want a player to react to walls and floors and stuff, the two parts of the line segment are the player's old position and new position. Construct a line segment from those two points and pass it in to the collision detection method, and it should return the intersection point on the triangle. Then you just update the player's position accordingly.

2) Like mentioned before, letting the user click on objects is as easy as casting a line segment out from the camera and seeing what triangle it collides with.

3) If you want a dynamic camera for a 3rd-person game, you can keep the camera in bounds similar to how you keep the player from falling through the floor - you just create a line segment from the camera's old and new position, then see if it intersects anything and update as needed.

Those are just a few examples.
Member
Posts: 268
Joined: 2005.04
Post: #8
Grayscale heightmap + vertex array of triangles = easy-peesy Terrain.

See NeHe for a simple implementation.

Quote:Should I even ask how to do collision detections with a polygonal mesh?

Find what triangle you're in (fairly easy 2d calculation), find the slope of the triangle using the normal (also easy), set the character to the proper height based on its position within the triangle. Simple trig.

Quote:Also, this might be along the same lines, but say in a RTS game the camera is tilted 45 degrees, so it's not looking straight down. If I wanted to click on a unit / draw a box around units that are on a 3d-terrain, that's no problem. Frustrum checking / ray + sphere collision. So I have them selected, and then I right-click on the ground to tell them to move somewhere. By right clicking, I can cast a ray from the camera, but how would I know where that ray interersects the ground on a 3d terrain?

gluUnProject
Member
Posts: 151
Joined: 2002.09
Post: #9
imikedaman Wrote:Once that's set up, it's as simple as looping through the triangles (or triangle strips) and testing it against the line segment.

Simple for you but tedious for your CPU . You should rather use something else like BSPs for collision detection for single meshes.
Member
Posts: 161
Joined: 2005.07
Post: #10
Hog Wrote:Simple for you but tedious for your CPU . You should rather use something else like BSPs for collision detection for single meshes.
It works for my needs, since it can handle up to 5 million collisions per second. The most I ever use per frame is usually around a few hundred.

EDIT: I should add, for things like first-person shooters, you usually use an invisible bounding box around the player for collision detection. You can even use more than one bounding box, like one for the chest and hips, one for an arm or leg, etc. Each bounding box is made up of 12 triangles, so it greatly lowers the number of polygons being tested by the collision detection.