sticking corners

[gnasen]

Hi,
Ive got a very annoying problem in my game (platformer). If I put a lot of boxes in a row so it should behave like a "normal" Segment Shape (see red dots):

However my circle shaped entities stick sometimes on the corners (primary after jumping). I think its because of the slop of collisions.
After some research I found this code by Slembke:

Code: Select all

preSolve(...){
    Return !(
      arbiterCount(arb) == 2 &&
      arbiterDepth(arb, 0) < slop && arbiterDepth(arb, 1) < slop &&
      cpvdistsq(arbiterPoint(arb, 0), arbiterPoint(arb, 1)) < slop*slop*2.0f
    );
  }

and translated it into my programing language (purebasic). The code does not work pretty well, because I really never get 2 collision points at the same time (arbiterCount(arb) == 2). Its everytime just 1.
So there could be several reasons: The code from above is pretty old. Does it work anymore? Is there a wrapper issue with arbiterCount(arb), or is it really everytime 1?
Or do you have an other idea for a fix for it?
I have one, but it would be needed to be preprocessed everytime (connect gaps by segment shapes).
Greetings Dario

[slembcke]

The issues is caused because Chipmunk allows objects to overlap slightly. The collision slop sets the amount of overlap that Chipmunk never attempts to fix so they stay colliding. Fast moving objects (like after jumping) often overlap more than that. This is what causes the sticking corners because collisions with each shape are considered individually. You end up colliding with the top of one shape and the corner of another even though they should be perfectly flush.

This is a problem with a lot of other physics engines as well including Box2D, PhysX and Bullet (that I know of). They all treat collisions in a similar way. The best way to work around it that I know of is to join the shapes together to get rid of the seams entirely. An easy way to do that is to join horizontal strips of boxes together. This doesn't fix making vertical walls smooth though. Chipmunk Pro offers some autogeometry features that would make this pretty simple, though it's not free and you'd probably have to write your own wrapper to purebasic for it. Not really an ideal solution for you.

That preSolve() callback was meant for box-box collisions. Circle-anything collisions only ever generate a single collision point. For the Your Story platformer that I collaborated on, we tried a couple new callback based filters that I was never terribly happy with.

[gnasen]

i had the same idea, to join the shapes together. However I see a little problem here:
If I join all boxes together (for example in the picture), I only use one shape for all of them. But now I cant decide, which box was hit by a collision, if I jump against it (to get some coins etc).
My approach would be to use 2 Layers: One layer for all the walking stuff etc (simple geometry) which does all "solid" collisions and one layer for the callbacks, which does always return false on any collision. The second one could tell me which box was hit.
It shouldn't be difficult to manage this, but its not pretty good for performance. At least I only have to do this for the static objects only.

[slembcke]

Or you could just use sensor shapes. They never are slightly less expensive than regular collision shapes. You only would need to make sensors for the special bricks like the coin bricks and such.

Another idea is if everything is based on tiles, you just need to grab the collision points from the main callback and look up which tile they are in in the tilemap.

[gnasen]

Unfortunately its not tilebased (you may guess it, if you watch the hill in the background of the picture). However I tried a bit around with a combination of our ideas. The sensor shapes are exactly what I need (it could be highlighted a bit more in the manual, that they even exist ) and in combination with adding an extra shape for the real collisions it works very well. I will write a little algo which will replace constructs like this boxes with one great box shape. I tried out, that it works really good, if you make the seamless box a little little bit smaller so the sensors can always trigger.
Thanks a lot for your help. Btw your engine is really nice: lightweight, fast and most stuff easy to use (I think that I use the rouge/static bodies wrong till today). Keep up that good work!

[slembcke]

Ah, yeah I see how just the boxes are tile-ish now. I didn't look close enough at that before. Good to know you got it working though.

[gnasen]

Good day,
I wrote the algorithm now and it seems to work pretty well. I will post the results if I'm finally done.
However there is a small problem I ran into:

As you can see, both shapes are touching each other (top and bottom picture). Now I try to do a shapeQuery, but it only detects the collision in the upper case. In the lower case it doesnt.
I know this is a tricky case (cause they are not really overlapping but at least touching), but is this how it is supposed to be?

[slembcke]

All of the collision detection functions were written with overlapping shapes in mind. They probably detect some shapes that are just barely touching, but I would assume it's undefined generally.

[gnasen]

Finally it seems that its working very well now. Here is what I achieved. It works with concave (1. in picture) and overlapping (3. in picture) stuff: