bullet dynamics

[NaN]

Well that's a difficult one. We also have slip oscillations in the trunk. But they don't break the traction control. My guess is that, as soon as the chassis has an angular momentum around the vertical axis it will oscillate.

angular momentum => angular velocity => tire slip => reaction force opposing the chassis angular momentum (tire friction)

For small slip = -(v - r * w) / v , constant tire load and constant angular speed w:
F = k * slip
m * dv / dt = - k * (v - r * w) / v
- k / m * t = r * w * ln(v - r * w) + v

The velocity is exponentially decreasing towards r * w (no slip case). There shouldn't be any oscillations actually. But I am assuming that w is constant. In fact it is something like: r * F = I * dw / dt.

Edit:
And like I said, it's not a problem in the trunk but in the bullet branch. So the interaction with bullet is complicating the whole story.

[NaN]

I removed all torques, forces from the chassis apart suspension, tire friction. I forced the surface normal to point upwards, locked the wheels and have been resetting chassis angular velocity at each external simulation step.

I've got the following readings for the F1-02:
- car is rotating in counterclockwise direction.
- slide ratios for the left wheels are negative for the right positive.
- slip angle is positive for the front and negative for the back.

So the bug has to be in the tire friction code I think.

Edit:
If I disable tire friction the rotation vanishes.

[joevenzon]

Some of the pacejka equation coefficients will cause the curve to shift left and right. Check out http://svn.vdrift.net/repos/pacejka and open the F1-02 car file. You'll notice things don't quite go through the origin. If you change a8 through a13 to zero then the lateral curve will go through the origin. You can make a similar change to the other curves. That might help you narrow down the problem, although ideally the physics sim would be stable enough to handle non-zero values in a8 through a13... however, that might not be practical and the effect is probably small.

How do the magnitude of the oscillations in the trunk compare to what you're seeing?

[NaN]

Will compare to trunk asap. Looking into branch code atm.

Edit:
Setting a8-a13 to zero didn't help. I think I've got a bug in the branch.

[NaN]

OK I got it.

The rotation is caused because the chassis is drifting to the left (don't ask me why). The F1-02 is heavier at the back so that the rear tires have more grip. The chassis starts to rotate around the rear tires physically fully correct. The effect is very small and doesn't affect the driving physics at all.

Now where do the oscillations come from? It is the f****ng wheel inertia + running the simulation at half of the trunk speed(600Hz)!!!! So increasing the rotational inertia of the 360 from 4 to 10 fixes the oscillation issues!

So I am going to merge back to trunk as long as it's hot.

[NaN]

There is no need to modify the wheel inertia if the simulation rate is increased from 60Hz(default) to 90-100Hz.

Does it make sense to allow the user to change the simulation rate in game? It would be an interesting feature. On the other hand it has serious influence on car dynamics and might be a source of bug reports.

[joevenzon]

My philosophy has been to run the physics rate as high as possible without destroying game performance on my (mid-level) machine. So I'd vote bump up the physics rate a little if the game still runs well with 3 AI cars present.

The trunk physics rate can be changed via a command line switch, because it can be useful for debugging, but having it as an actual feature can introduce complexities for recording replays, multiplayer (although we haven't had multiplayaer for a long time), etc.

[NaN]

If you want to test trunk rev2668 on your machine. You can modify the physics rate in collision_world.cpp.

Code:

void COLLISION_WORLD::Update(float dt)
{
    const int maxsubsteps = 7;
    const float fixedTimeStep = 1 / 60.0f;
    world.stepSimulation(dt, maxsubsteps, fixedTimeStep);
}

It is important to adjust the maxsubsteps if you change fixedTimeStep. Here it is setup for a minimum framerate 60/7 = 9fps ( dt < 0.12).

The internal rate is hardcoded to fixedTimeStep/10.

[joevenzon]

Unfortunately my copy of trunk is out of commission as I rewrite the scenegraph. I really should have done this in a branch, it's turning out to be a lot of work. I actually backed away from my plans to be more scenegraph-y and kept it as a pretty minimal scenegraph system but am applying lessons learned to increase performance.

[stan.distortion]

Just flicking through, probably nothing but there may be an oscillation in the damper functions, if there are it should affect the load on the contact patch, not sure how much they have changed though.
cheers

[NaN]

may be an oscillation

Yeah, I've been playing with the suspension lately. Like clamping the damping forces and adding a bump stop. Where do you notice the oscillations (car, track)?

should affect the load on the contact patch

The tire load is calculated from the suspension force(spring, damper, bump stop).

[stan.distortion]

Yeah, I've been playing with the suspension lately.

Noticed the contact patch being moved from the wheel centre to where it should be, cheers.
A lot of the stuff I was looking at could be messed up from me looking at it, hope not. And sorry about turning the c7 into a drunk hippo, that should only be in the config file.

may be an oscillation

That was just a feeling when I read it, I have no idea what the current state is. One could exist with using tables or arrays for damping rates, the resistance to movement from the damper should increase as speed increases but not speed*2=resistance*2. It could have a kind of 'car going straight through wall in fast crash' effect.
Last time I was looking at vdrift the spring and damping curves were added to the config, no idea what has happened since then.

The tire load is calculated from the suspension force(spring, damper, bump stop).

So the force on the contact patch can be far greater (or less) than the mass on that corner of the car?
cheers

[NaN]

Noticed the contact patch being moved from the wheel centre..

Well, the price is having the cars rolling over all the time. I am looking into that atm. Maybe a center of mass issue.

increase as speed increases

The damper friction is proportional to displacement velocity.

force on the contact patch can be far greater (or less) than the mass

Yep.

[stan.distortion]

Well, the price is having the cars rolling over all the time

I was at this and may be the cause of the sums being messed up. I was trying to get the body roll working and never spotted that. When I was at it I think the springs where compressing but the body wasn't rolling (staying more or less parallel to the ground) so maybe not but I wouldn't trust myself with it.

The damper friction is proportional to displacement velocity

But not directly proportional? The curve figures are still used in the config?
cheers

[NaN]

The curve figures are still used in the config?

Yes they are(the dampfactor):

Code:

T damp_force = -velocity * damping * dampfactor