yake::physics

YAKE physics systems are pluggable. See below for a list of officially supported plugins. Several systems can be used at the same time, each of them running any amount of physical worlds.

IPhysicsSystem:

• creates any number of worlds (limit is dependent on specific implementation/plugin)

IWorld:

• represents a self-contained physical world with physical entities (shapes, bodies, actors etc.)
• can create various objects belonging to this world: materials, actors, shapes, joints, trimeshes, avatars …
• allows to set properties (e.g. time steps, solvers …)
• running the simulation is done by calling step() regularly: fixed/variable time stepping is handled internally by the concrete implementation

IMaterial:

• represents physical properties of a shape (for example, bounciness and friction)

IShape:

• represents a geometric collision object
• physical properties are defined via materials
• can be a primitive like a sphere or a capped cylinder
• can be a more complex geometric object like a triangle mesh
• cannot be created directly, serves as a base class for immovable and movable shapes
• IImmovableShape: (derived from IShape)
  • is (*gasp*) not movable
  • can be created only by a static (i.e. immovable) actor
• IMovableShape (derived from IShape and base::Movable)
  • is movable
  • can be created by movable and dynamic actors

IActor:

• represents a complex physical entity in a world
• has shapes (at least one)
• is movable
• may be dynamic (in this case it has a body)
• IBody:
  • gives access to dynamics properties of a dynamic actor

IAvatar:

• represents, for example, a player in a physical world
• provides basic interface for actions: moving, jumping, taking dynamic objects, dropping them…
• dynamics influence is controllable

Have a look at the sources if you want to know more about the current implementation.

• IActor interface has createShape(), getShapes() [ is a defacto IStaticActor ]
• IStaticActor (static in the sense of “immovable”) is a typedef'ed IActor
• IMovableActor inherits from IActor and Movable
• IDynamicActor inherits from IMovableActor and implements IBody interface (IBody actually no longer needed) i.e. addForce(), addTorque(), addMass() etc
• advantage: linear hierarchy → easy to implement
• disadvantage: IStaticActor typedef… may break in the future?

or

• IActor interface has createShape(), getShapes() [ is a defacto IStaticActor ]
• IStaticActor inherits from IActor
• IMovableActor inherits from IActor and Movable
• IDynamicActor inherits from IMovableActor and implements IBody interface (IBody actually no longer needed) i.e. addForce(), addTorque(), addMass() etc
• advantage: limitations are (mostly) obvious in the interfaces.
• disadvantage:problem is the splitting of the hierarchy when deriving IStaticActor and IMovableActor → more cumbersome to implement. Maybe even impossible to do it cleanly.

or

• make it simple to implement but slightly less obvious:
• IActor interface has createShape(), getShapes() etc

• IActor represents both movable and non-movable actors
• IDynamicActor inherits from IActor and implements IBody interface, i.e. all the dynamics stuff like addForce(), addTorque(), addMass() etc
• advantage: easy to implement.
• disadvantage: limitations aren't obvious in the interfaces but they are obvious in the code (isStatic(), isMovable())

or

This is the 2nd option with some additions

* IActor interface has createShape(), getShapes() etc
  class IActor
  {
   ....
   public:
     ....
     SharedPtr<IShape> createShape( const IShape::Desc& rD ) { return createShapeFromDesc( rD ); } 
     ....
   protected:
      virtual IShape* createShapeFromDesc( const IShape::Desc& ) = 0;
  };

• IStaticActor is guaranteed to create only IImmovableShape's with covariant return types:

class IStaticActor : public IActor

  {
   ....
   public:
     ....
   protected:
      virtual IImmovableShape* createShapeFromDesc( const IShape::Desc& ) = 0;
  };

• IMovableActor is guaranteed to create only IMovableShape's with covariant return types:

class IMovableActor : public IActor

  {
   ....
   public:
     ....
   protected:
      virtual IMovableShape* createShapeFromDesc( const IShape::Desc& ) = 0;
  };

or

BodyAffectors affect physical bodies. (“You don't say?”)

A zone is a collection of geometric bounding objects (for example, spheres and axis-aligned boxes). Affectors can be attached to zones. Whenever a zone is updated it will apply the affector to all objects within the zone's bounding objects.

Several different body affectors are provided by default. New types can easily be implemented and registered to the factory in the usual approach.

Examples for affectors:

• The ConstantDirectionalAccelerationAffector applies a force corresponding to a constant acceleration to a body. The direction of the force is always constant.
• The ConstantSphericalAccelerationAffector applies a force corresponding to a constant acceleration to a body. The direction of the force points from the affector's origin to the body's position (if acceleration is positive).

Currently the following plugins are officially supported:

• physicsODE: uses ODE (Open Dynamics Engine, http://ode.org).
• physicsNX: uses Novodex Physics SDK (http://www.novodex.com).