Detecting Collisions

Chipmunk2D Bindings for the Unity3D engine
User avatar
Roland
Posts: 16
Joined: Thu Aug 08, 2013 3:32 pm
Contact:

Detecting Collisions

Post by Roland »

'Allo 'Allo,
Never used Chipmunk2D and am still getting used to how things work. Got something of a basic question regarding collision detection.

I see that in order to respond to collisions you have to implement specific methods for each collision pair on a script deriving from ChipmunkCollisionManager using the shapes' 'CollisionType' for the method name like:

Code: Select all

private bool ChipmunkBegin_footprint_ground(ChipmunkArbiter arbiter)
{ ... }
So, questions:
  • Is there any way to "wildcard" collision types to say "Respond to all collisions between _footprint and whatever?"
  • Is there any way to respond to collisions between shapes that have no type?
  • Is there any way for a shape to be tagged as having more than one collision type?
Guess that does it for now. Many thanks.
ShawnMcCool
Posts: 6
Joined: Sun Aug 11, 2013 2:06 pm
Contact:

Re: Detecting Collisions

Post by ShawnMcCool »

I have basically the same question. I'd also like to know if you can assign many collision types to a shape.
User avatar
Roland
Posts: 16
Joined: Thu Aug 08, 2013 3:32 pm
Contact:

Re: Detecting Collisions

Post by Roland »

Mr. McCool and I must has answers.
ShawnMcCool
Posts: 6
Joined: Sun Aug 11, 2013 2:06 pm
Contact:

Re: Detecting Collisions

Post by ShawnMcCool »

I'd be happy just to have access to some sort of basic documentation about how collision detection works. I learned what I can from the example, I think. I understand how to create a custom resolver between two types. But, there's more generic concepts that I'm lacking.
Steve Oldmeadow
Posts: 17
Joined: Tue Jul 16, 2013 10:27 pm
Contact:

Re: Detecting Collisions

Post by Steve Oldmeadow »

I found the Chipmunk2D manual very useful for understanding how collisions work. Chipmunk's layers are available in Unity but they are not exposed in the editor UI so you need to write some code to specify a shape's layer mask.

Something that just clicked with me is that shapes are monobehaviors therefore you have access to the game object plus all the other components attached to the game object. So you have Chipmunk collision types, collision layers and collision groups plus Unity's layers, tags and game object name at your disposal within a collision handler. If that isn't enough you can always attach another component to your game object and access it from the collision handler. That is a lot of power and certainly more than you get with PhysX.

Maybe it is better to explain what you are trying to do rather than asking for specific functionality such as specifying multiple collision types for a shape.
User avatar
Roland
Posts: 16
Joined: Thu Aug 08, 2013 3:32 pm
Contact:

Re: Detecting Collisions

Post by Roland »

Well, say you have defined an area on a level through a Chipmunk shape where there's a specific amount of force being applied to any body that enters it; like to simulate wind or something. So I figure you'd have a sensor shape with a collision manager defining a begin or presolve method for types labelled "wind" and... what? "object"? What if you have an object that you also need to be handling collision for on a different pair like between "projectile" and "player" at the same time you want the "wind" to have effect on them? Now you have to define collision handlers for every possible combination. Would be much easier to be able to set multiple collision types so that something can be considered "player" and "object" at the same time.

Or is there some other mechanic that I'm not aware of?
User avatar
slembcke
Site Admin
Posts: 4166
Joined: Tue Aug 14, 2007 7:13 pm
Contact:

Re: Detecting Collisions

Post by slembcke »

Hey guys. Sorry for the slow response time.
  • Wildcard collisions: It's a high priority on the feature list for the next version of Chipmunk, but it will be a while.
  • Collisions with no type: Yes, example below.
  • Multiple collision types: No as that could trigger multiple collision handlers. Hopefully wildcards will fill that void though.
So after making this example, I realized that it's awkward and will be fixing the API for it. My idea is backwards compatible though so the code here will work in the future.

So if you have a ChipmunkCollisionManager method that looks like this "ChipmunkBegin_player_monster", it's a collision between shapes tagged "player" and "monster". Shapes by default are tagged with an empty string. If you want to catch collisions between untagged shapes, you'd put an empty string between the underscores. (In other words, nothing) "ChipmunkBegin__" would catch collisions between untagged shapes, "ChipmunkBegin_player_" would catch collisions between the player and untagged shapes, and "ChipmunkBegin__monster" would catch collisions between untagged shapes and monsters. The order of the arguments is still important.

In C Chipmunk, every collision is handled by a collision handler and there is a default handler that handles collisions between shapes that don't have a more specific collision handler. I didn't think that would be particularly helpful from Unity, but maybe I should add it anyway? Would that be helpful?
Can't sleep... Chipmunks will eat me...
Check out our latest projects! -> http://howlingmoonsoftware.com/wordpress/
User avatar
slembcke
Site Admin
Posts: 4166
Joined: Tue Aug 14, 2007 7:13 pm
Contact:

Re: Detecting Collisions

Post by slembcke »

Hmm. Ok. In that use case default collision handlers might be useful.

On the other hand, that gives me an idea for something better. In the Unity version, it makes C# delegates out of your ChipmunkCollisionManager methods and passes those on to the C code. The name of the methods is only important so it can figure out what types to associate the delegates with. It's also possible for me to make an API call where you could easily associate a single delegate or method with multiple collision types. Still not as good as a wildcard, but it would make it easier to enumerate the things you want to collide.

On the TODO list! :)
Can't sleep... Chipmunks will eat me...
Check out our latest projects! -> http://howlingmoonsoftware.com/wordpress/
User avatar
Roland
Posts: 16
Joined: Thu Aug 08, 2013 3:32 pm
Contact:

Re: Detecting Collisions

Post by Roland »

slembcke wrote:
  • Wildcard collisions: It's a high priority on the feature list for the next version of Chipmunk, but it will be a while.
Sweet. 'Cept for the "be a while" bit : P
  • Collisions with no type: Yes, example below.
Super sweet. Don't know why I didn't try that.
  • Multiple collision types: No as that could trigger multiple collision handlers. Hopefully wildcards will fill that void though.
Ah - bit confused. Wouldn't the ability to trigger multiple collision handlers be something desirable? I desire it.
I just realized that the documentation states that you can only have a single collision callback for a given pair defined. Is that by design or due to a technical limitation? I'm not sure what's happening underneath the hood, but I know that in C# you can add delegates together and have them all invoked at once if that has anything to do with it. I figure an array of function pointers in C is basically the same thing.
In C Chipmunk, every collision is handled by a collision handler and there is a default handler that handles collisions between shapes that don't have a more specific collision handler. I didn't think that would be particularly helpful from Unity, but maybe I should add it anyway? Would that be helpful?
Like to be be able to define something like ChipmunkBegin_Default(...) and have it receive all collisions for all objects that have no more specific type defined? Yeah, I think that'd be real helpful. I'd probably use that for everything and do more specific filtering from there, unless that'd kill performance.

On a somewhat related note - I have a collision manager to implement my wind example thang with the following methods defined:
ChipmunkPreSolve_wind_player(...)
ChipmunkPreSolve_wind_ball(...)
Doing a Debug.Log shows when the ball is in the area for the wind, being defined as a box shape sensor, but it'll only do so for the first 18 frames or so and then stop receiving collision events altogether. The _wind_player method keeps working though. Off the top of your head: any reason this might be happening? I get the impression that the _wind_ball method is getting unregistered or something.

Thank you sir, and good luck with that TODO list - I shudder to think of the length of it.
User avatar
slembcke
Site Admin
Posts: 4166
Joined: Tue Aug 14, 2007 7:13 pm
Contact:

Re: Detecting Collisions

Post by slembcke »

Triggering multiple handlers is bad because that can do more than respond to the events. The return value of the begin and preSolve callbacks allow you to filter collisions, and the preSolve in particular exists to allow you to change a collision's outcome. If there are multiple callbacks what if their return values don't agree, what rule is used to handle that? What order should it run them in if they both make changes to the arbiter parameters? This is something that will need to be addressed with wildcards as well, but in that case there are only two to deal with.

The performance of a default collision handler may be somewhat poor. I don't have hard number though. Calling across the C -> C# language barrier is relatively expensive and its possible to have a lot of callbacks that you'd need to handle for a given frame. That's part of the reason why it's designed like it is.

As for the collision methods stopping, is the object falling asleep? Pre/PostStep methods are not called for sleeping objects since the collisions themselves are not active.
Can't sleep... Chipmunks will eat me...
Check out our latest projects! -> http://howlingmoonsoftware.com/wordpress/
Post Reply

Who is online

Users browsing this forum: No registered users and 7 guests