Car simulation physics problems

Hello !  :-o

I try to make a simple car racing game (not a 4x4 one, but one with jumps and loopings)  and have a few problems:

When I turn at high speed, my car model climb on the two left or two right wheels, because of centrifugal force.

I did implement a simple model of car based on the TestVehicleDemo from JmePhysics2, the Physic engine I'm using, and I add a simple routine to

keep the two front wheels parallels. In brief, four wheels with a two directional join per wheels.

So there is no suspension at this time. The buggeDemo and Vehicle&Car class from Physics v1 uses a "Hinge2Joint" and add:



to each join. How can I code the same with Jme Physics (2) ? I tried to add a third dimension to my join to make suspension and failed but I'm not sure of my Join representation

Here is my code:

    jointavga = getPhysicsSpace().createJoint();

        jointavga.attach( dChassis, dRoueavga );

        jointavga.setAnchor((dRoueavga.getLocalTranslation()).mult(scale) );

        axisavga1 = jointavga.createRotationalAxis();

        axisavga1.setDirection( new Vector3f( 0, 1,0) );

        axisavga1.setPositionMinimum( -0.5f );

        axisavga1.setPositionMaximum( 0.5f );

        axisavga1.setAvailableAcceleration( 95 );

        axisavga1.setDesiredVelocity( 0 );


        axisavga2 = jointavga.createRotationalAxis();

        axisavga2.setDirection( new Vector3f( 1 , 0 ,0  ) );

        axisavga2.setAvailableAcceleration( 265 );

        axisavga2.setRelativeToSecondObject( true );

I had my materials ok (rubber/iron), my center of mass neared to the ground.

May I code a third rotational axis ? … Had axles with suspension joint from the chassis and wheels joints to the axles ? Dynamically Apply forces to counter the centrifugal ones as adviced in other forum posts ?

Another question… my wheels physical models are Bounding spheres … is it the best solution or should I use triangles collision ? When I use the generatePhysicsGeometry(true), with spatial representation ( my wheels are cylinders) I obtain strange results, my car is jumping and jumping and jumping… 

Thanks for you replies !!!  :lol:


I know one way people have tried to keep all four wheels on the ground when turning is to lower the center of gravity. Also, maybe the friction is too great using the default rubber against iron, might want to tweak that a little so you can skid in hard turns.

I do beleive there are issues with trimesh on trimesh collisions in ode, so your best bet, and more performant, is to use the cylinders or spheres for wheel physics geometry.

When I use the generatePhysicsGeometry(true), with spatial representation ( my wheels are cylinders) I obtain strange results, my car is jumping and jumping and jumping... 

This is probably the trimesh on trimesh problem. Personally, I would stick to the spheres.

Define your own material like pavement or dirt, which is a more realistic approach to the rollover problem.
nymon said:

This is probably the trimesh on trimesh problem. Personally, I would stick to the spheres.

isn't everything in jME made of trimeshes?
isn't everything in jME made of trimeshes?

In ODE (used by jME Physics) collision geometry can be either made from the primitive shapes (cube, sphere, plane, etc...) or trimeshes.

I tried to replace my sphere my cylinders or capsules. No way.

I lowered the center of masses, had better results, but the two left wheels or two right ones continued to raise when turning at high speed depending on direction turn.

I Tried changing my wheels scale, EFM suspensions, … too.

I created new materials and tried differents combinations of all these tips for hours and hours… I don't have correct results.

Does anyone know where are the buggedemo or Rover Run sources …?

I don't think I will get it correct with parametring my variables. There's probably others parameters I don't handle correctly, but I can't see them.

I can imagine two tips:

first, to apply forces to my chassis and/or wheels to counter the raising ones.

Second, to apply rotations when there is contact with two same-side wheels and the floor and no contact with others so that my car may stay on the floor, but it seems too ridiculous.

I really need a correct physic simulation and can't use programmation tips because of I want loopings and jumps.

Any suggestions would be great !!


Kine, (getting mad)


I've been implementing and testing with car dynamics for a while now and there's just one thing I didn't figure out yet: How to get rid of some instability with the interation between the wheels (dynamic physic spheres) and the terrain (static physics triangule mesh - accurate). The code is a bit too long to post here but I can write a test again to show.

The problem is that SOMETIMES one wheel get under the terrain… I noticed that this occurs more often near the edges of the triangules… I tried increasing the size of them, but that always happen near the edges.

Any ideas?

BTW, I am coding open source stuff so feel free to ask for some code snippets and everything, if you're interested.

perick, please try increasing the maximum number of contacts allowed per collision (Odejava.setMaxStepContacts) or decrease step size (while increasing number of steps, of course, see OdePhysicsSpace$Odefactory.create), probably this can solve your instabilities.

If you can put together a short test showing off your efforts and would like it to be included in jME Physics 2 tests, I'd be very happy to add it there :slight_smile:

Experiment results:

Part I - Messing with JMEPhyscs implementation

  • I couldn't find usefull values for Odejava.setMaxStepContacts(int value). Any value I put ruined the simulation (10 to 10000000). Didn't find a getter or any place where it was called to see what is the correct range.

  • Found useful increasing Odejava.setMaxContactsPerNearcallback(int value) from 50 to 200… Didn't hurd much on performance and made it a little more stable.

    Part II - Messing with step sizes an update rates

  • I'm coding a really fast race game, so to decrease step size, I had to increase update rate to make the simulation nice, otherwise the game would be too slow. First I was targetting at: ups 60 and 1/60 step size… Got it REALLY stable at: ups 120 and step 1/120

    Part III - Conclusion

    Even at 60 & 1/60 it's more stable than before and it's acceptable using the 200 contacts pe near callback (dunno what it means, didn't studied deep)

    I'll try to code a useful test with inner classes and a very simple terrainpage to post here.

    Thanks again.

great, you were successful :slight_smile:

perick said:

Odejava.setMaxContactsPerNearcallback(int value) from 50 to 200

Oh, sorry for that - confused those methods. I'll increase the default as it affects performance only if many contacts are reported and in this case it does also cause instabilities.

- REALLY stable at: ups 120 and step 1/120

mm, that's something which can't be changed by default. So I added a setAccuracy to PhysicsSpace.
mm, that's something which can't be changed by default. So I added a setAccuracy to PhysicsSpace.

I didn't understand what you meant here, at all!

I'm curious because I've been testing Rover Run and that's a nice simulation with JMEPhysics (1)... Even at very low FPS there's no instability at all.

I meant: I can't change the default to 1/120. But until yesterday one had to cast to OdePhysicsSpace to set this parameter. To allow your code to be clean (without nasty typecast and compile time dependency to the Ode implementation), I have added a new method into PhysicsSpace so you can set those value with a proper call. Or: everything should be fine now :slight_smile:

Already interested in seeing that test :smiley:

Now I've got it the way I wanted…

Target: fast race cars, with suspension, stability, good turns, speed feeling and everything…

The problem I had with wheels penetrating on terrain was agravated by the extreme bounciness of rubber but now is completely solved… See below:


Gravity: Vector3f(0,-100,0) <- that will make good stickness and responsivness

CFM: 0.00001 <- setting this will make the joints a little more spongy and soft

Materials: CONCRETE for terrain and RUBBER for wheels… But change Mu to 0.9f and bounciness to 0.5f (instead of 0.85f)

Plus tweeked values for masses, joint velocities and available accelerations.

Works stable even as low as 60 fps (physics updates/second) with very nice speed feeling (aka NFS)…

I'll post the test here soon.

May the force be with you 


The crashing problems in Mac and Windows were caused by the tweeking in the:

Odejava.setMaxContactsPerNearcallback(int value)

Originally it used 50 callbacks, then I tried 200, and even that minimized the numerical instabilities it was causing the crashes. With the other tweekings on I could set it back to 50 and the crashes stoped, even in windows that seems to be more unstable. Now I