Dipping Nose
by Brandon Gamblin · in Torque Game Engine · 10/28/2005 (11:23 am) · 13 replies
I'm working on a vehicular combat game that has a lot of dunes for jumping. We noticed that when the player jumps over a dune, the nose doesn't dip downwards (as it would realistically, because they're front-engine cars).
In order to simulate this effect, I added a rotation to the player's transform during the UpdateForces function as seen in this snippet:
Now, if I use that code in UpdateMove, it works fine (but it shudders because the camera is rendered at a different rate than moves are calculated). However, if I put it in the UpdateForces, it will stop all forward movement while rotating.
When I view the incoming and outgoing matricies, they appear to be correct (No translation, only rotation). And yet, all velocity is nulled when this is executed.
Am I concatenating matricies incorrectly? Or, I suppose a better question is, how should I be concatenating matricies?
In order to simulate this effect, I added a rotation to the player's transform during the UpdateForces function as seen in this snippet:
int WheelsOnGround = 0;
for (Wheel* wheel = mWheel; wheel < wend; wheel++)
{
if (!wheel->tire || !wheel->spring)
continue;
if (wheel->surface.contact)
WheelsOnGround++;
}
if (WheelsOnGround == 0)
{
EulerF rot(0.01f,0,0);
MatrixF mat = getTransform();
mat.mul(MatrixF(rot));
setTransform(mat);
}Now, if I use that code in UpdateMove, it works fine (but it shudders because the camera is rendered at a different rate than moves are calculated). However, if I put it in the UpdateForces, it will stop all forward movement while rotating.
When I view the incoming and outgoing matricies, they appear to be correct (No translation, only rotation). And yet, all velocity is nulled when this is executed.
Am I concatenating matricies incorrectly? Or, I suppose a better question is, how should I be concatenating matricies?
#2
10/28/2005 (12:40 pm)
The problem is that we've set very specific values for all the driving physics parameters. I have the MassCenter where we need it in order to drive correctly (to avoid rolling at high speeds). 
#3
10/28/2005 (12:58 pm)
Well, if you drop a car from the top of the sky, the nose would -not- dip, because gravity effects all objects equally, regardless of mass.
#4
10/28/2005 (1:10 pm)
I would have to point to the works of the eminent Drs. Luke & Bo Duke, who, in the production of their vehicle physics documentary, were forced to put several heavy rocks in the trunk of their test subject (General L.) to prevent the front end from dipping lower than the back. :)
#5
As the linear velocity increases/decreases in the 'Y' direction (looking at it with traditional right handedness), increase/decrease the pitch of the vehicle.
10/28/2005 (1:13 pm)
Use ballistic trajectory calculations. As the linear velocity increases/decreases in the 'Y' direction (looking at it with traditional right handedness), increase/decrease the pitch of the vehicle.
#6
To calculate force amount, you want to apply force until the nose is pointing down basically. One approach to that would be to take the dot product of your forward vector (by) and straight down vector (VectorF(0, 0, -1)) and using the result to calculate a force amount to apply.
Hope this makes some sense, check out this resource for an example of doing something similar. The two wheeled code applies forces to keep a vehicle upright.
10/28/2005 (1:17 pm)
Code in ::updateForces shouldn't really directly modify the vehicle transform. You should just add a downforce to the mRigid like the rest of the updateForces code does. To roll over, you'd want to apply torque like this:nForceAmount = <whatever amount you want to calc>; mRigid.torque += bx * nForceAmount; // bx = your "right" vector, so this will rotate around it.
To calculate force amount, you want to apply force until the nose is pointing down basically. One approach to that would be to take the dot product of your forward vector (by) and straight down vector (VectorF(0, 0, -1)) and using the result to calculate a force amount to apply.
Hope this makes some sense, check out this resource for an example of doing something similar. The two wheeled code applies forces to keep a vehicle upright.
#7
In the first post, I pointed out how concatenating matricies nullifies the velocity. If I could figure out how to add pitch in the UpdateForces call, without stopping the car in midair, I could handle the rest of the physics calculations.
10/28/2005 (1:18 pm)
Scott - Well, I still have the problem of setting the pitch of the vehicle. In the first post, I pointed out how concatenating matricies nullifies the velocity. If I could figure out how to add pitch in the UpdateForces call, without stopping the car in midair, I could handle the rest of the physics calculations.
#8
10/28/2005 (1:20 pm)
Brian - Thanks. That helps a lot. I'll check it out now.
#9
In theory, the current updateForces should cause the front end to dip because the spring forces on the front wheels would stop applying forces on the main body, but I guess this is a case where you want more than that to help the feel of the game. Good luck!
10/28/2005 (1:27 pm)
Oh yeah, I was thinking about the rotation thing. Jumping a hill and dropping a car are not the same case. If you drop a car completely perfectly in the middle of the air, it might not turn (maybe there's a force that we're not keeping in mind). But when you jump something in a vehicle your front wheels leave land first so gravity will pull down on the front first creating rotation torque forces on the vehicle.In theory, the current updateForces should cause the front end to dip because the spring forces on the front wheels would stop applying forces on the main body, but I guess this is a case where you want more than that to help the feel of the game. Good luck!
#10
Once you get the hang of it you can land almost any jump with a RC car.
10/28/2005 (1:36 pm)
The force your not keeping in mind is the cyntrifugal force output from the tires, When racing RC cars you can easily use this force to control your jump. Spinning wheels will cause the car to nose down however if you apply brakes to the tires the car will actually nose up.Once you get the hang of it you can land almost any jump with a RC car.
#11
10/30/2005 (10:39 am)
Uhm, what about moving the "mass" point closer to where the engine is in the car?
#12
I think I like the torque addition solution better. Just feels like a more accurate solution.
10/30/2005 (11:30 am)
Again, moving the mass node affects how the car drives (specifically, how it handles rolling). The only way that would work would be if I moved the mass point toward the front when the wheels weren't touching the ground, then moved it back when the wheels were on the ground again.I think I like the torque addition solution better. Just feels like a more accurate solution.
#13
10/31/2005 (2:12 pm)
In case anyone's interested, this is the code I ended up with. It's in the UpdateForces function, just before the gravity calculation.// If no wheels are on the ground, make the car rotate downward (to simulate // the engine weighing the car down). // Why 2 million? Because dt is so incredibly small. Unfortunately, I don't have // any better answer than that. // -BWG if (contactCount == 0) mRigid.torque -= bx * dt * 2000000.0f;
Torque Owner David Tiernan