CollisionRules.Personal vs CollisionRules.Specific

[Syntax]

I'm not getting very consistent results with the CollisionRules hierarchy. This is my setup:

I have a static mesh that represents a zone on my field. I need to detect when a character passes inside the zone and when he leaves. I have two events setup for the static mesh: DetectingInitialCollision and CollisionEnding. When these events are called I confirm it was a character that passed in the zone and not another physics entity and then change a bool to whether the character is in or out of the mesh. I have also changed the static mesh's CollisionRules.Personal to NoSolver so that the character will pass through the mesh smoothly and still raise the events.

The problem is that on the xbox I get performance issues when every object (there are quite a few) in the environment start colliding with the zones. I have tried give the static mesh a personal rule of NoBroadPhase and specific rule for the characters of NoSolver, but then no collision is detected and my events arn't called. However, if I give the static mesh a personal rule of NoSolver and a specific rule for characters of NoBroadPhase, the characters will not collide with the mesh but everything else in the environment will. According to this page: http://bepuphysics.codeplex.com/wikipag ... on%20Rules specific rules should always override personal rules, but this doesn't seem to be the case 100% of the time.

Am I making a mistake? If you know of a more efficient way to do this manor of zone detection, I would love to be corrected on that as well. Thanks!

[Norbo]

Unless the collision rule calculator has been overridden with a custom handler, specific rules will indeed get used over personal rules and group rules. There is some complexity there relating to compound bodies though.

It sounds like something else is interfering with the rules. Attempting to reproduce the problem in an isolated BEPUphysicsDemos demo would likely help isolate the problem and, if necessary, would make it easy for me to debug.

If you know of a more efficient way to do this manor of zone detection, I would love to be corrected on that as well. Thanks!

It depends on what kind of detection is required. Right now, it sounds like the body of the character generates contacts with the mesh of the wall. Once the character is inside, there's no further testing. In effect, this is a 'character walked near or through a door' detector as opposed to a volume detector.

If basing the zone on the position of the character alone is sufficient, there are some faster options available. Instead of testing full collision geometry, the position alone could be tested for containment within a volume. That volume could be represented by something simple like bounding boxes and bounding spheres or, if necessary, a mesh. There are a variety of ways to implement this; I used a custom collidable to do quick gravitational zone detection in another project, but this requires getting your hands dirty with custom pair handlers and such.

Another option would be tagging the environment mesh which is a part of a zone. If the player is colliding with it, they're in that zone. If they're colliding with two different zone meshes, use the previous zone. If the environment permits it, you might not even need to examine contacts to use this; the bounding boxes could be sufficient.

There's also other approaches, but it all depends on what kind of behavior you need.

[Syntax]

Thanks for the reply. I tried making a brand new sphere and giving it a specific rule with the zone and it worked. However, I checked the character's collision rules before and after I set it's specific rule as well as in the middle of gameplay and I haven't seen anything abnormal that would cause the rule to get overridden. You said it can get complicated with compound bodies. My character happens to be a compound body. I suppose "vehicle" or "robot" would have been a better term than "character." I need to detect when any part of the compound body is inside of this irregularly shaped safe zone. Any ideas of what I should be looking for?

[Norbo]

Compound children have their own collision rules. In the pair hierarchy, the higher pairs' rules act as clamps on any lower level pairs. So, if the top level body defines a rule of NoSolver, that clamps all child pairs to a maximum interaction level of NoSolver regardless of any other child rules. (That clamping is required for consistency since the children might expect to have pairs despite a rule of NoBroadPhase on the parent pair which can't exist.)

So, in this situation, the child collision rules are capped at NoSolver by the parent specific rule- which is fine- but their own collision rule with the other object is restricted to NoBroadPhase because of the exposed Personal rule.

So here's a couple of options:
-Assign a specific rule with the individual children of the charactervehiclerobot.
-Create a collision group for characters and a group for the zones. Give the first group to the charactervehiclerobot compound. Give the second group to the zones. Set a rule between the characters and zones groups of NoSolver. For the other groups, set a rule of NoBroadPhase with the zone group.

[Norbo]

I need to detect when any part of the compound body is inside of this irregularly shaped safe zone.

If it needs to have full shape collision testing, then the position-only approach is out. If the zone needs to be a solid volume, a more robust approach may be to use either a DetectorVolume or a solid mobile mesh. The collision rule stuff above still applies to these methods.

[Syntax]

I finally got it working by doing all of the rules on the group level like you said. It does work but again performance issues are preventing me from using it as is. So I thought I would give the DetectorVolume from the demos a go. However, when I call DetectorVolume.IsEntityIntersectingVolume(), it crashes in NarrowPhaseHelper on line 393 because pairHandler is null. I was able to recreate the issue in the demos by replacing:

Entity box = new Box(new Vector3(0, -10, 0), 1, 1, 1);

with:

var bodies = new List<CompoundShapeEntry>()
{
new CompoundShapeEntry(new SphereShape(.5f), new Vector3(0, 1, 0), 1),
new CompoundShapeEntry(new ConeShape(2, .5f), new Vector3(1, 1, 0), 1),
new CompoundShapeEntry(new SphereShape(.5f), new Vector3(-1, 1, 0), 1)
};
var box = new CompoundBody(bodies, 45);

on line 39 (or so) in the DetectorVolumeDemo.cs

[Norbo]

Oops! There are indeed bugs with the DetectorVolume and compounds. However, I am in the process of rewriting it. It shouldn't take too long, but you may want to use a solid mobile mesh as a substitute. The mobile mesh version will do more work than necessary for a detector volume, but it can do what the DetectorVolume did.

I should note however that the (current version of the) DetectorVolume probably won't be faster than the static mesh approach, and the mobile mesh with solidity will likely be a little slower. It may be worth it to investigate exactly where the computational cost is at. Are there tons of zones polluting the broad phase? Are all the unnecessary pairs being filtered correctly?

[Norbo]

The development version now contains a rewritten DetectorVolume which should fix the problem with compounds/mobile meshes while increasing speed quite a large amount.

[Syntax]

Thank you very much for the update! I will let you know how that implementation goes. By the way, did anything change for the way objects compute collision bounces and friction since Version 1? I had spheres with a material bounciness of 0 and a floor with a material bounciness of .6 which created very stable sphere to sphere collisions but still allowed the balls to bounce on the floor. Now that I have applied the new update, my spheres have no bounce at all.Is there any way to tell BEPU to use the old method for calculating the final bounciness? Thanks again!

[Norbo]

The default blending approach was indeed changed to multiplicative as opposed to the former average.

The MaterialManager.MaterialBlender can be set to perform whatever calculation is desired. For example:

Code: Select all

                    MaterialManager.MaterialBlender =
                        delegate(Material a, Material b, out InteractionProperties properties)
                            {
                                properties = new InteractionProperties
                                {
                                    Bounciness = (a.Bounciness + b.Bounciness) * .5f,
                                    KineticFriction = (a.KineticFriction + b.KineticFriction) *.5f,
                                    StaticFriction = (a.StaticFriction + b.StaticFriction) * .5f
                                };
                            };

[Norbo]

Also, special behaviors can be defined between specific materials using the MaterialManager.MaterialInteractions dictionary.