So I am guessing that if I wanted to check collisions that do now produce physical response (what Unity calls a trigger collider) a BroadPhaseEntry would be the way to do it?
A BroadPhaseEntry would be at least involved, yes.
The easiest approach is to take an entity and change its Entity.CollisionInformation.CollisionRules. For example, setting:
Code: Select all
Entity.CollisionInformation.CollisionRules.Personal = CollisionRule.NoSolver;
would result in the entity's EntityCollidable collecting contacts with other objects, but no collision response would be solved for.
CollisionRules are also available for non-entities, like the StaticMesh.
More information about collision rules can be found
here. Some examples can be found in some of the BEPUphysicsDemos (CollisionFilteringDemo, EntityConstructionDemo, TankDemo, RagdollDemo, and a few others).
Technically, it's also possible to create your own BroadPhaseEntry type and then do just about anything, but that tends to be more work.
Also, and a going a bit off-topic, may I ask why you developed this Engine?
I could cleverly rationalize my former self's actions by saying:
1) If we're going full managed for later projects, it would be tedious to deal with the interop layers to an existing native solution.
2) A custom solution gives us more freedom in modification for both features and performance.
3) A from-scratch implementation offers lots of educational potential.
4) The potential revenue from productizing it could be useful for launching the later planned projects.
Other than #4, all of these were at least partially true, but they don't really feel like
the reason I spent so much time making a physics engine. The real reason probably sounds more like "I played with legos and jenga blocks a lot", plus an obsession with simulation of various kinds.
How many people do you have in your team?
Bepu Entertainment is a
duo, but I'm the sole developer of BEPUphysics specifically. Squashwell works on other stuff.