No seperate Thread for Physics-Update?


i just tried out the TestStressPhysics-Sample and wondered why only one core of my 2 processor-cores is used?

I thought the physics are running in a seperate thread so we have a update/rendering routine similar to:

  1. Start the physics simulation in an own thread
  2. Start the rendering in an own thread
  3. Rendering/physics finished -> wait for the other thread
  4. Sync physics and scene nodes

    Has anyone already modified jMEPhysics2 so the updates run parallel to rendering?


"wait(1)" after "while(physicsUpdateThread.isRunning())" and "running = false;" should reduce the cpu-overhead, while waiting for the other thread.

I wrote PhysicsMultithreadedGameState as a quick test to see how stable multi-threaded physics would be and didn't spend much time with it.  The code you posted seems to work pretty reliably without crashing?

Yes, no crashes.

I also tried the domino-example and it worked fine.

Tomorrow I will do some more tests.

Perhaps there are features where updateScene is required during the physics-update?

When yes, than there could be calculation-errors.

But I hope that the physics and scene data is clearly seperated, so that updataScene has now influence on the physics simulation.

I will investigate that.

Great work…when you get to a comfortable place with the code, if Irrisor agrees, I'd recommend posting either an update to PhysicsMultithreadedGameState, or a completely new class for others looking to utilize multi-threading within their physics games.

Awesome can't wait to try this! :smiley: Thx

awesome. :slight_smile:

darkfrog said:

awesome. :)

wow this actually is pretty useful will it become part of the repo anytime soon?

I stopped using ODE/ODEJava because of memory leaks, stack corruption and random crashes.

This bugs are not related to multithreading. They are somewere inside ODE/ODEJava and they will probably never be fixed.

I can not recommend ODEJava for any serious project, but it is ok when you want to play around a bit with physics.

Sorry, :confused:


What would you recommend JBullet, regular Bullet, or something else?

I wrote a very small "physics engine" for my game, because the experince with ODE was very frustrating and I did not want to get into the same situation again.

This was possible for me, because I have very clear and restricted use-cases. I'm using for example only axis aligned bounding boxes. So implementing everything by scratch after kicking ODE out took me less than 2 weeks.

( The character controller in Quake 3 is a good reference. It is written in C, but very well commented and easy to understand.)

In most current games you need more than a character controller, so there is probably no way around a physics library. When I would have to use a physics-library again, than it would be PhysX, because it works, there is a company behind it and many commercial games are using it.

I played a bit around with Bullet, but I don

Hey guys. Its been (quite) a while, but I'm still alive.

I did something like this. put the physics thread on a seperate thread ticker to the render thread. It was quite nice, and mostly ran smoothly.

Till… concurrent updates! I ended up using locks to make sure that they didn't operate on the same section at the same time. Lazy me, I did it at a pretty high level, which then cut out almost all the benefits of multi threading.

I chased up a few threads on it… and it all seemed too much trouble. I thought that all threads had common memory (ie - not processes), but… you can't really tell. and memory synchronization is more expensive than you would gain.

Of course this was pre 2.0… and I think the concurrent modification error was thrown from ODE.

Just a warning. If you don't get it… awesome.

Yeah, trying to multithread things like that, doesn’t work all too well. It all comes down to what is “embarrassingly parallel”, e.g if you can split a large task into many separate, independent tasks, then you can achieve optimal multitasking of the task.  In the end it’s up to the physics engine to multithread its own algorithms.

You might be able to support physics multithreading using the method in this thread, but you will be required to make no modifications to the scene or any physics related state while ODE and jME are being synchronized. This will be very difficult to maintain, and won’t yield much performance over single-threading.