BEPUphysics

Hi!
We are making a simple game in XNA 4.0 akin to Castle Crashers but in 3d. We are now trying to implement collision detection but the built-in XNA instruments (sphere and box) are insufficient. What we need is a per-polygon collision checks for static objects and per-bone checks for skeletally-animated ones. We are going to use orthogonal projection in our game and the problem with it is that it does not react to screen resolution properly. We have to scale all the objects in the world to make sure they appear on the screen correctly. That messes up game logic quite badly. So I thought it would be better if our artists would pack the models they create with another MeshPart that will be used for collision detection, then it will get scaled and moved/oriented with the model automatically and we will simply occlude it when drawing things. The bone system gets scaled ok so I guess all we need for the skeletal models would be a system of spheres, created for each bone to check collisions against.

My questions are:
- does the library support per-polygon collision checks? If yes would I be able to simply pass two MeshParts to the library and get true/false answer if they collided?
- what solution does the library have for skeletally-animated models, that remain in their t-pose all the time at the cpu level, while only their shapeless skeleton gets animated?
- would it be an overkill to use the library for a simple game like Castle Crushers, that would only require per-polygon collision checks and, most likely, no gravity/ragdoll/bullet physics?

Thanks.

does the library support per-polygon collision checks? If yes would I be able to simply pass two MeshParts to the library and get true/false answer if they collided?

Yes, it supports mesh-mesh collision tests. You would not be able to provide an XNA MeshPart directly, though. It needs to be a BEPUphysics mesh type (e.g. the MobileMesh).

You can use the NarrowPhaseHelper.Intersecting function to perform a one-off test between two collidables, but this is not a natural usage of the engine. Generally, the objects are added to the Space, the BroadPhase determines which pairs need testing, and then the NarrowPhase performs the per-pair tests. Each collision pair maintains state over time; quality and performance improve when the state is available compared to a bunch of separate one-off NarrowPhaseHelper.Intersecting tests.

- what solution does the library have for skeletally-animated models, that remain in their t-pose all the time at the cpu level, while only their shapeless skeleton gets animated?

The library is completely oblivious to graphics, so there is no built in system that specifically handles skeletal animations.

If you want to detect collisions with an animated model, the usual method is to position some simple shapes (spheres, boxes, cylinders, capsules, or whatever else) according to the animation and use them to detect collisions. There is no helper built in for moving objects according to animations; you'll just have to set the position and orientation as desired.

would it be an overkill to use the library for a simple game like Castle Crushers, that would only require per-polygon collision checks and, most likely, no gravity/ragdoll/bullet physics?

Possibly. It can definitely handle that type of use case (i.e. primarily a collision detection pipeline), but it's usually just as easy (and sometimes easier) to use full physics.

I would recommend playing around in the BEPUphysicsDemos to see how things are set up.

Thank you very much for a prompt and detailed reply, I greatly appreciate that. Well your answer told me we would have to learn quite a lot of stuff to be able to work with the library, many more than I thought . Moreover, the fact that we would need to transform our meshes to make use of them for collision and the fact that we would need to attach simple shapes to skeletal models helped me to understand that we need a simpler solution.

As I said we will use orthogonality in our game, which has an unfortunate disadvantage of not reacting properly to the screen resolution changes, which forces us to scale everything in our world to fit the screen properly. That led me to conclusion that we need to ask our artists to pack models with collision cubes. They will scale alongside the model, and move with the model. We will only need to skin them manually for skeletal models, but that is not a problem. But than the question remained how would we use them to check for collision. The answer is, we would extract their vertices and write our own collision-check formula. That would be better for us as we are complete newbies to 3d graphics and the scale and specifics of our game really does not need the full-scale physics engine.

In any case, thank you very much for your reply and good luck with the library!

P.S. A little bit of spam at the end . Here is our game's website: http://z-h-i.com/