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?
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.
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.
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.
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.