BEPUphysics

Hi Norbo
I am working on an engine for a game I wish to develop. I have been using BEPU for a few months now and it is working very well for handling the physics It is only now that I am trying to create an engine using an Interface for all physics objects like a Box, Sphere, Capsule etc, that I am coming to trouble. It is setup like; the interface contains a Entity value (which obviously holds the physics object). It also contains properties such as Position, Rotation, Scale, Mass. This interface is working fine for all entities such as the Box, Sphere etc but now that I have come to the StaticMesh and it is not an Entity. My question is, is it possible to hold a StaticMesh within an Entity or am I going to have to redesign the Interface for all physics objects. If that is the case, what value must replace the Entity in the Interface to be able to hold a StaticMesh and a box for example.

Thanks

My question is, is it possible to hold a StaticMesh within an Entity

Technically, sort of. The development version (http://bepuphysics.codeplex.com/SourceC ... evelopment) supports mobile entity meshes. However, it's recommended that if the mesh is actually static, then a StaticMesh should be used instead.

am I going to have to redesign the Interface for all physics objects. If that is the case, what value must replace the Entity in the Interface to be able to hold a StaticMesh and a box for example.

Both implement the ISpaceObject interface, but that is very high in the hierarchy and doesn't provide much information.

The closest connection between the two is that the StaticMesh is a Collidable, and that the Entity has a Collidable in its CollisionInformation property that acts as a proxy in the collision pipeline. The Entity property is actually an EntityCollidable, which is why entities cannot have StaticMeshes as their CollisionInformation.

The Collidable class is the superclass of objects that support generating contacts in some way. You may be able to create some parallel design analogy based on that.

However, I would not recommend trying to force physical objects and nonphysical objects under the same roof. There will be quite a few incompatibilities, such as Entity's use of rigid transformations and lack of general support for non-shape-based scaling (TransformableShape supports it, and a few others implicity support it, but it's not available across the board). Additionally, non-entities like the StaticMesh have no velocity, momentum, nor mass. The result of forcing the two together would likely be a class which either throws many NotSupportedExceptions, or has very little useful information exposed.

Thanks for your reply

I tried using the ISpaceObject as you mentioned and it did not provide any Entity information that I need such as position etc.(which is like you also said).

I then downloaded the newest development version and tried the MobileMesh and things are colliding with it but it stays still and does not move, is this what it is? As I assumed that by Mobile it meant that it could move, or am I not setting it up correctly?

Also, if I was to use the MobileMesh as the world which cannot move etc, what can go wrong with this as you recommended that a StaticMesh be used instead.
Thankyou again

I then downloaded the newest development version and tried the MobileMesh and things are colliding with it but it stays still and does not move, is this what it is? As I assumed that by Mobile it meant that it could move, or am I not setting it up correctly?

It can move, but it doesn't have to move. A mobile mesh is designed to be capable of movement with relative efficiency. A kinematic entity (constructed without a mass parameter, effectively infinite inertia) will not fall due to gravity; that's probably what you're seeing. A kinematic entity can still move by changing its LinearVelocity and AngularVelocity.

If a mass is supplied to the MobileMesh constructor, it will fall and bounce around like everything else.

The difference between a kinematic entity that has a mesh shape and a StaticMesh is that a static mesh cannot have velocity, and it is not designed to move. The practical result is that the StaticMesh should be faster for cases where a StaticMesh is usable.

Apart from the performance issue, a MobileMesh that just doesn't move will have similar behavior and simulation quality to a StaticMesh.

After working with BEPU for a while now, can't believe I missed that mass overload as I had this issue when I first started hahaha, I swear the overload didn't show up

I think for simplicities sake and not having to redesign my whole physics engine framework, that I will just use the MobileMesh as a static object. But this also raises another question, if the object is going to be still, I'm assuming you would make the entity kinematic because then nothing can move it(am I right in saying this, or can other kinematic entities move each other?)

Thanks for your help

if the object is going to be still, I'm assuming you would make the entity kinematic because then nothing can move it(am I right in saying this, or can other kinematic entities move each other?)

Correct, kinematics cannot be moved by interactions with other shapes- only direct commands will make them move.

By default, the collision rule (http://bepuphysics.codeplex.com/wikipag ... umentation) between two kinematics is NoBroadPhase, so they cannot collide. Even if this was overridden so that contacts were generated between kinematics, the engine will not attempt to solve the collisions as there is no solution. The result will be the kinematics still ghosting through each other.

On a sidenote, how would you rotate an Entity on or after creation? Im guessing you would edit the world transform of the entity? But then what does the Orientation matrix of the entity do? Thanks

Ok never mind, I figured out how to rotate it using a rotation matrix and setting the orientation to that matrix, works well Is there any planes that are Entities in BEPU? Because at the moment I am using a thin box and it is producing some weird results when pushed onto other objects such as them jumping around.

BEPU Physics is awesome compared to any other engine, good work

On a sidenote, how would you rotate an Entity on or after creation? Im guessing you would edit the world transform of the entity? But then what does the Orientation matrix of the entity do? Thanks

For reference, the core internal representation of the rigid transform is kept as a Position vector and Orientation quaternion. The OrientationMatrix and WorldTransform are derived convenience properties that are based upon the core representation. Setting their orientation changes the Orientation quaternion and keeps everything synchronized.

Is there any planes that are Entities in BEPU? Because at the moment I am using a thin box and it is producing some weird results when pushed onto other objects such as them jumping around.

There is no infinite plane, but a triangle can serve a similar purpose. The things to watch out for when making large environment structures are numerical errors. If the sizes of things get out of hand, the collision detection systems have a harder and harder time figuring out how to create a contact partially due to the limits of single precision floating point numbers. Special case collision detection systems typically handle it better (box-box, sphere-sphere, box-sphere, convex-triangle, and some others).

When creating a 'plane' triangle or mesh, there's two ways to go:
1) Tessellate the mesh such that individual triangles are around the recommended 0.5 to 10 unit range (you can go beyond that range, but it's a safe rule of thumb).
2) Make it one single gigantic triangle so large that no object will ever hit the edges or vertices of the triangle. This works because the convex-triangle is a special case that behaves like a plane-convex test when the object is colliding with the face of the triangle. If objects hit the edges or vertices, the quality will be lower because it has to fall back to more complex algorithms.

BEPU Physics is awesome

Thanks