[simspark-devel] Design question

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

Hi yet again :P


Joschka and I keep running into the same problem over and over again
considering the design of the physical abstraction layer. Our current
approach involves engine-specific stuff being restricted to the leaves of
the dependency tree. However, there is lots of ODE-specific code in
"body.cpp" and "collider.cpp" - 550 and 300 lines, respectively.

According to our current design, this code does not belong in those
classes because they should be abstract and not engine-specific. So,
generally, we would move this code to the ODE-specific subclasses
(OdeRigid, OdeStatic...). However, since this code will be the same for
all ODE-specific subclasses of Body, I would copy and paste lots of
redundant code.
A possible solution would be creating specific subclasses for Body,
putting the old code in OdeBody and equivalent code in BulletBody. In this
case, OdeRigid would have to inherit from both the abstract Rigid class
and the sepcific OdeBody class. Multiple inheritance is generallty frowned
upon. PAL, by the way, uses multiple inheritance a lot.
I have an idea in my head that involves creating two separate files,
odebody.h and bulletbody.h, and declaring a class Body in both of them. At
compile time, bulletbody would be hidden from the compiler if ODE is used,
and vice versa. All subclasses would then inherit from Body and
automatically inherit the engine-specific code that way. This would kind
of throw the idea of an abstract physics layer overboard, since the class
would be neutrally be called "Body", but is actually engine-specific.

So, we have a few ideas on how to deal with this, but all of them seem to
be very flawed. That's why we want to ask what you guys think (especially
Ben and Hedayat, since you seem to be most interested in the abstract
physics layer). I'll also return to the drawing board for the time being -
the new design looks good on paper, but once you start trying to implement
it, you realise the problems. Coming up with a good design that deals with
all the problems I mentioned so far will probably be the hardest and most
time-consuming part of my work.


thanks,

Andreas