[simspark-devel] Abstract Physics Layer

[<ah...@un...>]

Hello,


I'm the guy who volunteered for implementing an abstract physics layer in
Simspark. Actually, it's the project I decided to work on while I spend a
term in Japan.

Joschka and I spent a lot of time talking about the design during the last
few weeks and I've already started working on an abstract physics layer
that has some basic functionality with ODE. This is much harder than I
expected, especially because ODE is currently very deeply rooted in
Simspark, but I'll try my best. After that, I plan to get the same basic
functionality with Bullet and allow switching between both physics engines
at compile time. When this is done, adding more functionality
incrementally should be relatively easy.

Our current approach is to build a new dependency tree that does not
specialize in either engine (see
http://www.uni-koblenz.de/~aheld/newDesign.png). Most of these classes
will be abstract. In addition to all these classes, there will be
non-abstract classes derived from them (e.g. OdeBox and BulletBox derived
from Box). Following the advice of Oliver Obst, we've also added an
abstract physics server and specific physics servers for each engines
(i.e. OdePhysicsserver, ...). These servers will be responsible for
creating objects.

A practical example: Right now, an RSG file could contain "(nd Box". Upon
this, an OdeBox is created and added to the scenegraph.
In our approach, we will first create a physicsserver for the physics
engine we decided to use and later tell that physicsserver to create a
Box. The call will look something like "Box* myBox = new [...]Box()" with
"[...]" being the name of the physics engine we use. After this, all
methods necessary to deal with a Box will be readily available in the
abstract class, and delegated to the derived class by the compiler. This
allows us to deal with the many inconsistencies between the two physics
engines internally.

Another big challenge we are currently faced with is the handling of
collisions. Bullet does most of this internally, whereas ODE requires the
management of collisions by the user. Thus, all collision handling methods
are highly ODE-specific and there is not really a way to change this. The
collision handling is currently done by the Collider class, which should
be engine-independent in the final implementation.
To solve this, I've moved all the collision handling methods to the
ContactJointHandler class, which will remain ODE-specific. The
OdePhysicsServer will attach a ContactJointHandler to every Collider
Object (this should not cause any unwanted side-effects, and I think I've
read a comment somewhere that every Collider object automatically receives
a ContactJointHandler in the case of a collision, regardless). Bullet
objects will not receive any ContactJointHandlers for obvious reasons.

We're still pretty early in development, and we will welcome any other
suggestions on how to deal with the problems described above.

kind regards,
Andreas