Comparison of Physics Engines with Irrlicht

[aboeing]

Also, as I'm also sometimes doing image processing, is there a working link for your ImprovCV? The one on your homepages seems to be dead

Yes, I've been having ongoing issues with my webhosting, I will try and get that website back up for you soon. (this weekend)

@aboeing: Why don't you create a project announcement for that? Especially the benchmark really rocks! I have to get the full version running some time, this is very useful stuff.

I wanted to release a more complete wrapper for Irrlicht, but I guess I could announce the Benchmark project if thats what you meant?

might tread on the project i've just started though

Whats your project?

Edit: Having checked out the benchmarker it seems cool to compare all the physics engine side by side like that but the results are pretty open to interpretation as in we don't really know what the physics simulation should look like... and if that's how the same inputs from PAL result in such varying behaviours in the resulting physics simulations then it seems PAL isn't really that good for switching between engines.. should the same inputs to PAL not result in very similar results from the different engines?

Thats true, we don't know what they should look like, but we can sometimes say what they SHOUDLN'T look like, and we can assess them for the properites we want (eg: correct restitution, or stable/fast solutions, etc.)

Ideally, the same inputs in PAL should produce very similar results in all engines, however every engine is implemented differently, so there is no way to get the same results.

If every engine gave the same results there would not be much need for PAL (other than selecting the best engine for your platform, eg: Bullet on PS3, PhysX on nVidia GPU, Havok on AMD GPU, etc.). Instead you may find you are working on a game or simulator and the engine you are using is not giving you the desired results, using PAL you can just switch to a different engine that does give you the right results.

For example, if you were to develop a robot simulator, you may need fluid simulation if it is an underwater robot (eg: PhysX), or accurate links for a robotic manipulator (eg: ODE), or accurate friction for a walking robot (eg: Newton). You could then just use PAL and switch to the appropriate physics engine for each situation.

Similarly, in a game engine, you could switch depending on the game level/environment,etc.

[CuteAlien]

Also, as I'm also sometimes doing image processing, is there a working link for your ImprovCV? The one on your homepages seems to be dead :(

Yes, I've been having ongoing issues with my webhosting, I will try and get that website back up for you soon. (this weekend)

Thanks (though I will probably not have any free time the next few weeks...).

@aboeing: Why don't you create a project announcement for that? Especially the benchmark really rocks! I have to get the full version running some time, this is very useful stuff.

I wanted to release a more complete wrapper for Irrlicht, but I guess I could announce the Benchmark project if thats what you meant?

Yes, spend that project it's own thread in the forum :-)

[JP]

I would say that it is possible to get the same results from each engine, it's just a matter of tuning the parameters correctly. now that may not be an easy job but i'm fairly sure it would be achievable.

My project is a wrapper for Physx to use in Irrlicht, initially i thought of doing what you've done (before hearing about PAL properly) and allow other physics engines to be swapped in underneath the wrapper but i wasn't sure of the benefits and knew that it would actually produce a lot more work, if i just stick with Physx then i just have to deal with Physx rather than lots of other engines. As it happens i've basically designed the interface in a way that it could become like PAL but i doubt i'll ever get to that stage. Basically i started using Physx on PS3 and got on famously with it so i'm happy to use it for my PC projects too and so this wrapper is mainly something for me but also to share with the rest of the community.

Anyway, your project does sound pretty cool and useful so i don't want you to feel i'm knocking it! As you mention it could be good for a multi-platform game as you could just switch in the best physics engine for that platform really easily.

[cassini]

For example, if you were to develop a robot simulator, you may need fluid simulation if it is an underwater robot (eg: PhysX), or accurate links for a robotic manipulator (eg: ODE).

As far as I know an engineer have to be insane to simulate an underwater simulation with the kind of fluid simulation you get from Physx.
Isn’t is true that PhysX fluid simulation is particle based and do not obey incompressibility, which will be the number one condition for a fluid simulation?
In other word fluid simulation in Physx is just cosmetic.
As for ODE, accurate link for a robot? This is simple no true.

I would say that it is possible to get the same results from each engine, it's just a matter of tuning the parameters correctly. now that may not be an easy job but i'm fairly sure it would be achievable.

Not really, you have to be careful when making bold statements if you do not know how constrained physics really works.
All physics engines try to solve the same dynamics equations.
The formulation of any set of articulated and/or resting set of rigid bodies lead to a linear equations which need to be solved by a complex optimization algorithm, in order to find the internals reaction forces that satisfy the constraints betrween bodies.

If you took a class on advance linear algebra, you will know that all known algorithms for optimizing linear systems of ecuations with many variables, are based on the solution of linear systems of equations, and they all have cubic time complexity at best. So it is a complex problem.

For all physics engines the equations are the same, what is different is the features and the algorithm used to solve the systems of equations.

Game engines use iterative methods and they have to settle for aproximated solutions.
Since the solutions obtained from iterative algorithms, are approximations that leave a lot to be desired, physics engines makers use heuristic to make the engine stable, no to be confused with accurate.
Some engines use tricks like multiplying the velocity by a number like 0.9 in each frame, others use tricks like no using torque when the angular velocity is small, etc.
So unless all engines are using the same algorithm and the same heuristics, it is simple misleading the people saying that "it is possible to get the same results from each engine, it's just a matter of tuning the parameters correctly".

You are correct in that using a multi wrapper is not right because the multi wrapper will always lead to the solution that was best with teh eengien the wraper maker new best and not so good with the ones he added as check box feacture.
For example I was watching PAL performance video http://www.youtube.com/watch?v=IhOKGBd-7iw
you can clearly see that Newton does not perform particularly well on the horizontal constraint test, but then I have seen other videos of far more complex constraptions where newton does perform as expected
http://www.youtube.com/watch?v=5J3Fl5Uvehs
So you must conclude that at the very least no effort was placed on adjusting the engines so that they perform the best they could.

[fmx]

So you must conclude that at the very least no effort was placed on adjusting the engines so that they perform the best they could.

I'm sure he'll get to that some day
if you don't like it / want to use it, feel free to go away and use what you will, how you will

Instead you may find you are working on a game or simulator and the engine you are using is not giving you the desired results, using PAL you can just switch to a different engine that does give you the right results.

For example, if you were to develop a robot simulator, you may need fluid simulation if it is an underwater robot (eg: PhysX), or accurate links for a robotic manipulator (eg: ODE), or accurate friction for a walking robot (eg: Newton). You could then just use PAL and switch to the appropriate physics engine for each situation.

Similarly, in a game engine, you could switch depending on the game level/environment,etc.

IMO switching physics-engines midway during development is a really stupid thing to do, because of all the numerical changes which have to be made to the inputs to get anywhere near *similar* results; I wouldn't recommend it for games at any cost (just stick with vanilla implementations or singleton wrappers).

Its a good idea for small applications / demos with a specific aim because of this ability to switch, maybe also good for initial tests to see which physics-engine might be suitable for a future project.

Keep going and be sure to try make similar input-values give similar results if you can (probably through hard-coded constants to adjust scales and masses within the wrapper, shouldn't be tooo difficult).

[aboeing]

Anyway, your project does sound pretty cool and useful so i don't want you to feel i'm knocking it! As you mention it could be good for a multi-platform game as you could just switch in the best physics engine for that platform really easily.

Sure, I didn't take it that way at all, every bit of feedback is valuable. I just wanted to state that it wasn't possible to get every engine to act the same (see cassini's comments as to why), and still demonstrate how having the ability to swap engines is usefull.

As far as I know an engineer have to be insane to simulate an underwater simulation with the kind of fluid simulation you get from Physx.

Thats quite true, SPH based methods are not very good at calculating the correct forces that act on a submersed body. However, they are fast, and can give an approximation of the behavior you would get in real time.

At present, it is impossible to get accurate fluid simulations in real time.

As for ODE, accurate link for a robot? This is simple no true.

Correct, ODE is not accurate, just more accurate than most game physics engines. It is no where near as accurate as an engineering physics engine, or other realtime engines like Dynamechs.

you can clearly see that Newton does not perform particularly well on the horizontal constraint test, but then I have seen other videos of far more complex constraptions where newton does perform as expected .

The results for that test in the video have been independently verified at Umea University. It is in fact just that case where Newton behaves poorly, I have personally used Newton to model complex rag dolls and robots where it outperforms most other engines. This doesn't change the fact that it does not handle that particular case well (using its default configurations).

So you must conclude that at the very least no effort was placed on adjusting the engines so that they perform the best they could.

Effort was made to get the best possible performance, however it was the best possible overall performance, not for specific situations. (If you know how performance could be improved for Newton, the project is open source and I'd welcome contributions btw.)

IMO switching physics-engines midway during development is a really stupid thing to do, because of all the numerical changes which have to be made to the inputs to get anywhere near *similar* results; I wouldn't recommend it for games at any cost (just stick with vanilla implementations or singleton wrappers).

Yes, it would be a fair amount of effort to swap as you said, however some times if you are developing something where you are very unsure as to the performance of the engines switching like this is still far easier than doing everything from scratch again.

Its a good idea for small applications / demos with a specific aim because of this ability to switch, maybe also good for initial tests to see which physics-engine might be suitable for a future project.

This is the advisable solution. Just use PAL to try out every engine and figure out which one will do what you want best, then rewrite your code to do that.

Keep going and be sure to try make similar input-values give similar results if you can (probably through hard-coded constants to adjust scales and masses within the wrapper, shouldn't be tooo difficult).

Thanks for the encouragement, I do try and make the results as similar as possible.