BEPUphysics

By the way, if you're using noResponse as a CollisionRule between trigger entities and other entities, the cost associated with doing the collision check to generate contacts is generally orders of magnitude greater than the event processing. For range checking in particular, your best bet would be ...

If you re-use the same dictionary/collisionRules instance across a variety of entities, you will have to do very few operations (amounting to nanoseconds) when things are created or destroyed. However, it may end up being more complicated overall for your specific situation than doing it another way...

The ideal solution for building a robot would be the modules connected by constraints. The constraints would keep the robot together, serve as motors when needed, and possibly supply friction. Unfortunately, BEPUphysics does not have explicit support for all the constraints necessary in v0.10.0. v0....

I can see how it could become problematic if you did have a group for every entity, but I don't think I understand why you need a group for every entity. It sounds like the specificEntities list might help out a bit. You could add a bunch of entities to an entity's collisionRules' specificEntities l...

While I may do something like this, you can accomplish what you want to do by creating a collision group that represents the combination of the two other CollisionGroups. Basically, if you give an entity multiple CollisionGroups, the final rule will be equivalent to using a single collision group wi...

To clarify, no, you do not need both a relationship between group A and group B and between group B and group A. The two orderings are considered equal as far as the equality comparer and hash code are considered, so a rule between two groups can be thought of as 'two way.'

CollisionGroups were not designed primarily to prevent collision between groups of entities, but rather as a more general way to manage interactions. That's why it defaults to normal if no other rule is specified. For every simulation that would benefit from having group relationships default to noP...

By default, becomeDynamic/becomeKinematic do not change the collisionGroup of the entity. They have a secondary overload that lets you pass a collision group, or you can set it afterward. The reason the object falls through the terrain is because it still has the defaultKinematicCollisionGroup from ...

If you haven't checked the main page, BEPUphysics v0.10.0 is ready!

Check it out at http://www.bepuphysics.com.

Quick update; this is implemented in v0.10.0 as EventHandlerCollisionPairUpdating, EventHandlerCollisionPairColliding, and their "immediate" versions. The updating event occurs every single time that a collision pair associated with the entity with the event hook has its contact manifold u...

There is an overload of the Space.rayCast method that returns every hit along the ray up to a maximum distance. Using it will allow the ray to continue.

After the initial detection, you could also just raycast some other structure, like your own mesh representation.

You could use an outer shape (such as the capsule itself) that fully contains the player's limbs, head and torso to detect the initial raycast. Then, test against a separate set of 'body' entities. You'd need to set up some shapes that represent the character's body (or at least the shootable parts)...

Turns out it made it into v0.10.0.

Relevant events now also have an "other" entity parameter which is whichever collider that isn't the sender.

I'm aiming to have it out in the next few days. I'm on track so far, assuming I don't hit any showstopping bugs.