BEPUphysics

Norbo wrote:There is no BaseEntity class in BEPUphysics, so I'll assume you're referring to the top level Entity class.

I saw a file named EntityBase, and I assumed the class inside was called such. =p

Norbo wrote: 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.

Okay. I'll see what I can do... I think what I'll do is have a Box entity inside each Container that doesn't respond to collision and then move that with EntityMover and such, then apply that world transform down into the lists.

I think what I'll do is have a Box entity inside each Container that doesn't respond to collision and then move that with EntityMover and such, then apply that world transform down into the lists.

Just to clarify, you don't need EntityMovers to move an entity; they're just for convenience when you're trying to follow a path. The Entity class itself has all sorts of properties and functions to move it around (LinearVelocity, AngularVelocity, Position, Orientation, ApplyImpulse, etc.). Graphics can be positioned based on the entities' positions and orientations. It has a WorldTransform property for convenience when transforming models.

A tightly-controlled entity (no natural dynamics) without collision (no collision detection or response) won't be much of an entity. Such a thing might be useful for detecting nearby objects with collision events, but if you aren't using it for such, it doesn't sound like an entity is even necessary.

You may already know all of this, but I'm still very vague on how everything's interacting, so better to check than let you get trapped down a well for no reason

Norbo wrote:

I think what I'll do is have a Box entity inside each Container that doesn't respond to collision and then move that with EntityMover and such, then apply that world transform down into the lists.

Just to clarify, you don't need EntityMovers to move an entity; they're just for convenience when you're trying to follow a path. The Entity class itself has all sorts of properties and functions to move it around (LinearVelocity, AngularVelocity, Position, Orientation, ApplyImpulse, etc.). Graphics can be positioned based on the entities' positions and orientations. It has a WorldTransform property for convenience when transforming models.

A tightly-controlled entity (no natural dynamics) without collision (no collision detection or response) won't be much of an entity. Such a thing might be useful for detecting nearby objects with collision events, but if you aren't using it for such, it doesn't sound like an entity is even necessary.

You may already know all of this, but I'm still very vague on how everything's interacting, so better to check than let you get trapped down a well for no reason

Interesting... I'm still really new to the engine, and things don't do what I'd expect them to do. ;D Paths would be nice though; the Container moves to the end of a path (either rotating, translating, or a combo of both), stops, and then when the activation key is pressed again moves back. So, paths would be handy, for sure, but since all the objects move in tandem it makes great sense to have one overlying EntityMover/Rotator which somehow moves all of them, either by moving a placeholder or by trickling down to each of them (which I would like to do, but since EntityMover needs an Entity to move... I may just take a look at the EntityMover's source and see if I can't redneck together a version that works how I want). Because setting a field on seven things is faster than calling seven sets of methods. I did know about WorldTransform, I do use that already (it's what I was thinking about using for the placeholder Box; multiplying my other World matrix by its WorldTransform).

I should note that you don't even have to use EntityMover/EntityRotator if you want to follow paths (though an example of using them to do so is available in the PathFollowingDemo). They fundamentally just change the velocity of an entity. You can change the velocity of an entity directly through the entity's properties.

Their convenience comes from computing the necessary velocity to reach a goal position and providing tight control of both kinematic and dynamic entities through a common interface. None of it is magic, though; it's all fairly trivial operations that can be done externally. In other words, don't feel bound to the EntityMover/EntityRotator.

It sounds like the ghost object is completely unnecessary. I still can't quite tell what the end goal is, but it seems like the route you're on is overcomplicating things a bit

If you're trying to treat a bunch of separate entities as a single entity, consider just using a CompoundBody of the shapes instead- that's what it is made for.

If the stuff being moved isn't associated with entities or physical objects at all, it should be done outside of the physics engine entirely. Transforming some graphical models around is trivial and fast compared to jumping in and out of physics.

Norbo wrote:I should note that you don't even have to use EntityMover/EntityRotator if you want to follow paths (though an example of using them to do so is available in the PathFollowingDemo). They fundamentally just change the velocity of an entity. You can change the velocity of an entity directly through the entity's properties.

Their convenience comes from computing the necessary velocity to reach a goal position and providing tight control of both kinematic and dynamic entities through a common interface. None of it is magic, though; it's all fairly trivial operations that can be done externally. In other words, don't feel bound to the EntityMover/EntityRotator.

It sounds like the ghost object is completely unnecessary. I still can't quite tell what the end goal is, but it seems like the route you're on is overcomplicating things a bit

If you're trying to treat a bunch of separate entities as a single entity, consider just using a CompoundBody of the shapes instead- that's what it is made for.

If the stuff being moved isn't associated with entities or physical objects at all, it should be done outside of the physics engine entirely. Transforming some graphical models around is trivial and fast compared to jumping in and out of physics.

Alright. I think what I'll do is poke around the EntityMover class and see what it does, and then go from there.