Game Development Community

WheeledVehicle steering and rendering

by Matthew Jessick · in Torque Game Engine · 02/08/2008 (9:32 am) · 1 replies

The client side rendering of WheeledVehicle steered wheels is a little different from what the WheeledVehicle::updateForces is modelling for the physics. There might be some situations where this causes the car to look like it is acting a little funny. Mostly when you are looking at another vehicle maneuvering slowly near you. In most cases this won't be noticible unless you are looking at a vehicles side. (Anyone doing a Valet Parking game? ;) )

Again, the differences between physics and rendering aren't all that noticible under most circumstances. I happened to dig into this because I was trying to use the wheel's visual states to figure out problems I was having in a rear steering vehicle.


First, the "maxSteeringAngle" WheeledVehicleData datablock field really isn't used anymore (unless your vehicle model uses an animation for steering. In which case you would seem to also have to comment out the default "by-code" steering that is done during the setup of each wheels render matrix in WheeledVehicle::renderImage.)

The updateForces code and the renderImage code effectively assume (by not considering this) that a full steer (mSteering.x = +1 or -1) steers the wheel through an angle of 1.0 radian. This effective max turning angle is a little large for a modern road car (but perhaps not out of line for the "buggy" type vehicle) and might be contributing to some odd effects when the steering is full on (you can recover slides up to an amazing angle and full steer might cause the wheel to just skid rather than providing the expected lateral force.)

One difference between the steering angle that the physics is modeling and what the renderImage is rendering comes in from the updateForces use of "quadraticSteering". Here, the physics assumes that a half steer (mSteering.x = 0.5) steers the wheel 0.25 radians, while the renderImage turns it the full 0.5 radians. This is about a 14 degree difference between what the updateForces is modeling and what renderImage is drawing.

Another potential difference comes from some small angle assumptions/optimizations in the way the updateForces uses the steering to generate the angle of the wheel used for the physics. This is via the wheel->steering parameter that is usually 1.0 for steered wheels and 0.0 for non-steered wheels. In order to save some sin and cos calls, the code multiplies the sin of the quadratic steering angle by the wheel->steering to generate the vectors to point the tires lateral and longitudinal forces along. This approximation can cause differences between the physics steering angle and the renderImage steering angle for values of wheel->steering that aren't +/-1.0 or 0.0. For example, if you happened to use wheel->steering = 0.5 for some reason, the updateForces won't really be turning the wheel by 0.5 radians. It will be using cos(1.0 radian) and (sin(1.0 radian))*0.5 for calculating the vectors. With values of wheel-steering not equal to 1 or 0, this can really screw up the orthogonality of the lateral and longitudinal axes. Happily, the tireX and tireY vectors are re-normalized to minimize any effect from this on the magnitude of the forces. Still, the vector directions might be off by up to 10 degrees from a true 0.5 radian rotation. So if you really need to use a wheel->steering that isn't 1.0 or 0.0, you might consider upgrading this code.


I will likely add the quadratic steering system to my renderImage and also add use of the maxSteeringAngle datablock field to renderImage and updateForces so I can control the maximum steering.

#1
05/20/2009 (6:20 am)
Were you able to complete that quadratic steering system of urs ?