Probably my error, but collisions are outside shapes.

[j8stereo]

This is probably my error, but I can't find the mistake. Here's hoping someone else has encountered this.

So, collision points are retrieved from the arbiter during begin or preSolve. These points are stored within the game objects so that they can be rendered. My code isn't with me now, but it's something like:

Code: Select all

for(i = 0; i < cpArbiterGetCount(arb); i++) {
    aPhysicsable->storeCollisionPoint(cpBodyWorld2Local(aBody, cpArbiterGetPoint(arb, i)));
    bPhysicsable->storeCollisionPoint(cpBodyWorld2Local(bBody, cpArbiterGetPoint(arb, i)));
}

These points are then rendered as little x's relative to their objects centre. Often times they are quite correct, lying very close to a shape's boundary. Other times, often when flat faces collide directly, collision points are wildly outside the shape. I have a test case where collision points are in error by more than twice the length of the shape.

So obviously I'm doing something horribly wrong, but I can't figure it out. There's no way that chipmunk has errors this big. My code is unavailable right now but can be posted tomorrow if necessary.

[slembcke]

Well, there's nothing wrong with the code you posted. My best guess is that you are just rendering them at the wrong location? Body local coordinates are relative to the position and rotation of the body. Did you just do position maybe? You'd definitely notice if the collision points were wrong though. Thinks would tend to wobble and explode.

[j8stereo]

Checked all the rendering and collision callback code and have a clearer picture of what is happening.

A ring of objects is made. Each object is a sort of equilateral Y. As these aren't convex polygons, 3 cpShapes are needed per cpBody. Ten of these objects are arranged in a ring and set inwards towards each other such that two prongs of each Y collide simultaneously near the centre. For instance, the bottom Y of the ring would be upright and sent upwards, while the top Y of the ring would be inverted and sent downwards. From this, shouldn't we expect the first cpArbiters encountered to only generate one collision point each?

When the initial contact is made between all of the Ys, each cpArbiter reports 3 collision points instead. One point is always in an expected position at the meeting point of two prongs. The other two are reported near the centre of one of the colliding Ys. These incorrect collision points always line up exactly with the central kinks of some Y. It seems that one of the colliding cpShapes is picked by the cpAbiter, and all of it's vertices are reported as collisions.

This only happens when the arms of each Y are sufficiently thin enough. With thick enough arms, everything works fine. This behaviour appears when the points of the arms are about eight times further from the centre of a Y than the kinks. Additionally, this behaviour only seems to happen in the very first collisions of this setup, when two prongs collide at once, and at other rare times.

So based on this, and the fact that every other collision renders fine, it doesn't seem to be a rendering bug.

A few pictures.

Before anything has collided. Orange is the boundary of an object with one cpBody. Pink lines delineate the convex cpShapes.

2013-04-15-191142_1024x768_scrot.png (51.77 KiB) Viewed 5117 times

Red lines stretch from centre of an object to blue boxes at the collisions. After the first erroneous positions are reported, we see that the right and middle objects both have two erroneous points. These points correspond to the vertices of the colliding cpShape to the left. The collisions near the centre of the Ys should most certainly not be happening yet.

2013-04-15-191148_1024x768_scrot.png (54.28 KiB) Viewed 5117 times

A while later, another collision reports a pair of erroneous points.

2013-04-15-191233_1024x768_scrot.png (53.46 KiB) Viewed 5117 times

So... what's going on here?

[slembcke]

Oh. Hrm. I think I know what is going on here...

Does it only happen occasionally and when the tips of the triangles touch? The way I generate contact points for poly-poly collisions has some weird special cases that can cause it to output some really weird contact information particularly when very thin or very pointy polygons collide. I have some goofy workarounds so that it doesn't mess up the simulation very much.

Could you do me a favor and try out the 6.2 beta branch? That was one of the issues that was fixed.
http://howlingmoonsoftware.com/wordpress/?p=750

[j8stereo]

That did it.

Thanks

[slembcke]

Ok. Good to know all that effort wasn't for nothing then. :-\