[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
>