WorldTransformation in hierarchy

Discuss any questions about BEPUphysics or problems encountered.
Post Reply
Phippu
Posts: 24
Joined: Fri Jun 03, 2011 3:39 pm

WorldTransformation in hierarchy

Post by Phippu »

Hello, I'm currently working on a more or less complex object hierarchy that manages rendering, physics and more. Now I run into a little problem and I'm sure there is a simple solution and I'm just unable to see it. We all know that we need a WorldTransformation matrix to draw 3D objects. So in my hierarchy I need an object that has something to render ( a model for example) and that is bound to a bepu object for it's physical behaviour. My first intention was to use the Entity class which seems to work fine if I have an Sphere ord Box for example. But what if I have a StaticMesh or and InstancedMesh. Well they do have a Worldtransformation too, but they are not inherited from the Entity class.

So my question is: what class or interface should I use for my object for it's physical behaviour. See the pseudo code above for a better illustration:

Code: Select all

class BoundModelRenderer
{
   Model Model{get;set;}
   Entity BoundObject{get;set;}
   void Draw()
   {
      Model.Draw(BoundObject.WorldTransformation)
   }
}
I want to replace the "Entity" class with an appropriate class or interface so that I can assign a Box, a Sphere, a StaticMesh or an InstancedMesh. Or is there an entity to replace the StaticMesh and/or the InstancedMesh?
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: WorldTransformation in hierarchy

Post by Norbo »

There is no common parent to both Entity and StaticMesh which is helpful for rendering.

A StaticMesh is a Collidable, subclass of BroadPhaseEntry. A BroadPhaseEntry object lives in the collision detection pipeline. Collidables are objects in the collision detection pipeline that can generate contacts with other objects.

An Entity is an object capable of kinematic and dynamic motion. It has an EntityCollidable (subclass of Collidable), accessible in its CollisionInformation property. That EntityCollidable acts as the entity's proxy in the collision detection pipeline. The entity's own systems are dedicated to fulfilling its separate duties, like motion.

So, if you wanted to, you could create something based on Collidables since the entity has one. This would require some jumping around to grab the proper entity transforms though and may be a bit obtuse.

I generally recommend going with a decoupled approach where a game logic object has graphics and physics clearly separated. The physics object belonging to the game logic object could contain anything- an Entity, a StaticMesh, some custom Particle, etc. Your game logic object could use an abstracted interface to get any information from the general 'physics object' necessary for the renderer. Basically, the game logic object acts as glue, and any domain-specific logic takes place in the appropriate connected components.

Of course, there are even more ways to do it, but that covers the general idea.
Post Reply