Question about NarrowPhase.RemoveStaleOverlaps()

[ecosky]

Hi,

I was trying to figure out a reference leak of NarrowPhasePairs related to entities (a standard compound body) that have been removed from the Space, and it turns out that since both the entity being removed is inactive and the custom Collidable object's IsActive property always return false was causing the NarrowPhase.RemoveStaleOverlaps() to never remove the NarrowPhasePair that had been created between the entity and my custom Collidable. Changing my Collidable's IsActive to always return true corrected this and allowed the NarrowPhasePair to be removed as expected, but I am now wondering if there is something else I need to know about the situation. Namely, why is it that RemoveStaleOverlaps shouldn't remove pairs unless at least one item is active? Perhaps I am hitting an unexpected edge case related to the fact I am removing objects from the world? Perhaps there is some meaning to BroadPhaseEntry.IsActive other than what I expect which is that it is true if the object is moving. Should I expect a penalty for leaving the BroadPhaseEntry.IsActive true on an otherwise stationary/static object?

To put it in context a bit, these are rigid bodies that are related to NPC corpses that are stationary on the ground and need to be removed from the world. The custom Collider is my terrain.

Thanks for any feedback or suggestions,

[Norbo]

The narrow phase system decides 'staleness' based on whether or not the pair was updated. If the broad phase produces an overlap for a pair, it is updated. However, the broad phase does not produce overlaps between two inactive objects. To prevent inactive pairs from being removed from the simulation, it will only attempt to remove a pair if one of the two objects was active, meaning that the objects moved apart. (If inactive pairs were considered stale, then objects that wake up would have to regenerate their contact manifolds from scratch and would have no accumulated impulse to warm start collision solving. That would reduce stability and cause a visible jerk in complicated situations.)

Removing an inactive object from the space can confuse the system, as you've seen. This should apply to StaticMeshes and the like as well. Changing the static collidable to return active will fix the issue, but will also force it to do unnecessary narrow phase tests when objects are inactive.

Another option is to force an entity awake before removing it from the space. This relies on the object remaining active while not in the space; I don't remember any system which would interfere off the top of my head, so it should work.

A proper internal way to address this could be to test the stale pairs for for not belonging to the simulation in addition to the current inactivity testing. I'll look into this a bit more in a few days.

[ecosky]

Thanks for the info, very helpful. I can see why it might take a little time to resolve this; I tried to add a check for if the two entries were in different spaces to enable the removal and there doesn't seem to be an easy way to retrieve the Space they are in (maybe I'm just not looking at the right objects).

Out of curiosity, is there a reason why SimulationIslandMember.IsActive doesn't return true if IsAlwaysActive is true?

[Norbo]

Out of curiosity, is there a reason why SimulationIslandMember.IsActive doesn't return true if IsAlwaysActive is true?

Since activity is actually a property of the simulation island that a dynamic entity belongs to, IsAlwaysActive acts earlier in the pipeline to modify the island state.

There is a small undocumented oddity when using IsAlwaysActive with kinematic objects, though. Their activity state is defined entirely based on their current velocity since nothing else can affect them. For consistency, I'll probably change it to keep even kinematics active if IsAlwaysActive is true.

[Norbo]

The latest development version now includes changes to make kinematics with IsAlwaysActive set to true consistent and to remove stale pairs which contain removed broad phase entries.