Bodies With Sensor Madness

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

Bodies With Sensor Madness

Post by Roland »

Seeing some unexpected behavior in the following setup (sorry for the enormous image):
Image
The white shapes are objects with a ChipmunkBody and ChipmunkShape with sensor flag set. The reddish shapes are just shapes (sensor flag not set).

The colored crosses are the contact points received from the ChipmunkArbiter sent during the PreSolve callback, with the hard-to-see black lines being the contact normals.

It seems there's something horribly wrong with most collisions except maybe those involving a circle (ironic, considering the last issue I had found seemed to involve only circles). This a known issue or am I not getting something? Let me know if you'd like the sample project.

Thankee
User avatar
slembcke
Site Admin
Posts: 4166
Joined: Tue Aug 14, 2007 7:13 pm
Contact:

Re: Bodies With Sensor Madness

Post by slembcke »

So all of those return contact points that are roughly what I would expect. While it's hard to tell for some deeply overlapping objects, the black line always seems to like on the minimum separation axis (MSA). Polys and segment contact points are done by clipping edges along the MSA, circles against everything else are done using closest points.

The idea of a contact point breaks down the more and more objects are overlap. The contact points are slid along the normal to try and weight them fairly into each surface depending on the radius of the shape (polys can have radii too, though none do in your image). Contact points between shapes with a radius of 0 and a non-zero radius are sort of a weird case.

One of the features I've already implemented for the next version of Chipmunk is to remove the idea that contact points have a discrete position at all. Instead they will be a set of points on the surface of each shape that are considered to be in contact. This let me simplify quite a lot of code and throw away the laboriously constructed heuristics that ensured the contact points stayed the same when flipping the collision order or transitioning between which colliding edges were used to generate them. I suppose that is getting a little off topic...

Anyway, circling back around to the beginning. What do you expect the collision points for deeply penetrating shapes to look like and what are you trying to use them for? There might be a better way to get what you want.
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: Bodies With Sensor Madness

Post by Roland »

Huh - well that makes some kind of sense... maybe. I guess. : P

I was expecting that all contact points (whether deeply penetrating or not) would always be included within both shapes that were colliding; whether inside their overlapping volumes or somewhere along their surfaces or some combination of the two. I was shocked (shocked, I say) to see a contact point that was only contained by one shape and sometimes by neither (the pic shows a few that are just slightly away from either shapes). Kinda counter-intuitive having something called a contact point not actually be in contact with both shapes, you know?

I was trying to use a dynamically updated segment shape to do a type of circle-cast to detect whether a relatively small and fast moving body defined by a circle would've collided with another shape that the simulation wouldn't have picked up due to it's high velocity (and phasing through relatively "thin" shapes like walls and the like). I also need to know the angle at which such an object has hit the surface and thought the contact normal (or it's inverse, depending on the order of colliding shapes) would represent the normal of the surface, which along with the object's velocity, I could use to find the angle. I can mostly get what I need by doing a "segment" query, except it doesn't account for the size of the circle and in some instances would still result in the object phasing through another.

It sounds like your new implementation returning points along the surface of the shape would somehow be enough to extrapolate what I need. Do we have a release date scheduled for the update?
User avatar
slembcke
Site Admin
Posts: 4166
Joined: Tue Aug 14, 2007 7:13 pm
Contact:

Re: Bodies With Sensor Madness

Post by slembcke »

Well, for each shape it picks the surface that bust matches the collision normal. Then it clips those agains each other and finds a point in-between the two of them. For long thin shapes that in-between point might not lie on either collision surface, but it makes a better and more stable contact point than favoring either shape over the other. This is especially true if the collision order changes.

The revised contact points is one of the things I'm working on for the next major version of Chipmunk, so it's quite a ways away. The contact normals also don't really do what you want them to. They won't give you the angle the segment hits the other shape at, it will give you the minimum separating axis. The direction you can move either shape in the smallest amount to cause them to not overlap. It's also not going to give you a good way to estimate where the segment will hit the shape, something else you probably want.

Though now that you mention it, since all of the collider shapes now can take a radius parameter. (Something that happened recently) I could actually implement a proper swept circle query. I'll put it on the TODO list, but it won't make the next release for sure. We are already about ready to push that out.
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: Bodies With Sensor Madness

Post by Roland »

Hm - so I take it that there's nothing guaranteeing that the MSA is normal to either surface in the collision? Is there any way you can think of to reliably compute the normal of the surface that a shape most likely hit?
What does the friction model use to get the surface normal?

Questions, questions...
User avatar
slembcke
Site Admin
Posts: 4166
Joined: Tue Aug 14, 2007 7:13 pm
Contact:

Re: Bodies With Sensor Madness

Post by slembcke »

Well, in the MSA will always be a surface normal. Flat polygon shapes have a finite number of surface axes. Anything with a rounding radius has a curved shape and now you have the the possibility of any normal being a surface normal.

The problem is that the MSA of a segment and another shape rarely going to be the normal you want unless the segment barely overlaps the other shape. The contact point isn't going to tell you where the segment intersected with the other shape either since contact points are about pushing corners of objects apart, and not finding intersection points. The collision detection simply doesn't calculate what you need. Sorry. :-\
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: Bodies With Sensor Madness

Post by Roland »

So I take it your friction calculations are getting the surface normal through some other method not involving the collision detection system?

If I understand what you meant by the clipping of matching surfaces: Will a line that contains the contact point and lies along the contact normal be guaranteed to intersect both shapes if it were long enough? Would the minimum length of such a line be derivable from the value returned from the ChipmunkArbiter.GetDepth method, or what is the actual significance of that method's return?

Thanks and sorry for the bother!
User avatar
slembcke
Site Admin
Posts: 4166
Joined: Tue Aug 14, 2007 7:13 pm
Contact:

Re: Bodies With Sensor Madness

Post by slembcke »

No, the friction uses the normal returned by the contact points.

"Will a line that contains the contact point and lies along the contact normal be guaranteed to intersect both shapes if it were long enough" Yes, and it should be the same length as the contact depth. In fact removing the stored depth another change I'm making in the contact-point-less code. It's cheaper to just defer the calculation than to use up memory bandwidth to cache it.

That's still not helpful to your goal though. You still won't be able to calculate the ray's impact normal or ray length from the MSA. They are completely unrelated.
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 5 guests