bullet dynamics

[joevenzon]

What I could do is to stabilize the branch, add unsprung mass and merge to trunk this weekend(cylinder wheels, suspension geometry would be missing). If Joe is OK with it?

I'm okay with you merging the branch back into trunk whenever you think it's stable and ready.

[NaN]

Update:
The autoclutch works correctly. It is the TCS that is broken since the switch to bullet. I moved the suspension back into 600Hz code. It runs much smoother(stable). Tried to simulate the unsprung mass using velocity verlet. It didn't work. The problem are the external constraints: maximum travel, wheel displacement. Have to figure out how to add them to the integrator.

[sebiastisch]

In bullet they first predict the unconstrained motion, than calculate constraint violations, calculate new (angular/linear)velocitys, which fulfill those constraints and integrate with them again.

Maybe that helps.

[NaN]

predict the unconstrained motion

That's what I've been doing too. It works quite well as long as the suspension is not too stiff. But the f1-02 with its ultra stiff suspension is wobbling visibly

Code:

T Update(T dt, T ext_displacement)
    {
        // clamp external displacement
        overtravel = ext_displacement - travel;
        if (overtravel < 0)
            overtravel = 0;
        if (ext_displacement > travel)
            ext_displacement = travel;
        else if (ext_displacement < 0)
            ext_displacement = 0;

        // predict new displacement
        T new_displacement = displacement + velocity * dt + 0.5 * force * inv_mass * dt * dt;

        // clamp new displacement
        if (new_displacement > travel)
            new_displacement = travel;
        else if (new_displacement < 0)
            new_displacement = 0;
        
        // calculate derivatives
        if (new_displacement < ext_displacement)
        {
            force = GetForce(ext_displacement, velocity);
            velocity = (ext_displacement - displacement) / dt;
            displacement = ext_displacement;
        }
        else
        {
            T new_force = GetForce(new_displacement, velocity);
            velocity = velocity + 0.5 * (force + new_force) * inv_mass  * dt;
            force = new_force;
            displacement = new_displacement;
        }

        assert(!isnan(velocity));
        assert(!isnan(force));

        return -force;
    }

Another issue is tire angular oscillation due to bullet vdrift synchronization. That's why the TCS is broken.

To tackle both problems I've decided to switch to btRigidBody for chassis dynamics and to implement the suspension as a hinge constraint. Unfortunately this is somewhat time consuming as I have to rewrite bigger parts of cardynamics.

[charlieg]

Now that this is settling down, isn't it time for a new release? 8)

Or at least to plan what is planned for the next release...

[NaN]

Well ...

I am not sure if we've got anything to release.

The bullet branch will take another week or so. As I am not satisfied with the current state and decided to move suspension and wheels into bullet. So we will have a constraint based suspension and rigid body wheels(hopefully).

Another thing to consider is that, this are simulation related modifications. So eventually the casual player might not notice any difference to the previous release.

There are a number of things on my personal todo list(after I am done with the simulation part):
- dynamic sky, daylight
- smooth particles(smoke, dust, backfire)
- dynamic track objects => track objects (and car parts) library
- skidmarks ?

PS: The suspension prototype in blender :lol:

[joevenzon]

Still though, once the bullet branch is back into trunk and you like where it is, we should do a release. There's also the dynamic reflection change, and plus it'd be nice to have a lot of people taking a look at the bullet physics to see if they find problems.

[joevenzon]

Also... I looked through the bullet branch and it looks like the car.cpp function CopyPhysicsResultsIntoDisplay is mostly unchanged, it just gets positions and orientations from the dynamics member. Is that correct? I was going to start redoing the scenegraph system in trunk (or maybe a branch off of trunk) but didn't want to if it was going to require rework once you integrated bullet back into trunk. What do you think?

[NaN]

once the bullet branch is back into trunk and you like where it is, we should do a release

OK. But this might happen quite soon. :wink:

it just gets positions and orientations from the dynamics

Yep, this cardynamics functions should be used for graphics (won't change):

Code:

// graphics interface, interpolated!
    void Update(); // update interpolated chassis state
    const MATHVECTOR <T, 3> & GetCenterOfMassPosition() const;
    const MATHVECTOR <T, 3> & GetPosition() const;
    const QUATERNION <T> & GetOrientation() const;
    MATHVECTOR <T, 3> GetWheelPosition(WHEEL_POSITION wp) const;
    MATHVECTOR <T, 3> GetWheelPosition(WHEEL_POSITION wp, T displacement_percent) const; // for debugging
    QUATERNION <T> GetWheelOrientation(WHEEL_POSITION wp) const;
    QUATERNION <T> GetUprightOrientation(WHEEL_POSITION wp) const;

Edit: So please feel free to modify/rewrite the scenegraph.

[NaN]

Hey, I've just noticed that we've got no tire width in the car config files!? Will have to use tire mesh AABB I guess.

[joevenzon]

FYI, zimluura is working on adding dynamically generated tire meshes based on tire data (including width) in the config file.

[NaN]

Status report:

I failed to setup a constraint based suspension.
Getting the hinge stiff enough to carry a 1500 kg chassis with 9.81m/s^2 gravity is a problem. Increasing the number of iterations in the constraint solver from 10(default) to 40 has shown some improvement. But I am not sure if we can afford to run it at this speed. More testing is needed here. The values for the spring constants had to be unrealistically high(like one order of magnitude above the real world value). I may have messed up this one using a angular spring constraint. The usual tuning tips have been to adjust inertia, masses till the simulation looks plausible. So I think bullet is not meant for physically correct simulation.

So I rolled back to wheel ray simulation. It currently has two bugs to be fixed:

1) The car oscillates around vertical axis when at rest due to tire friction. It is not visible, but it manifests as oscillating slip values. Thats why the TCS is causing problems with some cars(360). Not sure how to fix.

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).

As soon as this issues are resolved(or worked around) I am going to merge the branch back. So that we can release it.

[NaN]

By adding a vertical offset to the collision box I think I found the reason for the second bug:



It looks like the wheel ray cast fails sometimes on both the collision mesh and the track patch. Will try to fix it.

[NaN]

Second bug fixed, one left.

[joevenzon]

What's the source of the oscillation in the first bug?
EDIT: nevermind, you already said tire friction

Why is tire friction making it oscillate vertically? I'd think it would make it oscillate forward/back.