bullet dynamics

[CrystalH]

Actually I found that box penetration thing too, (behaves like an explosion).
I created lately a heightfield from 6 sinus functions and it happens there more often.
I thik with F1-02 it happens everywhere.
With other cars i've seen it on dirt-3. (any bigger height change during fast drive will cause it).

I resolved this behaviour by replacing car chassis box with 4 capsules. This way it disappeared. Capsules collide better, probably because they have smooth normals.
Anyway i put capsules so they don't collide with wheels (didn't have time to find where to change collision group, so wheels won't collide on them). Funny thing this way is okay, but you can drive with car upside down on track .

I also added some dynamic objects to world. They behave good with car, but the game crashes in several places when a wheel is on a dynamic object (NaN's asserts in tire computations, antirollbar).

[NaN]

Thanks for testing CrystalH!

a heightfield from 6 sinus functions

A heightfield mesh not a procedural track right?

Capsules collide better

Do you mean there are no explosions any more? I've been thinking about replacing the box with a collision mesh.

I also added some dynamic objects to world.

The CastRay method in COLLISION_WORLD only works for static objects atm but should still return a valid contact point. I will look into this.

[CrystalH]

The heightfield was created in bullet with TriangleMeshShape with btTriangleIndexVertexArray (like in bullet demos).
So far i've tested i haven't seen any explosion. The car also bounces more realistically with terrain when i.e. flipping or landing.
I think a mesh for chassis would be more fit for geometry, but it seems like using few capsules would bring a better collision reaction.

[stan.distortion]

Maybe suspension specific stuff should get another thread?

2) Because the wheels are following the surface we have very fast wheel displacements (0.01m/ms => 10m/s) from time to time. At such displacement speeds the shock absorbers determine the suspension behavior completely. The damping forces can exceed 100000N with spring forces of about 7000N at the same time!!! The problem is not that pronounced in the trunk. It might be related to the track collision object in the branch. Not sure what fails here. A quick fix would be to either clamp the displacement velocity or decouple the wheels from the surface(wheel stiffness).

This is correct but at the mo the physics speed will effect it. Seen speeds over 50m/s, that's about right for a car with solid tires and real dampers release the kind of forces this would generate (they would explode otherwise).
The displacement from the previous position needs to be taken into account so physics speed doesn't affect the suspension model (looking into that, same problem the TCS had and think there may be other things affected).

[NaN]

physics speed will effect it

Yeah, that is what I haven't considered in the quoted text. 100000N damping forces don't sound that abnormal given an action time dt=1ms.

[stan.distortion]

Something else that may be an issue, the force exerted by the dampers on the tire contact patch at the moment of calculation is directly related to velocity, the force from the dampers passed as momentum to the body mass is the force multiplied by the time since the last calculation.
Going through what does what at the mo but there will need to be different values for frictional and momentum routines, could already be doing this, seem to remember there is some unused code there.

[NaN]

The suspension force (spring, damper, antiroll force) is applied to the tire patch to calculate tire friction. The opposing reaction force(normal force, tire friction) is applied to the chassis.

The integrator uses the accumulated forces to update the momentum: momentum = momentum + force * dt;

Edit:

there will need to be different values for frictional and momentum routines

Could you elaborate on this?

[stan.distortion]

The integrator uses the accumulated forces to update the momentum: momentum = momentum + force * dt;

Thats the bit I was looking for, guessing its part of the integrate1 and 2 routines.
Didn't think that could be right as everything would be screwed up if it was.

there will need to be different values for frictional and momentum routines

Was thinking the wrong way around, that each function worked out how much momentum was to be transferred to the body and summing them up at the end instead of getting the forces and turning them into momentum at the end. Correct me if I got that wrong please, I'll be referring to it again
2672 good, C7 and rouen very happy together, cheers.
With the rolling over problem, there isn't any chance of a divide by 0 in the suspension forces? Seems like everything goes wrong when the suspension velocity and displacement hit their limits and are zeroed.
cheers

[NaN]

getting the forces and turning them into momentum at the end

Yes.

divide by 0 in the suspension forces

There are no divisions in the suspension code except 1/dt.

everything goes wrong when the suspension velocity and displacement hit their limits and are zeroed

The velocity depends on the displacement:

Code:

velocity = (displacement_new - displacement) / dt;

So there is in fact a problem with the damping. It will decrease/vanish when the displacement is over the limits(is clamped). Interesting.

[stan.distortion]

Testing at the mo, had to sanitise the C7
Damping falling to zero should be ok but rebound damping seems to be a problem, mentioned it in the other thread, briefly it goes into large positive values (thousands) due to no unsprung weight.

[NaN]

no unsprung weight

Yeah, I tried to add weight to the wheels. But it always resulted in chassis oscillations.

[stan.distortion]

I tried to add weight to the wheels

That would be a huge step forward but would probably need something like the spring and damper rates for the tires otherwise the suspension loads would be huge. Not sure if the current tyre calculations do this already.
cheers

[NaN]

huge step forward

It would also allow to replace the wheel rays by proper tire collision geometry.

spring and damper rates for the tires

Do you have some numbers?

[stan.distortion]

A simple curve much like the bump stops for spring and a single figure for damp would do the job but not with any great accuracy. It would need to be part of the pacejka calculations to be any way accurate as it relates directly to the contact patch.
It should already be in the pacejka formula, not sure though, going to read up on them.
You already did quite a bit with them? Remember seeing graphs in a thread, will have a look.
cheers

[NaN]

It should already be in the pacejka formula

The problem is that the pacejka formula wants a normal force from you and returns the friction. It would be cool if there was a formula to put tire vertical deformation in and get normal, friction force out.