BEPUphysics

Hello,

For starters, I should alert all, I've been self learning XNA from next to no programming experience. Some java. Had a couple months of playing around, so I understand some, but not to much.

I've basically ripped apart the demo and re-used all the CharacterController and Camera features. I just had the ground breaking experience in understanding that when you add
character.Update(values) in the game Update's, it goes through all the updates defined in CharacterController.

As of right now, I still think that to create to my "player," I have to create that object( character = new characterControllerInput) in the LoadContent, and then update it with the game. I've added the code in Update to allow me to make the character Active.

I used the StaticMesh method shown in the demo to create my game world from a simple model. I've added the ability to fire one of my custom models using the right click, while still being able to shoot cube with left click. I run into a problem with my custom models colliding, but not important.

My first general question has to do with improving the character. My goal for learning is to be able to place two characters, and control one to fire projectiles to the other, deal/receive damage, and respawn.

I do imagine this is a topic that involves a lot more than a simple code example, and for my development, I would like to stay away from exchanging code as much as possible.

Any advice or thoughts anybody would share would be most appreciated. Share the concept more than code example, please.

More Specific to the question:
Do I define a int/double/float in the CharacterController to serve as HealthPoints, and include in the "HandleCollision" a subtraction of that object's hp,and then force a respawn when it reaches 0?

Do I try to create a whole new class called "player" or "avatar" that uses the step, query, and stance manager all the same, but includes the HP?

I have many more questions, including how to give the "Character" a model and collision that matches the model space( instead of a box or cylinder)? This can wait if this concept involves more development.

Do I define a int/double/float in the CharacterController to serve as HealthPoints, and include in the "HandleCollision" a subtraction of that object's hp,and then force a respawn when it reaches 0?

Do I try to create a whole new class called "player" or "avatar" that uses the step, query, and stance manager all the same, but includes the HP?

I would recommend conceptually separating game logic and physics. In other words, a game logic object might 'own' a physical object that acts as its body in the physical world, but that game logic object is not itself a physical object.

This implies the CharacterController should be left to handle the needs of the character's physical simulation, and it should not include any game logic concepts like HP.

For example, the CharacterControllerInput in the demos is just a very simple input logic handler which tells the physical CharacterController what to do. In this case, the CharacterControllerInput might be suitable for use as a "Player" or "Avatar" object, but the CharacterController is not.

For a real game, I would use a slightly thicker abstraction than the CharacterControllerInput. It still deals very closely with a lot of physical logic and, if the CharacterControllerInput was the "Player" object, it would imply the Player was always a CharacterController. (Also, I generally prefer keeping the specifics of user input separated from game logic in a real game.)

The separation's value becomes more evident when the game logic becomes more complex. What if the player jumps into a car? The CharacterController is probably removed from the space because the player isn't a physical 'character' anymore. If the game logic player IS the CharacterController (or the CharacterControllerInput), would the whole game logic player get recreated as a Vehicle (or VehicleInput)? This gets tedious and error prone very rapidly.

Another related example: I sometimes see new users trying to inherit from Box, Cylinder, Entity, and so on to create their own game logic types. This is almost never a good idea. It couples physics representation of a game object with the game object itself, just like making a CharacterController a game logic type does.

Keeping the physics interaction to a simple abstracted interface is nice in terms of portability, reusability, and cognitive overhead. In more detail:
-Keeping the physics at arms length makes it easier to swap out the physics provider, should you need to. (What if I exploded? )
-Using only high level interactions with physics at the game logic level reduces the amount of physics-specific code infesting the game.
-Limiting your interaction with the physics limits the amount you have to think about it. A game logic player implementation that just holds the game logic is a lot easier to look at and understand at a glance than a giant class containing complex simulation logic, plus some other scattered game logic data unrelated to physics.

how to give the "Character" a model and collision that matches the model space( instead of a box or cylinder)?

Generally, it's a good idea for characters that move like FPS characters to just use the simple cylinder approximation. In terms of character motion, handling actual collision detection between individual bones and the environment is almost never worth it unless you're making something like Sumotori Dreams. In that case, the CharacterController pretty much goes out the window.

That said, it's often very useful in FPS-style characters to be able to detect collisions against parts of the character's body for the sake of raycast, projectile, or other attack testing. This is pretty easy- testable objects will have to be positioned according to the animation state of the character (or at whatever level of fidelity your game requires). The collision representation and its mapping from the animation bones can be set up at content creation time.

There's a few different ways of setting up the collision queries in terms of performance. The physics objects might belong to the Space like everything else, but with a NoBroadPhase personal collision rule to stop them from colliding with anything. Or maybe the body pieces aren't in the Space at all, but instead just in a list which you manually run whatever query logic on when you detect that the character's approximate cylinder body was touched.

That process of setting up bones can also be extended to set up ragdolls pretty easily. Some extra information for the joints will have to be included.

I'd like to start of thanking you for your help. I didn't want to reply with 1,000 and one more questions after what you provided really did help me get a better grip on this whole development process.

I've reached the point that where I started to build the simulation as best I can without BEPU, creating my own cameras to perform exactly what I wanted to get out of them, and with helper methods that keep it simple at least for me to manipulate them with. I've also got my handful of models rendering nicely using a basic DrawModel method. broke it more than once trying to play with shaders... tons of fun. No animations yet, and I don't care to talk about them for now.

Simply put, now I find a need to better understand how to use BEPUphysics, and the space you've provided. I think I can handle a static mesh just fine, but using the prefab entities is something I'm not to savy with.
Here's the thing, I don't want it to be complex. I got tons more BS to do with AI logic and shaders.

Another related example: I sometimes see new users trying to inherit from Box, Cylinder, Entity, and so on to create their own game logic types. This is almost never a good idea. It couples physics representation of a game object with the game object itself, just like making a CharacterController a game logic type does.

Well, I don't want to try and re-inventing the wheel. Just look at it like an RTS, I want to basicly abuse the prefab box to make a building, and following your logic provided for the character, all units are cylinders, and all bullets are spheres. At least in collision sense. And I don't want them to roll around stupidly like I've been able to achieve. I've been reusing the Space.Add() function a lot, kinda all I know at this point, aside from playing with mass and velocity.

Got a cheat sheet for how to manipulate to properties to keep from rolling around? I think I can could just make buildings(boxes) kinmetic. I could use this same technique to create static objects in FPS like gameplay. But then moving onto objects that move, specifically people(units), how can I give them ability to stay upright, and give them similar control as demonstrated in the demos game?

I've only been getting the real understanding of making classes and super classes, and it make a lot of sense to me because of my background in IT. It's kinda like inheritenace. there is gaps in knowledge though, like I don't understand "interfaces" and how to use xml config files. But I do my best learning by just jumping into the deep end. I would like to be able to create a bunch of units(cylinders) and give to atleast give them logic to move towards a point.

Anyway, please just help me keep the objects upright, and point me in the directions on how to give each "unit" an sensible method to update itself( for the AI logic crash course I'll give myself ).

I'd also like to thank you for the whole "jumping" in a car point you made. Before I started seriously focusing on this hobby, I had dreamed up an idea that isn't exactly original, but for the theme of the game, gives the game some spice. That's what got me playing with my cameras, and getting into the superclass concept. It really helped me. Developed in understanding the logic.

Thanks a lot for your help.
And please don't explode. I need your help.

Simply put, now I find a need to better understand how to use BEPUphysics, and the space you've provided. I think I can handle a static mesh just fine, but using the prefab entities is something I'm not to savy with.

I've found the best way to do this is to play around in the BEPUphysicsDemos. Together, the demos cover almost everything. Trying to modify existing simulations, extending them to do new things, or just making whole new setups to explore possible approaches tends to clarify how everything hooks together.

Here's a list of demos which you might find most useful, organized roughly into a sort of curriculum:

Entity manipulation:
-LotsOSpheresDemo: Simple construction and placement.
-CoefficientsDemo: Simple demonstration of entity materials. Change the friction and bounciness.
-WallDemo: Simple construction and placement. Try changing the wall's structure and material properties.
-FancyShapesDemo: Slightly more complex convex entity construction.
-CompoundBodyDemo: Building concave objects out of multiple parts.
-EntityConstructionDemo: Various ways of building entities. This tends to be one of the more valuable demos since it goes into depth about Entity objects, the Collidable objects used by entities, and the CollisionShapes used by Collidables.

Static objects:
StaticMeshDemo: Single simple static mesh. Try using another mesh, or creating multiple meshes.
TerrainDemo: Single simple terrain. Try using different heightfield layouts, thicknesses, and transforms.
InstancedMeshDemo: Bunch of meshes sharing the same data. Try changing the mesh, transform, and layout of the meshes. Maybe place some on a Terrain.
StaticGroupDemo: Efficient combination of lots of static objects. Try putting more entity collidables into it.

Joints and constraints:
BridgeDemo: A bunch of planks connected together. Try softening the springs connecting the planks to make it stretch more, or try making it wider for easier driving.
ActionFigureDemo: Simple ragdollish thing with friction in the joints. Try modifying the motor properties to strengthen or weaken the apparent joint friction.
RobotArmDemo: User controllable roboarm. Try changing the structure of the arm and the properties of the constraints, like motor strength.
SuspensionCarDemo2: A car with constraint-based suspensions. Try fiddling with the suspension springiness and connection strengths.
TankDemo: A bunch of constraint-based tanks. Try changing the motors and connections to modify the tank's behavior.

Well, I don't want to try and re-inventing the wheel. Just look at it like an RTS, I want to basicly abuse the prefab box to make a building, and following your logic provided for the character, all units are cylinders, and all bullets are spheres.

I should clarify that you can still use the Box and CharacterController and so on- and indeed, if they fit the need, they should be used- but it's just a bad idea to use those types directly as the game logic objects themselves by inheriting them or by introducing more data into the type. No reinvention is necessary; the game logic objects can use those physics constructs without being those physics constructs.

I've only been getting the real understanding of making classes and super classes, and it make a lot of sense to me because of my background in IT. It's kinda like inheritenace. there is gaps in knowledge though, like I don't understand "interfaces"

To further clarify, when I say 'B inherits from A' when both A and B are classes, I mean 'B is a subclass of the superclass A'. The subclass has an 'is-a' relationship with the superclass, meaning an object of type B 'is an' object with type A, so an object of type B can be put into a field of type A. The subclass also inherits the superclass's implementation.

In C#, interfaces offer another form of subtyping. They still create the is-a relationship between the types. That is, a Message class 'is an' IMessage interface if Message inherits IMessage. However, in contrast to class inheritance, no implementation is inherited. Interfaces have no implementation to inherit. Instead, only the contract of the interface is inherited. A Message class inheriting IMessage is guaranteed to have IMessage's functions visible, satisfying the type's public contract.

Terminology sidenote: often, when a class inherits an interface, the term 'implements' is used in C#. For example, if the Message class inherits the IMessage interface, it is said that Message 'implements' IMessage. This is because Message, being a class which inherits the interface IMessage, must provide an implementation for IMessage's requirements. When an interface inherits from another interface, it's usually just called inheritance.

Another sidenote: C# only allows single 'implementation inheritance'- that is, a class can have only one superclass. This avoids ambiguity in determining the correct implementation to use for a given function. However, a class or interface can inherit from as many interfaces as you want without creating any implementation ambiguity since the interfaces cannot specify implementations themselves.

Got a cheat sheet for how to manipulate to properties to keep from rolling around? I think I can could just make buildings(boxes) kinmetic. I could use this same technique to create static objects in FPS like gameplay.

If you want an entity which won't respond to forces, then making it kinematic is indeed the right choice. However, having too many of these (many thousands) in the Space can be a performance issue. They cost about as much as a sleeping dynamic entity. That's probably not something to worry about until you run into it. If you do run into it, the solutions are pretty simple: toss the static objects into a StaticGroup, or wait for the incoming collision pipeline rewrite that makes it irrelevant.

But then moving onto objects that move, specifically people(units), how can I give them ability to stay upright, and give them similar control as demonstrated in the demos game?

If you want character-like behavior, using the CharacterController is the best option. Robust character behavior is surprisingly difficult to get right.

The CharacterController sets the body's LocalInertiaTensorInverse to the zero matrix to make it stay upright. This is the same as setting the inertia tensor to infinity. In other words, it's got infinite rotational 'mass', so no force can make it rotate.

I would like to be able to create a bunch of units(cylinders) and give to atleast give them logic to move towards a point.

Check out the CharacterStressTestDemo and its variants for a very simple implementation of "AI" applied to character controllers. They randomly run around, jump, and crouch. You could modify the demo's logic to be a little less seizurey.

point me in the directions on how to give each "unit" an sensible method to update itself( for the AI logic crash course I'll give myself ).

That stuff should be handled at the level of the game logic objects. There are a bunch of different ways that side of things can be structured. Since it's not really related to the physics at all I can't provide any special recommendations other than the conceptual separation stuff I outlined earlier. The game logic comes to a conclusion about what to do and what effects to apply to the physics side of things, and then the physics simulate that.

And please don't explode.

I'll try my best!

The CharacterController sets the body's LocalInertiaTensorInverse to the zero matrix to make it stay upright. This is the same as setting the inertia tensor to infinity. In other words, it's got infinite rotational 'mass', so no force can make it rotate.

Spot on, worked like a charm for the playing around I was doing.

Check out the CharacterStressTestDemo and its variants for a very simple implementation of "AI" applied to character controllers. They randomly run around, jump, and crouch. You could modify the demo's logic to be a little less seizurey.

Oodles of fun! I had reduced the number of characters so I focus on the group a little better. I ended up somewhat coping how you created CharacterControllers, and added them to a list, and had my CCs all running to a point and basically fighting over it. I still didn't program any logic for them to create projectiles to fire at each other, but they bully each other back and forth. I have yet to experience any bottleneck regardless the number of units I add.

Hench my next handful of questions. I hope I'm not becoming a nuisance.

For Starters, I've been attaching a model to the CharController. Its been successful for the most part, but I'm personally having trouble controlling the direction its facing. Do you think this is the best method to "pin" on a model, not considering giving it's shape itself a collision model. And how would be the best method to ensure the model faces the direction of the Controller? I've played around with messing with ViewDirection, HorizontalViewDirection, Orientation, but I'm not quite getting what I want. I noticed you typically have the view direction controlled by the camera's direction, but I'm trying to use the Controller independently. I may just suck at understanding how to use the Matrix and Quaternion creation methods appropriately. Currently reading up on the Vector normalize methods now.

My next goal is to create a camera that can stick to one of the models, and watch the direction it faces as it moves mindless forward to a point.
I've already got the idea of how to make it move to that direction without turning, basicly apply a vector2 to movementdirection that is the destination - body location.

Thinking about it, I believe I need to
Get position
Get view direction
Get destination location
Perform a method like Matrix.CreateLookAt(position, destination)
and turn the direction overtime until it matches the createlookat.

Close? No cigar? Any thoughts? Really appreciate your help.

My next questions comes down to understanding how units are Added to the space.
This thought comes from how you use a list to manage each created character and sphere character. The i variable is used to call on units separately. I don't really know how to word this question... but HOW? What gives each object in space its uniqueness? And can I manipulate that feature to pick one unit of the list, and get its specific position and orientation and what not, and ensure I'm getting the same "object" when I remove other objects from the list. I've got some dB experience, so the term Primary key makes sense to me, if it applies to this situation.

One reason I ask is because i was debating on playing with viewports and multi cameras, and I was thinking that I would ultimately need to make separate lists for separate players/teams.

Do you think this is the best method to "pin" on a model, not considering giving it's shape itself a collision model.

It'll involve some sort of drawing a representative model using the CharacterController body's position (and orientation, if it's a game where the character can rotate). The EntityModel is an okay method to have a graphical model follow the CharacterController's Body entity, but it's not made to handle all the things a character would do.

And how would be the best method to ensure the model faces the direction of the Controller?

Note that the CharacterController's body never actually changes orientation. Its inertia tensor is set to infinity. When it's changing direction, all its doing is accelerating in a different direction, not rotating.

In other words, the facing direction (that is, the CharacterController.ViewDirection) is an input to the character simulation, not an output. So, it's up to you to decide what direction you want the character to face for graphical purposes and for character input purposes.

For human players, this is usually defined by the camera, but that's not the only way to handle it. For example, NPCs can choose which direction to face without any camera involved based on some simple AI.

I've played around with messing with ViewDirection, HorizontalViewDirection, Orientation, but I'm not quite getting what I want. I noticed you typically have the view direction controlled by the camera's direction, but I'm trying to use the Controller independently.

Some details:
The ViewDirection, in combination with the Down direction, is used to interpret the HorizontalMotionConstraint.MovementDirection. The ViewDirection is projected onto the plane which has the Down direction as a normal. The result is the HorizontalViewDirection. A third and final axis is the StrafeDirection, which is perpendicular to both the HorizontalViewDirection and the Down direction.

If HorizontalMotionConstraint.MovementDirection is set to a normalized vector (X, Y), the character's goal motion will be X * StrafeDirection + Y * HorizontalViewDirection.

I should clarify that the 'ViewDirection' is not fundamentally linked to anything camera related.

This system is used over a simple Vector2 world space X-Z movement direction because the character's 'down' direction can be changed. If 'down' isn't (0, -1, 0), trying to apply forces on the world XZ plane would be incorrect.

Close? No cigar? Any thoughts? Really appreciate your help.

The Matrix.CreateLookAt function, specifically, creates a view matrix- a transform designed to take objects in world space into camera space. Matrix.CreateWorld would be what you want.

If the goal is just to change a direction over time to match another direction, then something like that would work, though it's doing more work than it technically needs to.

You could probably get away with a simple linear interpolation between two direction vectors, provided you watch out for singularities when interpolating between opposing vectors and renormalize the result. The angular velocity of the direction won't be constant with a pure lerp, though. If you care to avoid that, you could use a full Quaternion.Slerp with orientations built on the directions (a little heavy, since you don't care about the third degree of freedom), or perform a lerp on a rotation angle around the axis perpendicular to both input directions.

The i variable is used to call on units separately. I don't really know how to word this question... but HOW? What gives each object in space its uniqueness?

In low level terms, the list contains references to objects. Those objects maintain their own persistent physical state over time. The objects are unique because they are in different places in memory.

And can I manipulate that feature to pick one unit of the list, and get its specific position and orientation and what not, and ensure I'm getting the same "object" when I remove other objects from the list. I've got some dB experience, so the term Primary key makes sense to me, if it applies to this situation.

If the list is reordered, the object reference at a given index may end up referring to a different object than originally. The index does not necessarily stay associated with a specific instance in memory. It's just an index into an array of references.

The CharacterControllerStressTestDemo doesn't maintain any external state about the characters. It doesn't need to know if a character reference at index i is the same reference as it used to be, because that knowledge does not influence what the character will be told to do. The seizure-AI doesn't need to know anything about past state.

If you wanted to associate nonphysical state with a character to make more interesting, less blind decisions, like "I was trying to get to point X based on a goal because Y told me to a while ago and because of that I should...", then that'll have to be stored in some way that your update process can access it.

One possible C#-ish way of dealing with that would be to store a collection of game logic objects (instead of direct physics references) which in turn contain references to all the things they need to operate, like the physical character, the AI subsystem, the player input, or whatever else.

Well, I've kinda set myself on this "roadmap." Ive got cameras to functions. I've been able to draw my models. Im able to create objects with collision shape.
Now I'm stuck on creating the things to populate in my game other than lame ojects with collision.
We've had plenty of back and forth about the CharacterController, and from my point of view, it looks like the single thing I need to "master" and morph to my own purposes.

Should I try to make my own? Something that can be reused for each "sprite" or "unit" in the game? Would it allow me to give it attributes like "health", "endurance" and "ammo", as well as provide the cylinder entity I need to represent the body in the space. I was thinking doing this might help me understand how to make the unit's model face the direction I want it to at all times. I definitly want each unit to do that independant of the camera, and when I get into picking the unit to play as, we just move the camera to that unit's eye-level. The camera will always be a "slave" to other objects.

If I go this route, should I mirror the stance, query, step managers? and the constraints?
You keep telling me you would use something more robust, but I don't have an example of such to learn from. And the thing is, I really want to keep it pretty simple, to keep it modular. I feel like the controller gives me everything I would need for my game's purpose, aside from the health and other properties.

And another question that I probably shouldn't ask yet, how would I implement pathfinding using BEPUphysics? I've been reading heavy on A*. No need to go into major details, I still barely grasp the topic.

Should I try to make my own? ... If I go this route, should I mirror the stance, query, step managers? and the constraints?
You keep telling me you would use something more robust, but I don't have an example of such to learn from.

There may have been a miscommunication: the CharacterController is very robust, and it is what you should use for character physics.

If the CharacterController has the desired physical behaviors, definitely do not make your own character physics. Making a robust, feature-filled character from scratch is one of the harder things to do in the realm of game physics.

Would it allow me to give it attributes like "health", "endurance" and "ammo", ...
I was thinking doing this might help me understand how to make the unit's model face the direction I want it to at all times.

All of that would be best managed at the game logic level, outside of the physics representation.

And another question that I probably shouldn't ask yet, how would I implement pathfinding using BEPUphysics? I've been reading heavy on A*. No need to go into major details, I still barely grasp the topic.

There isn't really any overlap between pathfinding algorithms like A* and physics. A* and similar algorithms are used to plan routes. The algorithms themselves aren't related to how the routes are executed. The output of A* could be used to tell an NPC which way to go, and the NPC could then give the CharacterController input about how to move in the physical world to accomplish that goal.

For other forms of AI, like collision avoidance, there's a closer relationship. Usually, collision avoidance is implemented using either a bunch of ray casts or sweep tests in front of the character to find obstacles. The results of the queries inform steering. This is nice for short term planning like not ramming into other characters while following an A*-computed path, for example. However, collision avoidance doesn't require a physics engine to work; anything which can provide queries about obstacles would suffice.

All of that would be best managed at the game logic level, outside of the physics representation.

Well, I'm an idiot. I kinda don't have any clue how to do that. Now I'm looking at the Demos again, trying to really understand the magic behind some of the not so obvious stuff. Like how you create a camera, and really just move the thing for each simulation you load. Still a bunch I don't get. Really find it cool though, Kinda adopted it for my own levels, but I'm bound to really break it soon. I kinda morphed Demos and Standard Demos to mean Level and Standard Level to me.

I was thinking about REALY messing it up in an attempt to "make my own game logic", since I'm such a newb. I was going to try to sneak in a class inbetween Demos and Standards Demo to create "players" for each "Demo" I load. That was where I was going to add a value to represent Score for each player.

Then I still run into the problem of needing to make my "units." In each game, at the start, the player(and his Camera), get "stuck" to the unit, and the input moves that unit around.

My thought about making Units is trying to bang out a class that uses CharacterController like CharacterControllerInput. I'd appreicate your critisim. I've been writing this on paper in attempt to "sculpt it"


Some things I will do differant is how to Add or Remove the object from the space, I want it to be Added HigherUp, and then I'll add some stuff to just move it to a vector3 when it "respawns", and then I'll get into Removing it when I start playing with larger numbers. This is rough and really just an attempt at picturing it, but is it going in the right direction?

I hope I'm not getting annoying yet.

I kinda don't have any clue how to do that.

That Unit class you posted is one possible form of it. The posted Unit isn't itself a CharacterController (it does not inherit from CharacterController), but it owns a CharacterController and other properties needed by the game. That's fine.

My thought about making Units is trying to bang out a class that uses CharacterController like CharacterControllerInput. I'd appreicate your critisim. I've been writing this on paper in attempt to "sculpt it" ... is it going in the right direction?

Getting there; it's certainly possible to make something like that work out.

There are a few potentially unnecessary things in it that might introduce some grossness later on, but that sort of stuff is often best discovered by just ramming into it as fast as possible and refactoring the code as needed. This is even more true when dealing with unfamiliar territory and when the implementation wouldn't take that long to try.

Norbo, you are the shiznizz. I've had to do some reading of your earlier peices of advice, but its really starting to come together. Still having problems though. I had something kidna working in one demo, then I started over to using things that worked and i'm trying a differant direction. I started playing with Viewports. MAN did I BREAK IT! Thinking about the concept of Players and teams so I can make units attack each other and so on.
Getting results with how I'm using Character Controllers.

My question is more along the lines of C# programming in general.
Interfaces. How do I really use them?
For example, I make a unit using charactercontroller. I want a simplier way to add it to the space. I was looking at how alot of your objects "inhererit" from interfaces. Like how StaticMesh uses StaticCollidable in the demo.

I was thinking about using a similar method to give my Units ISpaceObject properties so I could easily add them to the Space.

Interfaces. How do I really use them?

In standard practice, they're handy for guaranteeing an object's public contract. A good example is the .NET framework's collections and collection interfaces. For example, IList<T> is implemented by a variety of list-like classes, including List<T> and arrays. So, if you have a function that takes an indexable collection of objects, you can choose to accept an IList<T> instead of a List<T>. That allows the caller of the function to conveniently pass a List<T> or any other compatible type.

[Digression: In contrast, BEPUphysics's interface types and their usage could fairly be called... exploitative. While the interfaces do guarantee certain implementations, the real reason they exist is to give the Space a way to parse an added object into the necessary subsystems by analyzing the type. It's not illegal or invalid or even particularly weird to do this, but if you take a gander at the Space.Add function, it's not exactly elegant. These are leftovers from an earlier redesign that tried to 'overabstract' the engine by pulling a lot of stuff into interfaces and superclasses.

The result is a pretty loosey-goosey API with a lot of unusual/unknown/unhelpful flexibility that, as far as I'm aware, not a single person has ever really used- except occasionally someone might look at it and consider trying to add nonphysics stuff as a custom ISpaceObject.

Over time, the engine has been going through a slow re-rewrite which is pulling the engine into more concrete pieces without any loss of useful abstraction. ISpaceObject and many of the other "marker" interfaces are likely going to die as a part of this process eventually, yielding a more direct API with fewer erroneous degrees of freedom.

The point of all of that being roughly: don't get too infatuated with various kinds of abstraction. Trying implementations, getting a feel for where the abstraction is actually valuable, and refactoring when needed tends to work out a lot better.]

I was thinking about using a similar method to give my Units ISpaceObject properties so I could easily add them to the Space.

I would strongly recommend against trying to add a whole game logic "Unit" to the Space, since the Unit is not exclusively a physical object. The BEPUphysics Space is where physical objects live. If there is a need to maintain sets of game logic objects, do it outside the physics engine.