## Simulating a vehicle onterrain (OpenGL)

Member
Posts: 24
Joined: 2008.01
Post: #1
My tank simulation game is progressing well. The tank moves realisticly and I can rotate the turret etc. Now I need to add fairly-realistic terrain for the tank to move over and I'm at a loss as to how to do it efficiently!

I've done some googling but all I can find is stuff about realistic terrain generation. What I really need is a simple in-game terrain engine with hills, depressions and impassible mountains loaded from a map file. I need some advice.

The way I see it, the representation of the terrain surfaces isn't all that relevant - I can use triangle-generator algos to produce a surface from points generated from a height file. The hard part is working out the 'collisions' between the vehicles wheels and the ground and adjusting the vehicle accordingly.

Here's my idea. I assign a 'force' vector pointing down for each of my tanks wheels; if the tank has 4 wheels in two tracks then thats 8 vectors pointing down. On a level surface (0 height) that force is 0 (vector is zero length) and the tank is level. On a negative height (depression), that force is increased by the depth of the depression. On a positive surface (hill or mountain) that force is decreased. Using these vectors I can then pivot/orientate the tank realisticly.

The hard part - getting the surface 'level' at any point in 3d and doing it efficiently. I could get the closest 'control point' in the terrain to the wheel position (and hence it's force vector) and then interpolate via a distance vector. But that would mean checking every control point against every wheel on every frame.

Moderator
Posts: 428
Joined: 2002.09
Post: #2
If you want to get fancy there are all sorts of articles and books about simulating the physics of vehicles. But it sounds like you just want your tank to follow the terrain and look reasonable, so your approach seems reasonable to me.

Two ideas spring to mind.

1. If you generated the terrain from control points algorithmically, then you can use the underlying mathematical function rather than the polys. For example, let's say you used bilinear patches. The surface normal and/or distance from a wheel point can be computed using an algorithm. This should be a solved problem for any surface representation you are likely to use, though some are easier than others.

2. You could project a ray at your surface polygons and find the point of intersection. Obviously you don't want to test the ray against every triangle in your scene, so you'd need an efficient way to cull them. I have several ideas in my head that would probably work but I don't want to suggest a naive solution of my own invention when smarter people than I have already worked on it. So look around...

A lot depends on the game. If this is a large world with first-person or behind-the-tank view, then you will probably need a terrain representation that supports LOD (level of detail). Gamasutra had a series of articles about this a while back. And I think LOD can also be used to efficiently find collision points.

If the view is looking downwards, or the field of play is limited, or the terrain isn't very detailed, then only moderate amounts of terrain are visible at a time and the problem is much simpler. A simple space partition of the terrain polygons might be enough, or if there are only a couple hundred triangles, the naive approach of testing all of them may surprise you by being fast enough. Computers really are awfully fast these days. And some naive optimizations are possible, for example once you find the intersecting polygon for the first wheel, the polys for the other wheels will be nearby.

Just some ideas from the top of my head...

Measure twice, cut once, curse three or four times.
Member
Posts: 283
Joined: 2006.05
Post: #3
For an example of how not to achieve this, search on Youtube for a game called Big Rigs. Here's one: http://www.youtube.com/watch?v=mB1zWEhgrLs
Member
Posts: 24
Joined: 2008.01
Post: #4

Yeah it doesn't have to be all that 'correct' by a long shot. The player will be more focused on the action than the interaction between the tank and the ground. It doesn't need 'car physics'.

1) Good idea although I wonder how flexible patches would be. The terrain will be produced via an editor (probably a height map) so the patch would have to be applied on top. I know little about patches, but I think that the number of control points in a patch is limited.

2) Probably the most straightforward solution, althought it depends on the resolution of the poygon landscape (which probably would be fine). The maps will be pretty big so I'd need to use some kind of bounding box/space partition scheme to just get the local polys. But it sounds straightforward and a 'naive' algo would atlease show if the idea works.

The game will be both first-person and 'behind the tank' depending on the mode, so a LOD scheme will be a must. I'll probably just create tank/building models at different resolutions and switch them in depending on the distance. I'll also use fog.

When you talk about terrain-LOD, do you mean terrain where the detail changes with the distance? Interesting I'll have to read up on that.

And how in particular can LOD be used to find collision points? I know about using the vehicle's bounding box to get the approximate collisions etc. Is that what you mean?

You're certainly right about the speed if modern CPUs. It's so easy to spend ages optimizing an inefficient routine because you think it'll be slow, only to find otherwise!
Member
Posts: 24
Joined: 2008.01
Post: #5
maximile Wrote:For an example of how not to achieve this, search on Youtube for a game called Big Rigs. Here's one: http://www.youtube.com/watch?v=mB1zWEhgrLs

HAHA Who hasn't heard of 'Big Rigs'?

Great game.

Still at least Big Rigs does terrain well. They just didn't bother to put in checks for a maximum speed, climb elevation or boundary. Very sloppy.