Sensor-Sensor Collisions

[sherief]

Currently, Body::sFindCollidingPairsCanCollide() rejects sensor-sensor collisions - however, I think there's utility in having them enabled. Jostle enables them by default and expects the API clients to filter them out if needed, and a lot of things like point-of-interest detection or near-miss detection are very straightforward with sensor on sensor collisions.

Is there a performance / design reason for disabling them in Jolt, or was it just a preference / choice? Would you consider enabling them? As we move closer to release I'm trying to get Jostle to be as close as possible to Jolt before releasing it publicly.

[jankrassnigg]

Can you give a concrete example how you would use this? Why do you need both objects to be sensors?

[jrouwe]

I don't see the use case either. I think in most cases people will be using lots of sensors in their level to trigger against keyframed / dynamic objects. Typically many of these sensors will overlap and, right now, collisions will be discarded at a very high level. If we allow processing them further then I think most people will not realize that they should be filtering this out at a lower level. This means that there will be lots of needless processing in the collision detection pipeline to generate contacts for things that don't need contacts.

If you need collisions between sensors and other 'ghost' objects, I would suggest placing the ghost objects in a separate collision layer that only collides with the sensors and nothing else.

[AnuraDev]

sensor vs sensor would allow for example conditionally piercing projectiles which in some cases could interact with each other. and ofc also interact with regular rigid bodies. all physic engines lack support for gameplay features but i understand what it all depends on the project. it would be great if jolt would lean more towards "real gameplay" rather than just stacking boxes and ragdolls. (i am not talking about something particular but in general)

also how do you "kill on hit" properly? is guess all callbacks are fired after update? so if for example you do a linear cast of a sensor and it finds 3 objects you will get 3+ overlap/collision events, in the order they occurred?

my general question is how you properly implement logic for game where you have like 500 (at a time) flying projectiles of different size and speed and gravity, and they can conditionally pierce targets (and maybe also each other also conditional) but do some gameplay effects on collision, not ignoring it. (btw does jolt have overlap tracking or it's on game logic? so for the same object you get an overlap begin/end event)

[jrouwe]

This is quite an old thread and doesn't really reflect how Jolt works at this moment anymore. Sensor vs sensor collisions are supported since 2d607c4 and you can either mark a body as a sensor in BodyCreationSettings.mIsSensor or you can override a body to be a sensor based on your own logic (which could be 'do I penetrate this other bodies shield?') by implementing a ContactListener and overriding ContactSettings.mIsSensor in the OnContactAdded/Persisted callbacks. These callbacks also allow you to spawn effects based on object interactions. If you want to discuss this further, please create a new discussion.

[AnuraDev]

no, i get it, no more questions for now, thx!