BEPUphysics

Hi Norbo, I'd like to ask what's happening here.

I have two entities - "turret" with several other entities attached to it with weldjoin; and "hull" which is a compound, made of several shapes: "back", "front", "crew", "engine".

I'm firing a sphere ("projectile") at those and attach ContactsCreated event to it - in events body there's couple of logging methods fire up to record what's happening. I have such a scheme that when sphere hits entity for the first time, it records position, time and so on, and then it is allowed to go through, firing following contactscreated events, "inside" the entity.

First scenario - projectile hits the turret.

1) contact is created between "projectile" and one of the turret attachments, "zip-1" entity. Contact has one pair - I'm looking at other.Pairs parameter, with EntityA and EntityB set to "projectile" and "zip-1" entity, as expected.
2) next, projectile sphere goes through and another event is fired. Sphere is inside turret, we have two pairs (other.Pairs): first one is OK - EntityA and EntityB set as expected - "projectile" and "turret" accordingly. BUT, second pair has only EntityA set to "turret" and EntityB is null - QUESTION nr 1 - wtf? How is that?
3) sphere continues to travel inside "turret" and creates some more events, the same manner as described above: one "good" pair, and another with only EntityA set to the "turret" entity.

Then sphere ("projectile") travels outside "turret" entity hits terrain and is disposed - that's my code and it works as expected.

Second scenario - projectile hit the hull - compound entity.

1) contact is created between "projectile" and hull - Other parametr is set to "back", children shape of the compound - as expected, but Other.Pairs count is zero. Why so?
2) projectile travels through compound firing continues events hitting other children and for none of those Other.Pairs.Count returns more than 0.

Is this how compound works, when it comes to collisions?

Thanks,
S.

2) next, projectile sphere goes through and another event is fired. Sphere is inside turret, we have two pairs (other.Pairs): first one is OK - EntityA and EntityB set as expected - "projectile" and "turret" accordingly. BUT, second pair has only EntityA set to "turret" and EntityB is null - QUESTION nr 1 - wtf? How is that?
3) sphere continues to travel inside "turret" and creates some more events, the same manner as described above: one "good" pair, and another with only EntityA set to the "turret" entity.

A CollidablePair between an Entity and a static collidable like a Terrain will show one of the entity connections as null. That's because static collidables like the Terrain have no Entity associated with them.

If you'd like to check which collidables are associated with the pair, use the CollidableA/B properties.

Note that pairs can exist between objects which have no contacts. They are created whenever objects are near enough to each other to potentially generate contacts. That heuristic is implemented as an AABB overlap check. The terrain's AABB is large enough to intersect the turret's AABB.

1) contact is created between "projectile" and hull - Other parametr is set to "back", children shape of the compound - as expected, but Other.Pairs count is zero. Why so?
2) projectile travels through compound firing continues events hitting other children and for none of those Other.Pairs.Count returns more than 0.
Is this how compound works, when it comes to collisions?

Yes, that's just how compounds work (currently). Child collidables do not have their pair lists updated, and an object with an event hooked to it colliding against a compound will report child collidables.

The top level compound still maintains a list of pairs. If you can get a reference to it, you can check the full pairs list. One option would be to walk up the pair hierarchy: By the end of that loop, you'll have a pair that includes the top level compound.

(Digression: I dislike the current implementation of events. Especially deferred ones. Especially the way the CompoundCollidable handles things. There's a decent chance that they will get ripped apart in the future. I haven't yet decided on the form of the successor, but it's probably going to be much simpler.)

OK, clear, thanks.

Is there any way to know if contact comes from aabs overlap or narrowphase?

Any timeframe for events rewrite?

Is there any way to know if contact comes from aabs overlap or narrowphase?

Overlapping AABBs alone do not result in contacts. Only the narrow phase test which actually checks if the objects are touching can generate contacts. If a ContactCreated event is dispatched, it is because the narrow phase generated a contact for that particular pair.

If you'd like to know if a particular CollidablePairHandler represents an 'actual' collision instead of a 'potential' collision, check the pair's Colliding property. It returns true if the pair has any contact with nonnegative penetration depth. (Speculative contacts can have negative depth, representing a separation distance.)

Any timeframe for events rewrite?

I can't offer a time with any reasonable accuracy- there's a bunch of other stuff that has higher priority. I'm more concerned with improving the performance of some particularly large simulations needed by one of our projects. Then again, there's always a chance that I'll end up working with the event system, getting annoyed by it, and ripping it apart early. That's approximately why the new BufferPools and 'Quick' collections exist now.

I can't offer a time with any reasonable accuracy (...)

Oh, that's OK, I'm not rushing to rewrite my own code based on events either

Thanks,
S.

One more thing, a noticed following pattern - in example above projectile hits various entities, and:

- when collision is between projectile and non-compound entity, pair.EntityA is set to projectile entity - as you expected - the first one is the one which collisions we're handling
- BUT when collision is between projectile and compound entity, pair.EntityA is set to compound - that's confusing, as you would expect here projectile entity

Is there any reason for this?

Thanks,
s.

Events do not affect the order in pairs; CollidablePairHandlers exist independently of events. Further, CollidablePairHandlers have no guaranteed order on the involved collidables/entities.

Only the "sender" and "other" parameters of the event are based on which object has the event hooked.