Vehicle animation & physics in 3D

#1 I can't give too much guidance, but I will say that the way our C++ engines work is your first suggestion: Wheels are separate objects, and the vehicle physics tie the body of the car to the wheels, and the wheels interact with the ground.

That's -probably- a pretty decent idea to start from.

#2 An additional idea might be to have all 4 wheels connected to the vehicle mesh and then create 4 different animation threads. Each animation thread would have one wheel lifted from the lowest point to the highest point. Then, using blended animations and value interfaces, programatically raise each wheel in response to the vehicle's pitch and roll angles. For reference, see the FPS demo - the robot uses a value interface to 'blend' an animation of the robot bending from down to up. The value interface is set in response to the player pointing the robot up or down with the controller.

John K.

#3 Thanks John, I'll take a look at that. I haven't messed with animation yet (one thing at a time!)

Stephen: I licensed both Torque X Pro and TGEA, and I noticed the vehicle code in TEGA. If you have any specific guidance that you can't post publicly, please feel free to email me. If I can really wrap my brain around how it works in TGEA then I may try to port the code over as a vehicle component in Torque X, or at least get some good ideas. (I want to stick with Torque X because I'm targetting the Xbox and the productivity boost from using managed code is tremendous - its only me and an artist so we need all the help we can get.)


Speaking of, I'm still trying to get a handle on all the interfaces in Torque X. The documentation on the 3D stuff is really sparse, just in case you didn't have enough work to do :)

Is there anywhere that lists out all the interfaces and their purposes? eg: these are the physics/collision interfaces, and so on. I remember seeing a tutorial somewhere about writing 2D components and it seemed to give a clear enough picture of how to register delegates for the various events, but it (obviously) only covered the 2D interfaces. A quick 101 tutorial on writing different types of components would be even better.
Without the FPS demo I would have been so lost I probably would have given up - it has been really valuable as a reference.

#4 Stephen and John:

After even more digging, I discovered the RigidConstraint classes, though I haven't found any examples of them being used as of yet. I am starting to think that a RigidSpring constraint might be the ticket for connecting wheels to the vehicle.


Is there any existing documentation or a physics example that uses the existing constraints?

#5 Update:

I have a vehicle with four-point contact to the ground and suspension working, but I have run into a huge show-stopper. It appears that the RigidBody physics support in TorqueX doesn't do angular rotation when you call ApplyImpulse.

In other words when you steer the car it goes the correct direction, more or less, but it just appears to slide rather than move properly because the rotational component of the impulse is being ignored. I noticed if I set RotationScale to any value other than zero it freaks out and the code comments seem to indicate that rotation isn't supported.


Is this really the case?


edit: Well now I can't seem to figure this out... the physics demo level of the FPS demo has boxes which seem to respond to impacts correctly - if you hit them on one corner they apply the impulse from the collision correctly.

If I set a RotationScale of 1.0 my vehicle just starts spinning out of control (collision box is 2x4x1). If I change the collision box to 4x4x4 then the box sits there and starts rotating about the Z axis, speeding up over time, but the speed is dependent on mass.

I also tried commenting out all the calls to ApplyImpulse on my component (which inherits T3DRigidComponent), but I got the same effects basically - if the box wasn't square and had a high mass it would just go off spinning like crazy.

#6 The most fundamental change I have made to the vehicle physics is getting better control over the moments of inertia. The existing stock system in TGE only allows a spherical or a "box model" of inertia. This is an unfortunate choice as this model doesn't cover much of the full space of even diagonal inertia matrices. I added new capabilities to set the inertia via a vector of diagonal elements, or as radii of gyration.

See class Rigid::setObjectInertia for how the inertia is set in stock Torque.

#7 Note: found another bug. In RigidCollisionManager.cs, the CastRay method. It causes the method to return the index of the body in the result list instead of the index of the shape that was hit on the body (which is what the comments say).

// check the bounding box
                    if (shape.CastRay(queryData))
                    {
                        // earlier - set the first variables
                        if (queryData.Time < firstTime)
                        {
                            firstTime = queryData.Time;
                            firstNormal = queryData.Normal;
                            firstBody = body;
                            firstShapeIndex = j; //NOTE: fixed - was i
                        }
                    }

#8 Russell, I think you're right. I'm testing the code change now. If everything looks good, I'll check-it into the engine source.

John K.

#9 OK I have added moment of inertia and center of mass to the stock RigidBody class (based on Rigid in TGEA) and it is almost working right, but there is still a problem. If I run the physics demo the spheres all react correctly, but the boxes don't.

They do fall and interact better now, correctly tumbling instead of just falling forward, but they have a tendency to settle onto their corners, and if you give them a nudge they will tend to roll around the four corners of the box and end up resting in an odd position, instead of falling flat onto a box face.


For the spheres I'm using a unit sphere moment of inertia; for the boxes I'm using the moment of inertia for the box, according to it's mass and side (in this case 4x4x4).


Basically the simulation isn't stable - things seem to jitter around. I don't see anything in the Rigid class for TGEA to deal with this and I'm not sure if it is a bug in my implementation or a limitation of the physics in TorqueX.


Any ideas?

#10 Well I was getting wierd errors about being outside a scene bin range, but it turned out to be failing to normalize the angular position in the property setter for the Transform on RigidBody, so that problem is solved. (the angular position would end up being NaN which caused all kinds of fun problems).

I still see the box problem; spheres seem to behave correctly, but boxes want to rest on their edges or a corner. Sometimes they will rest flat on a face (like you expect) but usually not. Boxes that aren't square are worse, tending to roll wildly and even clip through the terrain falling to infinity.


I'm going to post the code in the private forum; please apply to your TorqueX pro and run the Physics test level - you can see what I mean.

edit: The thread is here, for TorqueX Pro owners: www.garagegames.com/mg/forums/result.thread.php?qt=74435

#11 OK I think I finally got the basic physics working, see my thread in the private forum for updated files. ApplyImpulse now correctly applies angular momentum according to the inertia tensor.

But it turns out that my vehicle now wants to roll and/or flip out if I give it anything except a null inertia tensor, which tells me that there is something wrong with my suspension calculations.

#12 Russell,

Would you be willing to provide a summary of how you set up your vehicle in terms of dts export? Specifically, how did you set up the dts files and the animations?

Thanks,
Jeff

#13 Haven't gotten that far, I've been working on vehicle physics, which I just got working a few minutes ago. I'm trying to tune the parameters right now to see if I can get it to behave the way I want.

I know that we can export the vehicle and the wheels separately - I've already tested that - but it makes things more complicated because you need several scene groups and T3DTSRenderComponents.

I may see if I can use the animation threads (as previously suggested), so we can get things like shock arms in the model and behaving correctly.