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.
Collision events - explanation needed
Re: Collision events - explanation needed
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.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.
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.
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.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?
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:
Code: Select all
while (pair.Parent != null)
pair = (CollidablePairHandler)pair.Parent;
(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.)
-
- Posts: 49
- Joined: Mon Oct 08, 2012 4:57 pm
Re: Collision events - explanation needed
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?
Any timeframe for events rewrite?
Re: Collision events - explanation needed
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.Is there any way to know if contact comes from aabs overlap or narrowphase?
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.)
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.Any timeframe for events rewrite?
-
- Posts: 49
- Joined: Mon Oct 08, 2012 4:57 pm
Re: Collision events - explanation needed
Oh, that's OK, I'm not rushing to rewrite my own code based on events eitherI can't offer a time with any reasonable accuracy (...)
Thanks,
S.
-
- Posts: 49
- Joined: Mon Oct 08, 2012 4:57 pm
Re: Collision events - explanation needed
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.
- 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.
Re: Collision events - explanation needed
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.
Only the "sender" and "other" parameters of the event are based on which object has the event hooked.