simspark-devel

[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

[simspark-devel] Fwd: Abstract Physics Layer

[Ben <lgp...@16...>]

---------- Forwarded message ----------
From: Ben <lgp...@16...>
Date: 2009/11/5
Subject: Re: [simspark-devel] Abstract Physics Layer
To: ah...@un...


Hi, Andreas,

  I'm so exciting to do a reply when hearing the message of abstract physics
layer that
progress has been made in Simpark by the great contribution of you and
Joschka. I only got
some experience in last year when I tried to integrate PAL into our
simulator. I have some
agreements and suggestions as following.

 1. Collision Handling is really a trick issue for the reason that the
designs of different engines
    have no standards(especially ODE is hard to be compatible with others).
For instance, I
    remember that the 'dJointFeedBack' of ODE is really hard to handle.

 2. I've looked the tree of physical classes. May be there is a missing of
class 'Material' which
    descripts the property of physical objects such as frictions, bounds,
etc.

 3. Switching between different physical engines in compile time like well,
is there a consideration
    of switching in run time? Obviously, the simulator will be more
efficiency when the engine has
    been built-in since switching in run time will have some cost in virtual
functions. However, switching
    in run time get two clear advantages: we need not to maintain lots of
versions; it is more convenient
    and flexible.
Hope useful!

Regards
Ben
2009/11/5 <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
>
>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Simspark Generic Physical MAS Simulator
> simspark-devel mailing list
> sim...@li...
> https://lists.sourceforge.net/lists/listinfo/simspark-devel
>