Comparison of Physics Engines

Has anyone done a survey comparison of open source
physics engines for their potential use in Blender, as
compared with the current one found in the Blender
Game Engine?

In particular, I am curious as to how ODE and Tokamak fare
when contrasted with Blender Physics… Here is information on


well anyway, there was a comparison between the different methods of physics on the ODE site somewhere

but anyway

blender has physics implemented on top of solid [which only does collision detection]. this causes it has problems with stacked boxes for example.

I haven’t played with tokamak [I may, I’m bored] but ODE allows things like bodies connected to each other in several ways, and though it can be pretty slow it does a very nice job. [connected bodies allow veichles and ragdolls and numerous numerous other things]

ODE doesn’t have triangluar collision detection, [OpCode is another library, with a different license and a bunch of quirks in relation to ode]. in theory SUMO could be used to detect collisions for ODE, and all would be good, but I don’t know if anyone has done that yet.
[SUMO is gpl I think, ODE has a dual license bsd-ish and lgpl]

tuhopuu has ode and some others. i guess that might just be for the particles, but i think it’s for the game engine. so go get tuhopuu from testing builds forum at and try those engines out. i’ll give it a try and make sure they work.
<edit> well they work but it would appear that tuhopuu is a bit shaky yet when it comes to the game engine. the first thing that caused me to suspect this is when i pushed P my main actor became invisible.

Tokamak can’t be used in Blender because its license is incompatible with the GPL.

z3r0 d : dont you mean SOLID with ODE. to have better collision detection? and also there is a new version of ODE out, which is supposed to be faster QuickStep i guess… but i dunno :o

blender (bf-blender, tuhopuu is different) isn’t using ODE from what I remember

I said that SUMO could probably be used to detect collisions for ODE, which would probably be faster than the current [Opcode/ODE] collision routines. THe licenses would allow it too

quickstep is pretty quick, run the test_crash demo to play with it
[with it off it can take several minutes to do one frame [default like 10 iterations I think]]

note: if built in windows test_crash will probably cause the stack to get full when quickstep is turned off. This is because the stack size is fixed in windows, where in linux it can expand even into virtual memory. the function stack is used somewhat to traverse the connections [collision points] between the blocks.

I have a build of test_crash somewhere, maybe i’ll find it

[if you tweak it so there are fewer blocks it will be less likely to crash with quickstep off]