Creating Entities out of my own models?

[snoozbuster]

I have three "types" of models, if you will. The first never moves. That's easy, I can use StaticMesh. However, I have models that aren't affected by gravity and only move on command, to which they usually translate/rotate. I've got my own code for this, but if there's a tutorial on springs or whatever you've got around here, please link me. Anyway, I'm not sure how to make these static models that move. I'm also not sure how to take my own models and create Entities out of them. I would love it if you could help me out with the right classes and such; the classes that seem like they would work are abstract. Thanks!

[Norbo]

I have models that aren't affected by gravity and only move on command, to which they usually translate/rotate.

Be careful here; if an object teleports, the solver will not have any velocity to work with and collision response will be 'squishy' because position correction is the only force capable of running.

If the goal is some kind of movable 'unstoppable force' object which never responds to any collision or force (like gravity) and effectively has infinite mass and inertia, then a kinematic entity is the way to go. When constructing an entity, there's a mass parameter available in the constructor overloads. If it is defined, the object is dynamic and has finite mass and inertia. If it is not defined, the entity is kinematic.

You can also switch the state of an entity after construction using the BecomeKinematic and BecomeDynamic methods, though if you can, doing it in the constructor will avoid extra initialization.

If the kinematic entity needs to move around, it should be controlled using velocities. If the velocities are correct then collision response will have enough information to prevent squishiness. If you have position goals, you can compute a velocity to reach those goals over time (velocity = displacement / time). The EntityMover and EntityRotator classes do this automatically for the purpose of following paths, as can be seen in the PathFollowingDemo and CharacterPlaygroundDemo (in the BEPUphysicsDemos project source, contained within the main source download).

if there's a tutorial on springs or whatever you've got around here, please link me.

For the ways you can constrain dynamic objects to other dynamic or kinematic objects or the environment, look here: http://bepuphysics.codeplex.com/wikipag ... umentation

There's a ragdoll demo linked on that page, but that can be a little daunting to start with. The BEPUphysicsDemos source project contains a bunch of simpler isolated setups that might be easier to learn from to start with. For springs in particular, the idea is just to start with a normal constraint of the proper type and adjust its SpringSettings. By default, the SpringSettings have values very close to rigid (high damping and high stiffness).

I'm also not sure how to take my own models and create Entities out of them.

There are a lot of different ways to construct entities; an overview can be found in the EntityConstructionDemo in the BEPUphysicsDemos project.

For mobile meshes specifically, there's a built-in 'prefab' type called MobileMesh. The prefab entities are just convenience wrappers that make constructing entities a little easier and allow more of their internal data to be exposed through the Entity's properties because of the fixed type. For example, you can create an entity which has a mesh shape without using the MobileMesh class and instead just pass a MobileMeshShape to an Entity constructor, but the entity's CollisionInformation property will return the abstract 'EntityCollidable' type rather than a 'MobileMeshCollidable.' The EntityConstructionDemo goes through all of this and more.

However, care should be taken when using MobileMeshes for dynamic objects. By nature of being a bunch of individual triangles, the mesh is going to be a slower representation than an approximation like a bunch of box shapes put together in a compound shape. If at all possible, I would recommend approximating the geometry in the physics by using simpler, fewer, faster primitives (box, sphere, convex hull, etc.). This advice does not apply to big chunks of level geometry- the StaticMesh is well suited for that.

[snoozbuster]

Alright. I'll definately check out those links and tutorials. The first part, though, I'm not totally clear on. I do need the objects to be unaffected by gravity or collision with other kinematic objects, but they are going to need to move around when commanded and collide with dynamic entities. Can kinematic objects be affected by velocity and/or springs, and thereby be moved around? If so, what class would I need to use to make such a psuedo-kinematic object?

Also, the only real dynamic object I need is, in fact, a box, but I don't want to play with scale and then apply the texture to it, and I'd like it to be able to support other objects, so I was trying to use MobleMeshShape and MobileMesh to generate data, but I'm not sure if it actually worked (I got distracted with other projects, and then college started).

[Norbo]

I do need the objects to be unaffected by gravity or collision with other kinematic objects, but they are going to need to move around when commanded and collide with dynamic entities. Can kinematic objects be affected by velocity and/or springs, and thereby be moved around?

Kinematic entities:
-Move when a velocity is manually specified by setting the LinearVelocity or other conceptually related properties.
-Happily go through other kinematic entities or static geometry.
-Push dynamic objects around without slowing down.
-Do not move in response to collisions.
-Do not move in response to constraints (which a 'spring' would be).

The velocity of the kinematic could be set manually to simulate a kinematic being affected by a spring. However, it would be unwise to connect such a spring to a dynamic entity with the intention of having a two-way interaction between the entities. If that behavior is needed, then the object should be dynamic, not kinematic, and a proper constraint should be used.

Note that dynamic entities can have their IsAffectedByGravity turned off and their collision rules altered such that they don't collide with certain other objects or groups of objects. More information about collision rules can be found here: http://bepuphysics.codeplex.com/wikipag ... umentation

If so, what class would I need to use to make such a psuedo-kinematic object?

Kinematic entities are just instances of the Entity class or its children which were either constructed without a mass/inertia parameter or were turned kinematic after the fact. Any entity can be made kinematic.

the only real dynamic object I need is, in fact, a box, but I don't want to play with scale and then apply the texture to it, and I'd like it to be able to support other objects, so I was trying to use MobleMeshShape and MobileMesh to generate data

In addition to performance, I should also mention that the primitives that approximate the actual shape will behave more robustly as well.

[snoozbuster]

In addition to performance, I should also mention that the primitives that approximate the actual shape will behave more robustly as well.

What exactly does that mean?

[Norbo]

For example, a Box will behave more robustly in general than a mesh representing a box. Similarly, a Sphere will be much faster and more robust than a mesh representing a sphere. Collisions will be more correct and the chance of something 'weird' happening will reduce.

Mesh collisions are based on a bunch of per-triangle collision tests (pruned with an acceleration structure, of course). Each test, in the worst case, is about as expensive as a single general convex-convex shape test. That's not too bad, and certain configurations (face collisions) are faster. However, triangle geometry is extremely thin, so it's numerically harder for the collision detection system to handle. Usually this doesn't cause any noticeable problems, but it does make the algorithms work harder for a possibly worse result.

After the collision tests, the contacts are taken together to form a contact manifold. The logic for this is more complicated for a mesh than a simple convex object. Not only do you have to worry about backfaces and triangle boundaries, but the manifold cannot be known to be convex, which introduces some extra complexities.

In other words, for optimal behavior and performance, mobile meshes should only be used when they are truly necessary- which isn't that often.

[snoozbuster]

In other words, for optimal behavior and performance, mobile meshes should only be used when they are truly necessary- which isn't that often.

Alright, then, so the important question now is how do I apply my texture and/or UV coords to Box?

[Norbo]

The physics engine is completely separate from and doesn't know/care about the graphics used to represent collision geometry. You can use a graphical mesh to represent a physical Box entity. The GettingStartedDemo/BasicSetupDemo show a stripped down example of how to transform a model to follow an entity, amongst other things: http://bepuphysics.codeplex.com/wikipag ... umentation

The basic idea is that you use the entity's position/orientation (conveniently represented by the Entity's WorldTransform property) to transform the mesh. Usually, you'll find the mesh wasn't centered in the same way as the physics object, so it will be offset by some amount. To address this, you can first apply a translation that puts the graphical mesh in the proper location in local space before transforming it using the WorldTransform.

[snoozbuster]

Alright. Hopefully I'll be able to get everything working now. Thanks for your help!

[snoozbuster]

Kinematic entities are just instances of the Entity class or its children which were either constructed without a mass/inertia parameter or were turned kinematic after the fact. Any entity can be made kinematic.

I've hit a small snag. I was trying to do what you said, make an Entity, but I haven't figured out how to make an Entity from my own model. I can use MobileMesh to do it, but like you said that's not all that accurate (although I am using MobileMeshSolidity.Solid). I don't want to approximate because I will have to either guess and check the data for all my models or write an importer, neither of which I'm fond of doing. Is there another way?

[Norbo]

I can use MobileMesh to do it, but like you said that's not all that accurate (although I am using MobileMeshSolidity.Solid).

It should not be really noticeable, especially in simple situations; if you're noticing significant problems, there may be something else going on. A common problem is improper scale. The engine likes individual objects (like triangles within a mesh) to be in the 0.5 to 10 units range. If you go significantly smaller than that, you will run up against a variety of tuning variables that were based on the 0.5 to 10 unit range. While they can be reconfigured, it's not easy to get them all right. Going significantly above the range will gradually increase the chance that you run into numerical problems.

I don't want to approximate because I will have to either guess and check the data for all my models or write an importer, neither of which I'm fond of doing. Is there another way?

There's not really another fundamental approach, since it's a dichotomy: use the mesh directly versus don't use the mesh directly. If you want speed and usually better robustness, approximate. If you want don't want to make approximations, don't approximate

There is one way to automate the approximation. It's called convex decomposition. I haven't implemented explicit support for it in the engine, but it could be added externally. Basically, you can create multiple convex hulls from the mesh as necessary to maintain desired concavity and stick them into a CompoundBody.

However, for almost all smaller shapes, you don't need a concavity. Passing all the mesh vertices (possibly of a simplified physics mesh) into a single convex hull shape would be fine. Note that convex hull performance degrades roughly linearly with the number of points in the hull; try to keep it low.

When dealing with performance, it's always better to use the simplest representation possible. ConvexHulls are pretty quick when they have a reasonable number of vertices, but a Sphere or Box (or other simple shape) is pretty much always going to be faster.

[snoozbuster]

Alright. Thanks for that clarification. I do have another question about the best way to go about with the thing I'm working on, though.

I have a container class that holds lists of all my various enhanced models, and I want it to be the object translating/rotating and then sending the data to its lists about how to change position. However, the container class had no relation to Entity at all. So I thought I'd have each BaseModel have its own mover/rotator and then just communicate the path, direction, and also if it needed to be moving to the lists. That, however, seems to be highly inefficiant in hindsight. So, my question is this: Should I leave it as it is right now, should I change BaseModel to inherit from BaseEntity (since it already contains an Entity object), should I change my container class to inherit from BaseEntity, or should I use a ghost Box approximating the size of my container for the Entity? Which would be easiest? Which would the engine support more easily? Which would work faster? =p

Thanks for your help.

[Norbo]

Should I leave it as it is right now, should I change BaseModel to inherit from BaseEntity (since it already contains an Entity object), should I change my container class to inherit from BaseEntity, or should I use a ghost Box approximating the size of my container for the Entity? Which would be easiest? Which would the engine support more easily? Which would work faster? =p

I have no idea

I seem to be missing a lot of context, so I can't really answer your question. I can still provide a couple of general-purpose pointers which might help.

A common approach is to have a game logic object have an Entity reference for its physics proxy. If the entity needs to know which game logic object it is associated with, you can put the game logic object in the Entity.Tag property. There's also a separate Entity.CollisionInformation.Tag property which is associated with the collision proxy of the physics entity; the collidable's Tag is usually easier to access from the context of collision events.

[snoozbuster]

A common approach is to have a game logic object have an Entity reference for its physics proxy. If the entity needs to know which game logic object it is associated with, you can put the game logic object in the Entity.Tag property. There's also a separate Entity.CollisionInformation.Tag property which is associated with the collision proxy of the physics entity; the collidable's Tag is usually easier to access from the context of collision events.

Let's see if I can explain it better.

I have a container class (we'll call it Container) that holds lists of enhanced Models (we'll call that class Model). Each Model holds an Entity, an EntityMover, and an EntityRotator.

Option 1: Make Container inherit from BaseEntity, and use Container as the Entity in EntityMover/Rotator, then apply the transforms to Container to the things it contains via something or another.

Option 2: Do nothing, and leave things the way they are (which may or may not be a good idea, this part of my code is really fragmented and messy from rewriting).

Let's put it like this... What would be the purpose of making something inherit from BaseEntity?

[Norbo]

There is no BaseEntity class in BEPUphysics, so I'll assume you're referring to the top level Entity class. Extending from the Entity is rarely a good way to architect game logic. It's inherited from internally by the MorphableEntity and Entity<T> (which is in turned inherited by all the prefabs). The EntityConstructionDemo shows examples of how these differ.

Option 1 seems to overcomplicate things by jumping in and out of inheritance trees/ownership graphs and bundling game logic tightly with physics data. I still can't judge Option 2 due to insufficient context, but it seems you don't like it too much.

So, I choose Option 3 Something with a clear separation of game logic, physics, and graphics and explicit management of how they interact would be beneficial. Unfortunately, with the information I have, I can't offer much more than that.