WheeledVehicle class bug and solution
by Duncan Gray · in Torque Game Engine · 11/04/2005 (9:35 pm) · 9 replies
In void WheeledVehicle::extendWheels()
existing situation
A ray is cast to check the distance from the hub to the ground so that the engine knows how far to extend the spring and where to render the wheels in relation to the vehicle.
Problem
When the vehicle takes a hard landing and the spring upward force is less than that required to overcome the downward force of the vehicle, the wheel->extension is set at the maximum point of upward travel, which is correct. However, the vehicle collision hull has not yet collided with the ground so the vehicle continues to travel downward until it does collide with the ground. Meanwhile the wheel is being rendered partially underground which tends to look, well, dumb...
Its very noticeable on vehicles with BIG wheels.
Proposed solution
OK, now collision code is not something I'm on speed with. This may or may not be a simple question.
(a) How do I call a collision event
(b) Having called the event, surely it needs co-ordinates as to where the collision took place so that the rigidbody can respond correctly
existing situation
A ray is cast to check the distance from the hub to the ground so that the engine knows how far to extend the spring and where to render the wheels in relation to the vehicle.
Problem
When the vehicle takes a hard landing and the spring upward force is less than that required to overcome the downward force of the vehicle, the wheel->extension is set at the maximum point of upward travel, which is correct. However, the vehicle collision hull has not yet collided with the ground so the vehicle continues to travel downward until it does collide with the ground. Meanwhile the wheel is being rendered partially underground which tends to look, well, dumb...
Its very noticeable on vehicles with BIG wheels.
Proposed solution
wheel->extension = (rInfo.t < ts)?0: (rInfo.t - ts) / (1 - ts);is the line where the wheel extension is calculated. I propose calling a collision event when ever (rInfo.t < ts) which would stop the vehicle traveling down any further, as would happen in real life. When your vehicle springs bottom out, you feel the impact. The vehicle does not continue to travel down until the chasis hits the ground.
OK, now collision code is not something I'm on speed with. This may or may not be a simple question.
(a) How do I call a collision event
(b) Having called the event, surely it needs co-ordinates as to where the collision took place so that the rigidbody can respond correctly
About the author
#2
11/05/2005 (4:55 am)
I've been noticing that effect lately but didn't know where to look for a solution. Thanks for posting this. I may have to wait for an official fix (final 1.4) but it's good to know others have seen it and the remedy is in the works.
#3
In void WheeledVehicle::updateForces(F32 dt) find
// Spring force & damping
F32 spring = wheel->spring->force * (1 - wheel->extension);
and just below it add
I looked in vehicle::resolveCollision then in Rigid::resolveCollision to extract the above code and apply it to the hub whoose spring has bottomed out.
Perhaps Clark or another expert can verify that its technically correct. Visually, it works for me and solves the problem I experienced.
11/05/2005 (12:10 pm)
I have a working fix for this problemIn void WheeledVehicle::updateForces(F32 dt) find
// Spring force & damping
F32 spring = wheel->spring->force * (1 - wheel->extension);
and just below it add
if(wheel->extension == 0) //spring fully compressed
{
// Apply impulses to the rigid body to keep it from
// penetrating the surface.
F32 n = -mDot(localVel,Point3F(0,0,1));
if (n >= 0) {
// Collision impulse, straight forward force stuff.
F32 d = mRigid.getZeroImpulse(r,Point3F(0,0,1));
F32 j = n * (1 + mRigid.restitution) * d;
mRigid.force += Point3F(0,0,1) * j;
//mRigid.force += spring;
}
}I looked in vehicle::resolveCollision then in Rigid::resolveCollision to extract the above code and apply it to the hub whoose spring has bottomed out.
Perhaps Clark or another expert can verify that its technically correct. Visually, it works for me and solves the problem I experienced.
#4
But it will be in a future release.
11/05/2005 (1:59 pm)
This won't be fixed in 1.4; we're building final installers and demos so it's not a good time for further code changes. :)But it will be in a future release.
#5
Yeah, I tried out a wheeled vehicle today with the final 1.4 and still noticed the tire issue. It's not a problem though. It looks like Duncan has a good solution, so I'll try that. It should be pretty easy to implement. By the way -- thank you for all the hard work on 1.4.
@Duncan
Thanks for the code fix for this. I'll give it a try.
Edit: For anyone interested in this, the fix is quick, easy and works great.
11/25/2005 (5:28 am)
@BenYeah, I tried out a wheeled vehicle today with the final 1.4 and still noticed the tire issue. It's not a problem though. It looks like Duncan has a good solution, so I'll try that. It should be pretty easy to implement. By the way -- thank you for all the hard work on 1.4.
@Duncan
Thanks for the code fix for this. I'll give it a try.
Edit: For anyone interested in this, the fix is quick, easy and works great.
#6
Looking at the drawing below
There are TWO additional issues being addressed here:
(1) another reason for the wheel being rendered partially below ground
(2) vehicle not slowing down on hills
Concept A shows the current single ray cast used to calcualte where to render the wheel. As you can see, it fails miserably when there is a slope with the wheel being drawn partially below ground. It should be possible to calculate an adjustment to the wheel spring length to lift the rendered wheel in proportion to the surface inclination.
The purple force vector should also be calculated and applied to the vehicle to slow it down in proportion to the surface angle.
Concept B might be better for very large wheels where the surface is not straight as depicted, but curved or rough. Multiple ray casts might have better luck at determining exactly where the wheel contacts the ground to render it correctly and also to calculate the "speed adjust" force due to the incline.
I have not implemented this yet but plan to get round to it. If someone wants to do the maths in the meantime you can save me some time and post the formulas.
11/25/2005 (1:59 pm)
The vehicle class has another bug/missing feature in update forces where no consideration is taken for the slope of the terrain. A vehicle should slow down when going uphill but this vehicle class never knows it's going uphill because it has no data input relating to that.Looking at the drawing below
There are TWO additional issues being addressed here:
(1) another reason for the wheel being rendered partially below ground
(2) vehicle not slowing down on hills
Concept A shows the current single ray cast used to calcualte where to render the wheel. As you can see, it fails miserably when there is a slope with the wheel being drawn partially below ground. It should be possible to calculate an adjustment to the wheel spring length to lift the rendered wheel in proportion to the surface inclination.
The purple force vector should also be calculated and applied to the vehicle to slow it down in proportion to the surface angle.
Concept B might be better for very large wheels where the surface is not straight as depicted, but curved or rough. Multiple ray casts might have better luck at determining exactly where the wheel contacts the ground to render it correctly and also to calculate the "speed adjust" force due to the incline.
I have not implemented this yet but plan to get round to it. If someone wants to do the maths in the meantime you can save me some time and post the formulas.
#7
The raycast down is oriented to the vehicles current orientation. So if the vehicle was vertical, then the "down" raycasts that the wheels perform would be horizontal.
If you render the cast rays with a few opengl calls you can see what it's doing a bit easier.
So normally, the ray cast that the wheel is actually doing is somewhere between the two pictures you have above. Because the overall orientation of the vehicle will not be the same as the orientation needed at the wheel itself.
The force that would slow down a vehicle going uphill is gravity, which is already applied. I guess you have less friction as well because gravity is not pulling you into the surface as much. This must be the missing force. ;)
11/25/2005 (5:48 pm)
Some random babbling about this:The raycast down is oriented to the vehicles current orientation. So if the vehicle was vertical, then the "down" raycasts that the wheels perform would be horizontal.
If you render the cast rays with a few opengl calls you can see what it's doing a bit easier.
So normally, the ray cast that the wheel is actually doing is somewhere between the two pictures you have above. Because the overall orientation of the vehicle will not be the same as the orientation needed at the wheel itself.
The force that would slow down a vehicle going uphill is gravity, which is already applied. I guess you have less friction as well because gravity is not pulling you into the surface as much. This must be the missing force. ;)
#8
I forgot to mention that my vehicle is a special case which is always upright regardless of the terrain slope, due its internal gyroscope.
Under those circumstances I have now applied the surface.normal to the spring force which solves part 2 of the problem. The vehicle now slows down on uphills and free-wheels down hills etc as expected. I should also tweak the static friction value in the datablock to let it slide down very steep slopes.
So, the standard vehicle DOES slow down on hills Just my vehicle did not but now it does.
The other render problem is still an issue for me but Ill look into it in due course.
11/25/2005 (10:34 pm)
@Brian, thanks for the input. You are correct with respect to the standard vehicle. I just rechecked starter.racing and that vehicle does roll down a hill if you park it on a hill with the wheels facing down the hill. It's because, as you say, the spring force is 'up' with respect to the vehicle, which would be angled on the slope.I forgot to mention that my vehicle is a special case which is always upright regardless of the terrain slope, due its internal gyroscope.
Under those circumstances I have now applied the surface.normal to the spring force which solves part 2 of the problem. The vehicle now slows down on uphills and free-wheels down hills etc as expected. I should also tweak the static friction value in the datablock to let it slide down very steep slopes.
So, the standard vehicle DOES slow down on hills Just my vehicle did not but now it does.
The other render problem is still an issue for me but Ill look into it in due course.
#9
11/28/2005 (6:19 am)
OziMan... Thanx for this fix... It really helps 
Associate Kyle Carter