Aligning a vehicle to terrain

Started by
6 comments, last by Codeka 14 years, 2 months ago
Case and point: I can do it with four points, which uses the front and rear wheels do compute the pitch and roll factors. It works quite nicely, but doesn't provide very good results for tracks and half-tracks (eg tanks), which is what I'm dealing with (when tracks are long they will start to go through the terrain, plus there's no "tank going over a hill with a cool drop as its center of mass crosses the threshold" effect). Here's a sketch: The sketch exhibits two cases where I want the result to be different: the black line is the terrain underneath a track, the blue boxes are contact nodes where the track's contact with terrain is tested. I blotched the center of mass indexes (for some reason I added two of them to make things a bit less clear): COM1 = center of mass 1 and goes with ALIGN2. Eg if the total mass on the right side of COM1 is greater, the track should align to ALIGN2. Conversely, if the mass on the left side of COM2 is greater, the track should align to ALIGN1. This should be a simple logic problem to solve, even for me, but at this time it's seriosuly hurting my brain. So: given a center of mass COM (I calculate mass factors for contact nodes based on a their distances from COM; should I take a square root of these to even the values?), how do I determine the two primary contact nodes that determine the pitch of the track (0 and 1 for ALIGN1, 1 and 4 for ALIGN2 in the above sketch). Let's assume I can have any number of contact nodes (in this case I'm using five)?
Advertisement
If it was me, I'd just bite the bullet (so to speak) and use a physics library... not that that answers your question, of course [wink]
I considered that, but the problem really isn't that difficult and I really don't need the additional complexity of a physics library. All I need is to find a way to properly align the tracks to the terrain and the rest sorts itself out automagically :)
Use additional points. Use six points for half tracks, maybe 6 or 8 for full tracks.
I've had a bit of a think about this, and I think this is how you could do it. I'll refer to the diagram below (I'll just do it two dimensions for the sake of discussion, but to do it in three dimensions you basically just do it both ways ):<br><br><img src="http://codeka.com/tmp/align-tank.png" /><br><br>If we start with the bit labelled "A", what you do is find the centre of mass and project down to find the height (green dotted line). Then do a bunch of projections to either side (yellow dotted lines) and find the highest point &#111;n either side of the centre of mass. Those two points are the &#111;nes you want to align with (you can see the red dotted line is where I've aligned it).<br><br>The method is &#111;nly as good as the number of projections you do (in the diagram, you can see the terrain sticks through a bit). If you do more projections, you'll get better results - at the cost of performance of course.<br><br>There are also some pathalogical cases where it's going to result in the wrong result. If you look at the bit labelled "B", you can see how this could happen. If you want to avoid this, then I would simply do a second set of projections to ensure that no points are higher than the plane you've aligned the tank to, and if there are any such points, choose those instead and re-do the alignment.<br><br>I think this would work in most cases (at least, all of the cases I can think of). The hardest part is actually getting it to animate realistically (i.e. &#111;nce you move over the "tipping" point, getting the tank to fall down). This is why I would've choosen a full-blown physics library.
Brilliantly simple, Codeka - I expanded this a little bit and the results are pretty good. Of course I'm not getting that cool tank-flips-over-a-hill effect the way it's in reality, but I added rudimentary slope acceleration and a few more contact nodes and now it actually looks pretty decent. No real physics, but I don't really care about real physics here - I want a good degree of predictability and most of all, I want it to be fast with a large number of units, not to mention a large degree of intuitiveness for the player.

If anybody wants source code, drop a line and I'll clean it up and post it. Or PM me or whatnot.

Oh, one more thing, Codeka - I'm not really getting what's wrong in example B in your post.
It's not too much work to get a simple 3d angular body simulating. Influenced by springs/ray casts.

This could get you rolling: http://gafferongames.com/game-physics/physics-in-3d/

The RK4 isn't really necessary. It could be nice though for increased tuning resolution.

The trick is then handling the friction and its influence on the vehicle. I've gone every direction on this and my current implementation is my favorite. But someone else owns it, so i'm not going to share it with you just yet. :)
Quote:Original post by irreversible
Oh, one more thing, Codeka - I'm not really getting what's wrong in example B in your post.
Example B would be a problem if your tank is coming down a steep slope onto a shallow slope. It could result in the front of the tank "sinking" into the terrain. If your tanks move forward quick enough, then you might not notice it.

This topic is closed to new replies.

Advertisement