BEPUphysics

Hi Guys,

First of all, great work on Bepu. It's great to have properly robust 3D physics on Windows Phone devices

Now my question is, what is the basic actor/body class in Bepu? That is to say, if I made three dynamic boxes, a static triangle mesh, and say a sphere what would their common base class be?

The samples reference things like boxes and vehicles so I'm not 100% sure, I've tried goign up their inheritance trees but I get lost along the way. My best guess so far is that Entity is the base class for such a thing?

Other questions I have are: How can I set if it is static or not ? Also is there a way to set userdata for entities? These are features I've found in PhysX/Farseer so just curious if there are equivalents in Bepu and how would I go about usng them

Reason I ask is because I'm writing a wrapper for Bepu in my 3D engine (noting personal, I wrap everything up ) and need to find a good 'base' class to use for my 'BepuActor' class

Thanks for any help!

First of all, great work on Bepu. It's great to have properly robust 3D physics on Windows Phone devices

Thanks

Now my question is, what is the basic actor/body class in Bepu? That is to say, if I made three dynamic boxes, a static triangle mesh, and say a sphere what would their common base class be?

Between those, ISpaceObject would be the common base. The ISpaceObject is a very high level interface that defines something that can be added to a space. However, you won't have access to much from that high up.

"Entity" is the superclass of mobile rigid bodies (Box, Sphere, Cone, CompoundBody, etc.). These can be dynamic (with mass/inertia) or kinematic (infinite mass/inertia). All entities can have linear/angular velocity, but only dynamic entities will respond to collisions and bounce around. Kinematic entities, having infinite mass/inertia, will happily smash through anything in their way.

An Entity has a CollisionInformation property which returns the Collidable used by that entity. A Collidable is a proxy for the entity in the collision detection pipeline which is used to collect contact points.

StaticMesh, InstancedMesh, and Terrain are all Collidables, but they are not owned by any Entity since they don't need any of Entity's systems. These objects are static and cannot move using velocity.

How can I set if it is static or not ?

When an entity is constructed, there are multiple constructors- some with mass properties, some without. If one with mass properties is used, the object is dynamic. If one without mass properties is used, the object is kinematic.

If you later want to change the dynamic/kinematicness of the object, you can call entity.BecomeDynamic or entity.BecomeKinematic.

Also is there a way to set userdata for entities?

Yes; the entity.Tag property. ISpaceObject does not currently expose a Tag; this may change shortly.

So are static meshs different to dynamic objects? I'm currently using the 'Entity' class for dynamic objects (haven't done much with it besides boxes so not 100% sure how flexible it is) but I'm finding StaticMesh does not inherit from it so they're not interchangable...

Correct, StaticMesh is immobile and doesn't share the functionality of the Entity, which is for dynamic and kinematic rigid bodies which have the ability to move around based on velocities.

StaticMesh does inherit from the same interface, ISpaceObject.

It also inherits Collidable, which is inherited by anything that can create contacts. The Entity's CollisionInformation property is the thing that lives in the collision pipeline for the entity, and it is an EntityCollidable. But that's not particularly helpful for a high level actor wrapper.

ISpaceObject has a Tag property in the upcoming v0.15.2, though. That at least provides user data support across StaticMesh/Entity/Updateables/SolverUpdateables.

oh ok cool

I haven't looked into it yet but how would I go about getting callback functions called when a contact occurs?

CollisionInformation inside an Entity has the property Events which has an assortment of events you can delegate.

oh ok awesome

Just one more quesiton, I'm a bit stuck with rigidtransforms. It's a bit wierd how they take in a position and a quaternion. Why not just settle for a single matrix? So I was wondering, how does one go about converting a matrix into a position vector and a quaternion for rotation?

Would it be fine if I did: Quaternion.CreateFromRotationMatrix(mat); even if it's a 4x4 matrix with position data?

Just one more quesiton, I'm a bit stuck with rigidtransforms. It's a bit wierd how they take in a position and a quaternion. Why not just settle for a single matrix?

A single 4x4 matrix is designed specifically to work for many different kinds of common transformations. Projections, shearing, scaling, translations, and rotations can all fit in there.

RigidTransform refers to a subset of those transforms- rotation and translation. Systems that need a rotation and translation can be given a RigidTransform without having to worry about the possibility that it includes additional transformations.

It's technically possible to still mess up a RigidTransform by giving it a non-normalized quaternion, but that failure mode is very rare and easily handled.

There's also the issue of size (7 floats versus 16 floats), but that was only a minor concern when choosing to use RigidTransform.

Would it be fine if I did: Quaternion.CreateFromRotationMatrix(mat); even if it's a 4x4 matrix with position data?

Yes; the Quaternion.CreateFromRotationMatrix should operate only on the upper left 3x3 section. As long as it doesn't contain shearing or scale, it should be okay. The translation can be grabbed from the matrix's translation property.

Norbo wrote:

Just one more quesiton, I'm a bit stuck with rigidtransforms. It's a bit wierd how they take in a position and a quaternion. Why not just settle for a single matrix?

A single 4x4 matrix is designed specifically to work for many different kinds of common transformations. Projections, shearing, scaling, translations, and rotations can all fit in there.

RigidTransform refers to a subset of those transforms- rotation and translation. Systems that need a rotation and translation can be given a RigidTransform without having to worry about the possibility that it includes additional transformations.

It's technically possible to still mess up a RigidTransform by giving it a non-normalized quaternion, but that failure mode is very rare and easily handled.

There's also the issue of size (7 floats versus 16 floats), but that was only a minor concern when choosing to use RigidTransform.

Would it be fine if I did: Quaternion.CreateFromRotationMatrix(mat); even if it's a 4x4 matrix with position data?

Yes; the Quaternion.CreateFromRotationMatrix should operate only on the upper left 3x3 section. As long as it doesn't contain shearing or scale, it should be okay. The translation can be grabbed from the matrix's translation property.

Oh yes, it's all coming back to me from the good old days of PhysX/Newton. If I recall PhysX had a 3x4 matrix which had position and rotation but obviously not scaling. And yeah,t he issue of size totally makes having a quaternion and Vector3 instead of a Matrix4x4 worth it