## Raycast Vehicle and arcade drift

Murphy
Posts: 32
Joined: Fri Aug 31, 2007 6:36 am

### Raycast Vehicle and arcade drift

We are trying to allow our Raycast Vehicle to drift. That part is not hard. Lower the friction on the wheels and you are basically done.

The problem is that this behaves as one would expect and causes the player to lose control of the vehicle. We want the player to be able to maintain a drift for a long period of time and also be able to modify the drift by pressing left or right (to allow a more or less narrow drift around a corner for example).

We have tried a lot of different configurations and cannot maintain a drift for more then a second or two. Has anyone done anything like this before and have some suggestions?

colinvella
Posts: 26
Joined: Sat Feb 09, 2008 2:38 pm
Location: Malta
Contact:

### Re: Raycast Vehicle and arcade drift

You could try keeping high wheel friction (to prevent over-realistic drifting) and instead apply a centripetal force at the car's centre of mass, outward from the curved path while turning. The magnitude of this force could be calculated as a function of linear and angular speed and triggered after a given threshold (equivalent to a static fiction limit). This way, the car should not spin out of control but simply drift outwards from the curve.

Murphy
Posts: 32
Joined: Fri Aug 31, 2007 6:36 am

### Re: Raycast Vehicle and arcade drift

Thanks Colin!

A few questions before I try to implement this however.

Is centripetal force in your example the same thing as applyTorque()? And how is applyTorque() different from setAngularVelocity()?
Also, does applyTorque() use the center of mass to apply the torque around?

"outward from the curved path while turning". I am not sure how to translate that into code. How would I define the curved path?

Also, something I have been thinking about is what if the vehicle loses its grounding for a small period of time and one wheel makes contact with the ground before all the others. Wouldn't the friction of the one wheel cause the vehicle to spin?

Erwin Coumans
Posts: 4228
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

### Re: Raycast Vehicle and arcade drift

Drifting is not properly supported right now, once the tyres loose grip, the vehicle gets out of control.

It would be good to get this sorted though.

Have you checked out Jiglib's vehicle behaviour?
Thanks,
Erwin

Murphy
Posts: 32
Joined: Fri Aug 31, 2007 6:36 am

### Re: Raycast Vehicle and arcade drift

That makes sense Erwin. Nothing I have tried has resulted in correct behavior. We are going to try to fake it (at least for the time being).

I haven't looked into Jiglib yet. I will have to check out their vehicle code.

colinvella
Posts: 26
Joined: Sat Feb 09, 2008 2:38 pm
Location: Malta
Contact:

### Re: Raycast Vehicle and arcade drift

Murphy wrote: Is centripetal force in your example the same thing as applyTorque()? And how is applyTorque() different from setAngularVelocity()?
Also, does applyTorque() use the center of mass to apply the torque around?

"outward from the curved path while turning". I am not sure how to translate that into code. How would I define the curved path?

Also, something I have been thinking about is what if the vehicle loses its grounding for a small period of time and one wheel makes contact with the ground before all the others. Wouldn't the friction of the one wheel cause the vehicle to spin?
I'm not very familiar with the Bullet API, but what I meant is to apply a linear force at the car's centre of mass. If the way to do it is to use an applyTorque() function, and you could specify an application offset (r) and a force vector (F) separately, you would specify a zero offset to get a translational force with no "turning" component i.e. torque itself would be zero because r x F = 0 x F = 0.

By "outward from the curved path while turning", I intended sideways from the car's forward direction- assume the car's forward direction in body coordinates is towards positive X and Y is vertical.. then the force should be applied along +Z or -Z depending on your turning direction (CCW or CW around Y assuming a right-handed coord system).

 To avoid the car rolling over altogether, you could try lowering the car's CM artificially, even if it means beneath the car's chassis and into the terrain. That way it could act like a boat's keel and practically eliminate the chance of a rollover... just my 2c

hiker
Posts: 83
Joined: Tue Oct 24, 2006 11:52 pm
Location: Australia
Contact:

### Re: Raycast Vehicle and arcade drift

Hi Erwin,
Erwin Coumans wrote:Drifting is not properly supported right now, once the tyres loose grip, the vehicle gets out of control.

It would be good to get this sorted though.
Any chance of improving this in the near future? We have recently added some skidding to SuperTuxKart, and some people have complained about this
Have you checked out Jiglib's vehicle behaviour?
No, but I definitely don't want to use another physics lib - I like bullet

Cheers,
Joerg

Nico65
Posts: 8
Joined: Mon Apr 14, 2008 1:48 pm

### Re: Raycast Vehicle and arcade drift

I'm also interested. I'm trying to make a more or less realistic simulator out of Bullet, so applying a fictional force on the car doesn't look so good to me, I'm more thinking of working on the friction instead (the friction is simulated by impulses anyway). But I need to understand how it really works first

marshmonkey
Posts: 2
Joined: Wed Aug 20, 2008 10:57 pm

### Re: Raycast Vehicle and arcade drift

Erwin Coumans wrote:Drifting is not properly supported right now, once the tyres loose grip, the vehicle gets out of control.

It would be good to get this sorted though.

Have you checked out Jiglib's vehicle behaviour?
Thanks,
Erwin
our game Zero Gear uses Bullet's vehicle model and we run into this effect of the vehicle slightly losing grip and spinning 180 degrees immediately. So far we have been able to minimize this problem by building tracks that are flat or conform to the momentum of the vehicle as closely as possible - but it is still something that crops up at inopportune times. There is nothing as frustrating as racing down a track only to get a slight bit of air and spin around backwards!

Since you seem to have a handle on what is happening with the physics when this happens - is there anything you can suggest for us to explore on tweaking or adding to the vehicle model in order to curb this behavior?

hiker
Posts: 83
Joined: Tue Oct 24, 2006 11:52 pm
Location: Australia
Contact:

### Re: Raycast Vehicle and arcade drift

marshmonkey wrote:our game Zero Gear uses Bullet's vehicle model and we run into this effect of the vehicle slightly losing grip and spinning 180 degrees immediately. So far we have been able to minimize this problem by building tracks that are flat or conform to the momentum of the vehicle as closely as possible - but it is still something that crops up at inopportune times. There is nothing as frustrating as racing down a track only to get a slight bit of air and spin around backwards!

Since you seem to have a handle on what is happening with the physics when this happens - is there anything you can suggest for us to explore on tweaking or adding to the vehicle model in order to curb this behavior?
Well, I had a look recently, a similar (I think) behaviour happens in SuperTuxKart when one of the wheel does not touch the ground anymore - the other wheel is then pushing the kart only on one side, resulting in a sharp turn of the kart. And this obviously happens when the track is not flat anymore (or not smooth enough, has a kind of edge).

I was able to improve the situation somewhat by increasing the suspension rest length (see threadhttp://www.bulletphysics.com/Bullet/phpBB3/vie ... f=9&t=2398 for more details, though by now I've learned that my first suggestion is not really correcty ... but it helps in most situations like this ).

When I have time again I'll try to modify the raycast vehicle - either by pretending that all (rear) wheels touch the ground when at least one wheel touches the ground, or perhaps by simulating a three-wheeled kart - having only one rear wheel Of course, that's not realistic, but in STK I am not aiming at realism, so that approach might work. I can post an update here once I have time to work on the physics again.

HtH
Joerg

marshmonkey
Posts: 2
Joined: Wed Aug 20, 2008 10:57 pm

### Re: Raycast Vehicle and arcade drift

we kind of deduced that this was what was happening. One thing we have brainstormed but have not been able to test out yet is setting all 4 wheels friction values to 0 unless all 4 wheels are touching something. I have to think this would result in some emergent undesirable physics someplace else though.

Murphy
Posts: 32
Joined: Fri Aug 31, 2007 6:36 am

### Re: Raycast Vehicle and arcade drift

I wanted to report back and say that the method marsh describes above works pretty well. We change the friction values to 0 after all the wheels lose contact and bring them back to 1 over time (half a second) after all the wheels are touching again. This allows the kart to slide a bit after getting some air which helps a lot and just seems "right".

hiker
Posts: 83
Joined: Tue Oct 24, 2006 11:52 pm
Location: Australia
Contact:

### Re: Raycast Vehicle and arcade drift

Thanks for the update.

I tweaked the ray cast vehicle model somewhat to improve the 'one wheel not on floor' issue differently: if only one wheel on an axis touches the ground, I copy the raycast information from that wheel to the wheel not on ground, basically simulating that both wheels are on the ground (with the same distance). This solved the problem of the kart suddenly rotating on the spot if one of the rear wheels loses contact with the track for us (i.e. supertuxkart):

Code: Select all

``````   // Work around: make sure that either both wheels on one axis
// are on ground, or none of them. This avoids the problem of
// the kart suddenly getting additional angular velocity because
// e.g. only one rear wheel is on the ground.
for(i=0; i<4; i+=2)
{
if(m_wheelInfo[i].m_raycastInfo.m_isInContact &&
!(m_wheelInfo[i+1].m_raycastInfo.m_isInContact))
{
m_wheelInfo[i+1].m_raycastInfo = m_wheelInfo[i].m_raycastInfo;
}
if(!(m_wheelInfo[i].m_raycastInfo.m_isInContact) &&
m_wheelInfo[i+1].m_raycastInfo.m_isInContact)
{
m_wheelInfo[i].m_raycastInfo = m_wheelInfo[i+1].m_raycastInfo;
}
}   // for i=0; i<4; i+=2
``````
Cheers,
Joerg

Murphy
Posts: 32
Joined: Fri Aug 31, 2007 6:36 am

### Re: Raycast Vehicle and arcade drift

Thanks for the tip!

I placed that code right at the start of btRaycastVehicle::updateVehicle() (is this where you placed it?) and it seems to help. We are now using your method with our wheel friction removal method and it is getting better and better with more tweaking.

hiker
Posts: 83
Joined: Tue Oct 24, 2006 11:52 pm
Location: Australia
Contact:

### Re: Raycast Vehicle and arcade drift

Murphy wrote:Thanks for the tip!

I placed that code right at the start of btRaycastVehicle::updateVehicle() (is this where you placed it?)
I put this code just after the call to rayCast (in updateVehicle):

Code: Select all

``````      //
// simulate suspension
//

int i=0;
for (i=0;i<m_wheelInfo.size();i++)
{
btScalar depth;
depth = rayCast( m_wheelInfo[i]);
}

// Work around: make sure that either both wheels on one axis
...
``````
It's not really related to drifting, but I tweaked one more thing: I added an artifical force pulling downwards whenever a wheel is not on the ground. That helped a lot with downhill parts of a track which are a bit too steep to work with realistic physics (i.e. kart is falling since the wheels are not on the ground, and therefore you can't steer), but which track designer thought to be smooth enough. You could probably get away with increasing the gravity as well, but that would require re-tweaking of a lot of other parameters. This is in btRaycastVehicle::upateSuspension:

Code: Select all

``````        for (int w_it=0; w_it<getNumWheels(); w_it++)
{
btWheelInfo &wheel_info = m_wheelInfo[w_it];

if ( wheel_info.m_raycastInfo.m_isInContact )
...
else
{
// A very unphysical thing to handle slopes that are a bit too steep
// or uneven (resulting in only one wheel on the ground)
// If only the front or only the rear wheels are on the ground, add
// a force pulling the axis down (towards the ground). Note that it
// is already guaranteed that either both or no wheels on one axis
// are on the ground, so we have to test only one of the wheels
wheel_info.m_wheelsSuspensionForce = -m_track_connect_accel*chassisMass ;
}
``````
As I've said, that's a big cheat, but it helped us a lot.

Cheers,
Joerg