bullet dynamics

[NaN]

It could be the collision box. I should change the way it is calculated. You can play with the vertical collision box offset in cardynamics.cpp line 651.

Code:

const MATHVECTOR <T, 3> verticalMargin(0, 0, 0.3);

[stan.distortion]

Will give it a try.
Getting an oscillation on the start of the same track with the 350Z now, looking for any connections.
Had some weirdness with wheel positions in the .car file too, the MI or 350Z sink into the track if lowered. The wheel heights are set only in the .car file or they have to match something else?

[NaN]

MI or 350Z sink into the track if lowered

The do it at the start right? I am looking into AlignWithGround() function atm, need it for rollover recovery too.

The wheel rays are shot from the top of the wheel (wheel position + radius) downwards. If the wheels are below the track no hits are created the car bottoms out.

Edit: I think I am going to change it to a fixed position inside the collision box. So it doesn't depend on the wheel position.

[stan.distortion]

The do it at the start right?

At the start and as far as I got after, a few hundred meters at most.

[alex25]

i see some kind of bouncing with the F1-02 on pretty much any track (at least the ones that i tested). just start the game and the car kind of shakes a bit. the shaking persists while driving. i tried modifying the vertical margin to 0., but then the car didn't move at all. if i made it 0.001 then the car really bounced around once i got it going. something is wrong with the collision logic here.

--alex--

[alex25]

again at the start with the F1-02 car in neutral and with the brakes fully applied just watch the car slowly drift around. this is with the latest version from svn.

[NaN]

shakes a bit

F1-02 has a very small momentum of inertia, mass but very stiff suspension. The suspension implementation is causing problems here.

modifying the vertical margin to 0

Vertical margin of 0 means the collision box encompasses the car with the extended wheels. It won't be able to move at all. A small margin means leads to interferences with bullet collision resolution and suspension calculation.

car slowly drift around

Will look into this.

To be honest the suspension code is a fragile beast I've been struggling with for weeks now.

[stan.distortion]

I see bullet can do springs, the place I saw that mentioned new features in version 2.75 so maybe it's a recent thing. Any thoughts on implementing the springs and dampers as a bullet component?
Also, import and export of rigid bodies seems straightforward, would it be possible to have, say, a complete wheel (including skin) as a loadable .bullet file? If so, would this also work for other objects (ie, wishbones, driveshafts, panels etc.)?
cheers

[NaN]

The code for bullet based suspension is there (cardynamics.cpp). It is incomplete though. The problem with bullet spring/joint constraints is to get them to carry a 1500kg car. They always broke for me. I am not sure if they are meant to be used for such stiff systems.

[NaN]

I've tested a number of collision shapes for the car body, (even wrote one by myself :lol: ) trying to resolve the car track collision issue(very noticeable on Ruudskogen).

I think I understand why it happens. The car having a high speed (>30m/s) hits the track(suspension bottoms out while braking or track has a slope) at a shallow angle. The penetration will be 30m/s / 60Hz = 0.5m in the worst case.

What I don't know at the moment is how to adjust/manipulate the contact resolution in such a way that it doesn't catapult the car into the air. Increasing collision margin, simulation speed is of limited help the issue remains.

[stan.distortion]

Is it simple to detect when it happens? Could the body be removed from the world, re-positioned, then replaced and the momentum calculated and applied to the everything affected by the move?
I'm at suspension forces at the mo and have been thinking about doing the same kind of thing, rigidly attaching the wheels to the body, getting the forces from c of g to contact patch, then re-positioning the wheel and re-distributing the forces. Kind of a bodge but bullet doesn't seem to like solid stuff much.
Something else with the collision points, the .car files don't seem to have a fixed zero point. I'm guessing the .car origin relates to the body (the 3d shape) origin, is it possible to change that without having to change every car? If not, is it worth adding a point at which the car bottoms?

[NaN]

Could the body be removed from the world, ...

Ouch! That sounds like a PITA. I added bullet dynamics into VDrift to deal with collision resolution and stuff. Because it actually does it better than VDrifts own implementation (see revision < 2659). Before my changes bullet was used for collision detection only and the collision response was done in VDrift. So you propose to roll back to the previous code.

[NaN]

Give me some time to do more testing. I am not yet ready to give up on bullet.

[stan.distortion]

Because it actually does it better than VDrifts own implementation

After seeing so may constraints that aren't and so many impenetrable bodies penetrated (....could have put that better...), I'd have to question that.
Bullet does a great job of movement of stuff but it doesn't seem to do such a great job of movement of stuff attached to other stuff.

Give me some time to do more testing. I am not yet ready to give up on bullet.

Wouldn't dream of suggesting that, it does a great job and, with development, will handle constraints and penetration just as well as it does momentum.
For now, even with rigid suspension, there will be a lot of floating around, 2 rigid bodies coming into contact behave as though they are made of rubber.
Taking the wheels and body as a solid mass for bullets interpolation will simplify things, I was looking at 16 more rigid bodies and 28 joints per car for a simple double wishbone setup.
Detaching the wheels, recalculating and re-attaching will sidestep bullet's spongieness and the momentum re-calculations are the same as the suspension geometry calculations as they are all acting between the car rigidBody c of g and the surface.
Something similar has to be done with the tyres anyway and would benefit from being part of the same routine. The pacejka calculations seem beyond bullets limits and need to be done with better resolution than the positional data from bullet's collision handling.
A putTheWheelsWhereTheyShouldBe routine to do the lot is what I'm suggesting. For now it can just be 4 (+/-) wheels stuck on the corners of a box and a routine to use the existing pacejka calculations and apply the forces generated to the body.
Once that works ok the detaching the wheels and re-attaching them to allow steering and suspension could be done and then the re-positioning of the wheels on the track surface, the re-positioning can be eased in as a percentage of the calculated value which should help damp out oscillations.
I'm going through to see how to do this at the mo, the CARDYNAMICS::UpdateBody routine looks like the spot to break into.
VDrift's appeal to me is as an accurate simulation and that's the aspect I'm making these suggestions from. It's also great fun and would be even more fun with extra features, bullet should allow more time for developing that aspect, I would like to do what I can whichever way.
cheers

[NaN]

VDrift's appeal to me is as an accurate simulation and that's the aspect I'm making these suggestions from.

We are aiming for the same goal here.

Taking the wheels and body as a solid mass for bullet

Now I begin to understand what you mean. So you propose the wheels to be a part of the car collision shape, but to update/calculate their relative position in VDrift? I think it would work. But we need to make sure that it doesn't break bullets collision detection/resolve.