Physics Simulation Forum

I have a demo vehicle demo, you can find it here:
http://www.enlightenengineering.com/drivingGame/

I used bullet for the collision detection and my stuff for the rest of the physics.

I struggled to use bullet for all the physics but was unsuccessful. I would get stuck on little bumps, it was unstable, the tires would not slip …

I certainly don’t mean to insult anyone. The demos work great and I am amazed the stuff that runs in realtime, but I was really frustrated when I tried to but the bullet vehicle on my own terrain.

At this point I’m not sure if I want to pull the collision stuff out of bullet and go forward or delve deeper into bullet.

I’m curious to know how people get vehicles to behave nicely in bullet. Do you adjust integration stuff? Did you spend a ton of time adding functionality to the vehicle in the demo? What tricks do you know that I don't?

Again, I hope no one takes offense, just looking to share my experience and hear from others. If you used bullet to build a vehicle driving game I’d love to hear how you did it, maybe you have no idea what I’m talking about and it worked out of the box for you.

Also, feel free to look at my physics stuff on that same site.

Thanks

We're about to release two driving games using Bullet as the physics engine, and driving engine. The first is a Kart racer, and the second is a vehicle combat game. (I'll post the press releases when they come through.)

The Kart racer basically uses the default Bullet engine, with very few fixes & modifications. The second one is quite a bit more advanced.

I've written up some notes, hints & tips here: http://docs.google.com/Doc?docid=0AXVUZ5xw6XpKZGNuZG56a3FfMzU0Z2NyZnF4Zmo&hl=en

It's still in a draft form, but you should be able to get something from it.

hi
I'm interested at ANY code, any hint about that
some time ago I tried to model some Mc Pherson and Double Wishbones based chassis using Bullet constraints and "my own" suspensions. It was highly unstable, the whole thing deintegrated on bumps
I was wondering if soft bodies could help, or where the (stable but unrealistic) raytracing based VehicleDemo could be modified, but I ran out of motivation and, possibly, talent. I'll look at that, thanks

I’m happy to see some users are interested in discussing this.

When writing physics code I generally do the physics realistically without going too crazy with high stiffness and generally trying to use critical damping. Then I lower the integration step until it is stable. If it does not run in real time I tweak masses, stiffness and damping. In my simulation (not bullet) I use an integration step size of ~1000 Hz. This is way more than what seems common practice in bullet (60 Hz).

It seems the approach to making bullet simulations stable is a different kind of process, Kester did this:


Why isn’t decreasing the integration time step an effective method of increasing stability in bullet? Maybe it is, but it did not seem to be in my experience.

Interpolating the normals doesn't improve simulation stability exactly, it reduces the effect of driving over edges.

There's no way we can afford the CPU time of a simulation step of 1000Hz. We were at 120Hz, but we're shipping at 60Hz, since we're not getting collision problems at that rate. Your timestep should probably be set based on the fastest speed of your objects and the size of those objects to eliminate tunneling.

To increase the stiffness of the constraint solver, increasing btContactSolverInfo.m_numIterations will have more effect than the timestep. You might also try a different constraint solver (Featherstone, or analytic.) As I understand it though, fighting stiffness like this is a losing battle.

Note, I haven't tried any of this: the default 10 constraint iterations, and the sequential impulse constraint solver were enough for my needs. My simulation only involves one rigid body per car, so I don't have a stiff simulation.



It sounds like your simulation is too stiff. I don't think soft bodies will help, because they still need to be solved by the constraint solver AFAIK. I think you can still get realistic simulation from a raycast vehicle though.

Hi

Kester - I have been using your cheat sheet on Google Code. VERY helpful thank you! I managed to better my cars driving considerably. However my car is still bumping around from time to time. I have a fairly small limit to the size of my tack collision mesh, and as a result the changes in angles can be quite extreme.

So i was wanting to try to implement your "normal interpolation" suggestion. My question is this. What do you do with the interpolated normal? do you set the wheel info for you vehicle using setRaycastWheelInfo? or do you apply those normals to your track mesh?

Hi,

It's good to here it's been of some help.

I derive from btVehicleRaycaster, and use the interpolated normal as the returned btVehicleRaycasterResult.m_hitNormalInWorld.

Hey thanks,

So I have a btVehicleRaycaster in my vehicle class and I am now setting the new normals at the same time that i do setBrake/applyEngineForce.

Basically doing this

btVector3 newNormal = InterpolateMeshNormal(normalArr, triangle, results->m_hitPointInWorld);
results->m_hitNormalInWorld = newNormal;

for every wheel. Is this the correct place to do it? Or are those values going to just get overridden by bullet later on?

Bullet sets the wheel contact normal in btVehicleRaycaster::castRay.

I derive from btVehicleRaycaster and override that method - it's called from the vehicle's update, so if you change the normal outside of btDynamicsWorld::stepSimulation, it'll never get used.

I also use this method to set the ray-cast collision flags to reject trigger volumes etc, and reject ray collisions with the vehicle chassis.

I haven't tried this interpolating stuff. It's first time I've heard about it, and it sounds interesting.
As I understand these things... interpolating the normals will mostly improve the continuity of friction/traction... and the "bump" of a polygon edge won't be affected by this, right?

The suspension force also depends on the contact normal, so it smooths out the bump on polygon edges.

Oh, I see... I haven't really made a deep dive into the btRaycastVehicle details, but this sounds quite interesting, and it's next on my list! And thanks for the document, it helped me greatly!

Btw, hijacking the post a bit: I've seen that setting a "realistic" mass for the car causes strange suspension trouble. For example; setting the mass to 1200 (gravity is -9.8 ) it is impossible to get the suspension particularly stiff. It can be dampened, to a degree, but on bumps the *suspension will be compressed until the chassis hits the ground* (I'm sure there's an english word for this, but I'm not a native speaker). This includes insane values, like 1000000 for stiffness. It seems to be capped, somewhere. (I've seen the 6000 limit on the suspension impulse, but I don't think that this limit is hit, in this case, haven't verified lately though).
Setting a smaller mass, like 120, and making all forces smaller improves the behaviour quite noticably. Did anyone else experienced this?

The force is clamped after mass is factored in, so you are probably hitting the maximum suspension impulse limits (I've upped the 6000 limit to 100000). Our lightest vehicle's mass is 500kg, and the heaviest is 4000kg. The suspension stiffness ranges from 10.0 to 200.0.

It's good to know my notes are helping people.

I suspect everyone "pushes" their vehicles rather than torquing the wheels.
True?

Anyone put torque on the wheels?

If you're setting m_engineForce, then that's effectively the torque from the wheels. This is clamped to the friction limits and applied to the chassis. This is good, because it's simple and easy.

It doesn't take into account the inertia of the wheel or it's angular velocity however. For that, I think you'd need to add a rigid body for each wheel. The problem with that is that the constraints required to hold the wheel in place are too stiff. It might be possible to use the rigid body's angular factor to constrain the wheel to a single dimension, but I think that operates in world space rather than local space.