bullet dynamics

[stan.distortion]

But we need to make sure that it doesn't break bullets collision detection/resolve.

That's what I would be worried about. There would be 2 physics systems running in parallel and they might not play well together.

So you propose the wheels to be a part of the car collision shape, but to update/calculate their relative position in VDrift?

Exactly. I'm getting my head around btCompoundShape now, should have the wheels falling off by this evening

[NaN]

On a side note, bullets offers callbacks to hook into any stage of its pipeline. So one could use the pacejka friction model for the wheel contacts(wheels considered to be fixed(part of the body). There is still the issue with suspension force calculation. I am not sure if it is possible to retrieve it from bullets contact solver.

falling off by this evening

Would love to see some code.

Edit:
Had a look at the code. The tire friction can be passed as a friction constraint(not in the callback). The callbacks won't give you enough information implement the friction, suspension I think. Will look into it.

[NaN]

I did some more tests on car collision box vs track geometry collisions. Bullet has no problems resolving collisions with flat surfaces like btStaticPlaneShape or a flat mesh. The car(360) didn't bounce due to weight transfer(braking) like it does at some of vdrift tracks even in flat sections. Looks like I'll have to look into bullet(have been trying to avoid this).

[stan.distortion]

Bullet has no problems resolving collisions with flat surfaces like btStaticPlaneShape or a flat mesh.

Was wondering about something when I saw the body was a compound shape, could you stick a flat plane on the bottom of the car?
Nothing happening fast with the suspension but its getting there.

[stan.distortion]

Useful link that came up in an ODE thread:
http://www.continuousphysics.com/Bullet/...tated.html

[NaN]

could you stick a flat plane on the bottom of the car

The current bottom is quite flat(btBoxShape). But I'll try just out of curiosity.

p.s.
There is a global variable gContactBreakingThreshold. I wonder how it influences the hinge suspension? Will do some testing eventually.

[stan.distortion]

Will have a look at that, found quite a bit looking through ODE treads on improving bullets hinges though. m_limitSoftness and m_stopERP in btGeneric6DofConstraint.h are the main ones.

[NaN]

Actually I am busy with other stuff here but ....

http://bulletphysics.org/Bullet/phpBB3/v...ion#p17189

http://bulletphysics.org/Bullet/phpBB3/v...f=9&t=5019

Edit:
The second one is only for angle > pi. Not an issue for us I think.

[stan.distortion]

svn 2695.
First a note on where I have got to. Nowhere. Gone full circle and basically using the same code except using the wheel centres as the btGeneric6DofSpringConstraint. This is giving a rigid linear constraint, not sure how well it will handle axial but looks ok. Going to map geometry onto then from CARDYNAMICS::Update() once I get the typedConstraint callbacks figured out (added them to collision_world, figuring out how to use them).
Will use simple linear suspension to begin with and map suspension and steering geometry onto them later.

Ok. With 2695 the car is hopping around and ends up flipping over. With the joints at the hinge points its ok so it may sort it's self out once the suspension is in.
cheers

[NaN]

using the wheel centres as the btGeneric6DofSpringConstraint

So you have a slider instead of a hinge, right?

[stan.distortion]

So you have a slider instead of a hinge, right?

Slider for the vertical movement (no static friction ), a rotational axis for the steering and another for the wheel.
Can simulate any suspension geometry with a single 6Dof joint, just using a single slider for now to see how it goes.

[CrystalH]

I created a Heightfield in bullet through btHeightfieldTerrainShape. It caused a crash on collision, and this was because m_shapeId isn't defined for all shapes except btTriangleMeshShape (says bullet comment).
Adding this if in MyRayResultCallback::addSingleResult resolved the problem:

Code:

if (!rayResult.m_localShapeInfo)
    m_shapeId = 0;
else  // only for btTriangleMeshShape
    m_shapeId = rayResult.m_localShapeInfo->m_shapePart;

This was also the problem with crash on dynamic objects (not the asserts).

I've also found that CAR::GetTireSquealAmount produces squeal sounds while in air and emits particles. (I had funny ribbon trails in air also). By adding this check at beginning resolved the issue:

Code:

    float d = dynamics.GetWheelContact(WHEEL_POSITION(i)).GetDepth() - GetTireRadius(WHEEL_POSITION(i));
    if (d > 1.f || d < 0.f)  // not on ground
        return 0;

This check could be also somewhere else to not allow driving upside down.

[NaN]

GetTireSquealAmount produces squeal sounds while in air and emits particles

This was a bug in collision world. I've been assigning asphalt surface as default. It has been fixed some time ago.

m_shapeId isn't defined

Thanks, haven't looked into dynamic objects yet.

[stan.distortion]

Getting on ok with this, albeit very slowly. Have got my head around bullet constraints and have steering and springs working ok, working on dampers and brakes/driving torque at the mo.
Grip calc's where mentioned before, I'm about to head down this road. Planing on using the tyre rigidBody's grip variable to see how it goes, is there anything I should bare in mind?
cheers

[NaN]

tyre rigidBody's grip variable

Do you mean m_friction? You would have to adjust the value depending on current slip (maybe using CF_CUSTOM_MATERIAL_CALLBACK). But you need the tire normal force(maybe from the suspension constraint) to calculate it. Another problem is the simulation rate. The wheels are simulated with 600Hz now and this is pretty much the minimum rate I think. As we already have problems with low wheel inertia (< 5.0).

I am curious about your constraint setup. Do you mind to check in your code(maybe wrapped into #ifdef _BULLET_).