I was wondering / hoping for any way to ignore collisions on a case by case basis.
What i want is the collision information, but the ability to tell box2d not to process the collision response (i would like to do this myself).
I want to implement soft bodies and i think this would make it the easiest/work the best.
Even if there is some convoluted way to make this happen, i’m all ears! reflection or whatever it takes!
Is something like this planned for a future release?
Thanks!
It’s not possible to collide with something without a collision. It never has been in any physics engine because colliding is what gives the collision response. Do you mean triggers? Triggers would give some data, and you can get more data by raycasting against triggers.
From chipmunk physics documentation:
After checking if two shapes overlap Chipmunk will look to see if you have defined a collision handler for the collision types of the shapes. This gives you a large amount of flexibility to process collisions events, but also gives you a very flexible way to filter out collisions. The return value of the begin and preSolve callback determines whether or not the colliding pair of shapes is discarded or not. Returning true will keep the pair, false will discard it. If you don’t define a handler for the given collision_types, Chipmunk will call the space’s default handler, which by default is defined to simply accept all collisions.
So it is something that is implemented in at least one engine. While i could use triggers, i would not benefit from the Collision2D.contacts array that is not included in trigger information. I would benefit greatly (speed-wise) from letting unity do the fine collision detection. I want all the collision information, and want to be able to handle the response myself.
To replicate this in Unity is slightly more wasteful as the overlap check would happen twice. Unity can expose this but AFAIK it is not exposed, so you will need to use triggers.
However a workaround is to take the current velocity each frame and position, and when the collision does occur, you can set the position + velocity to those stored variables and then filter out the collision, or use triggers. I would recommend this approach but be careful of multiple objects colliding at the same time as tunnelling could occur (chipmunk would be vulnerable to this as well on corrections).
But, no engine I know of actually collides then lets you do something else, it’s always the same under the hood or bad terminology. Collision means the collision has happened and the object has hit it, and therefore stopped or whatever, not that an overlap check is allowing for you to respond to a potential collision response before continuing.
It’d be nice if Unity exposed an OnPreCollision function which is called whenever something is about to calculate the actual responses from a collision - it is possible so here’s my vote for that.
From farseer physics docs:
OnCollision
The OnCollision delegate gives you the information about a collision when it is happening. It is a lot more accurate than the OnBroadphaseCollision delegate, but at the cost of performance. You also have the ability to cancel a collision by returning false in the method you subscribe
So what I’m asking for is not so foreign. It should not result in extra collision checks, they could call oncollisionenter2d just before resolving the collision (adding collision impulses) and If a user decides to ignore the collision (for what ever reason) no impulses are applied and the body is treated as never having colkided in the first place. This could be useful in many cases but happens to fit my needs perfectly.
Edit: or even an OnPreCollision event that allowed you to selectively filter collision response would be fine.
I would also like to selectively ignore collisions – or even propogate them to other objects. I wish OnTriggerEnter would pass enough information for me to recreate the collision. That would be enough.
You could just use two colliders, on that is a little larger than the other. The first one detects decides if it needs to ignore that object. Might be tricky at faster speeds.
That would not give you the contact information. Which is what I need.
Actually this is a very standard feature of most physics systems, and is called a PreSolve event - during which the opportunity is given to disable contacts between two colliders prior to collision resolution.
It can be useful for myriad purposes, and is sadly missing from Unity so far as I can see (although admittedly I am very new to Unity, but not indeed to game programming).
We need to be able to selectively ignore contacts on a case-by-case basis inside OnCollisionEnter()/OnCollisionEnter2D() - and preferably also tweak contact normals to implement some gameplay mechanics. Its a really standard technique.
If anyone from the dev side of things is listening, what’s the chance of getting this exposed?
Our names are too similar, they’ll think I made a second account 
4.5 beta notes say that they updated to box2d 2.3.1
And from the box2d manual:
Pre-Solve Event
This is called after collision detection, but before collision resolution. This gives you a chance to disable the contact based on the current configuration. For example, you can implement a one-sided platform using this callback and calling b2Contact::SetEnabled(false). The contact will be re-enabled each time through collision processing, so you will need to disable the contact every time-step. The pre-solve event may be fired multiple times per time step per contact due to continuous collision detection.
So here’s crossing my fingers!
The 4.5 beta notes I’ve seen revealed that the 2D physics have been updated to Box2D v2.3.0.
But maybe that has already changed again. After all, v2.3.1 has been officially released just a few days ago.
Nonetheless, the change list for Unity 4.5 looks pretty sweet. Can’t wait!
I’m doing a lot of “selective colliding” via layers. You can select which layers collide with which other layers in EDIT->ProjectSettings->Physics2D. This does mean you’d have to know whether you want the collision to occur, before it occurs.
Ahh, I got it messed up. It’s 2.3.0
This solves nothing… When you want to disable collisions based on things like:
We need the very standard pre solver… present in all physics engines since the 90’s
Indeed
It’s now been more than year since last post here. Has this been resolved yet? I need this feature too!
TLDR: Detection and resolution are separate steps. Some engines let us execute code between those two phases. To my knowledge Unity does not.
Old post but I have to say there is some bad info here.
Lets look at the stages of the Physics response.
You have a Detection phase, then a Response phase.
It is not crazy to let programmers insert code and processing between the Detection and Response phase.
To my knowledge Unity does not support this.
Havok does.
To my knowledge, in Unity, this is the path:
CollisionDetection → __CollisionResolutionStep__ → OnCollision*
What would be great is a:
CollisionDetection → ChanceToModifyCollisionData → CollisionResolutionStep → OnCollision*
In summation, detection and resolution are separate steps. Some engines let us execute code between those two phases. To my knowledge Unity does not.