Chipmunk Physics

Posted: **Mon Sep 02, 2013 12:53 pm**

I keep getting this warning in my simulation which is basically a bunch of segment shape bodies linked with pivot joints:

Chipmunk warning: High GJK iterations: 31
Failed condition: i < WARN_GJK_ITERATIONS
Source: (...)/chipmunk/src/cpCollision.c:305

What does it exactly mean? Should I worry? The simulation looks stable despite the warning.

Posted: **Mon Sep 02, 2013 7:48 pm**

You shouldn't necessarily worry no, but it is weird. Basically GJK works by picking better and better pairs of edges to try and find the closest points between two shapes. Unless you have a shape with hundreds of vertexes, it should be extremely rare to get more than a dozen iterations. If it hit's 30, it's probably because there is a bug where it's not actually detecting the exit condition correctly.

How often do you get the warning? Like hundreds of times a second or less than once a second?

Also, what branch are you on? I've sort of made a mess of that lately... I merged a bunch of the branches together to get ready for the release, and the "glfw" branch is currently the most up to date. Except for some documentation and release notes, it's basically ready for release. (I know, I know.. I've been saying that for months. :-\ )

Posted: **Tue Sep 03, 2013 4:01 pm**

slembcke wrote:You shouldn't necessarily worry no, but it is weird. Basically GJK works by picking better and better pairs of edges to try and find the closest points between two shapes. Unless you have a shape with hundreds of vertexes, it should be extremely rare to get more than a dozen iterations. If it hit's 30, it's probably because there is a bug where it's not actually detecting the exit condition correctly.

How often do you get the warning? Like hundreds of times a second or less than once a second?

Both:) Sometimes once in a few seconds, sometimes I'm simply awash with warnings. When all movement dies down, they stop coming.

One thing unusual in the simulation is my own body grouping with begin collision callback. The goal was to collide only non-adjacent segments, so that the structure wouldn't fold completely when not supported (think bike chain). So the segments really overlap but the callback returns false to filter out adjacent collisions. Don't know if it matters.

slembcke wrote: Also, what branch are you on? I've sort of made a mess of that lately... I merged a bunch of the branches together to get ready for the release, and the "glfw" branch is currently the most up to date. Except for some documentation and release notes, it's basically ready for release. (I know, I know.. I've been saying that for months. :-\ )

I'm on branch beta-6.2, commit 67de5d6c04138ab45bd99d6ee5ca5f01a6fea25a. I can wait till 6.2 is out, no fire.

Posted: **Tue Sep 03, 2013 7:02 pm**

Hmmmmm... :-\

Well, it's not a show stopping issue. It can affect performance a little, and it definitely sounds like a bug though.

Posted: **Wed Sep 04, 2013 9:43 am**

slembcke wrote:Hmmmmm... :-\

Well, it's not a show stopping issue. It can affect performance a little, and it definitely sounds like a bug though.

I got a clue. When I put a breakpoint when the warning is triggered I noticed one of the MinkowskiPoint's has almost a == b:

Code: Select all

(MinkowskiPoint) v1 = {
  a = {
    x = 314.017
    y = 34.8992
  }
  b = {
    x = 314.017
    y = 34.8992
  }
  ab = {
    x = 0
    y = -3.8147e-06
  }
  id = 256
}

And here's the collided segments that caused it:

Code: Select all

(lldb) print *seg1
(cpSegmentShape) $4 = {
  (cpShape) shape = {
    (const cpShapeClass *) klass = 0x0044c2f4
    (cpBody *) body = 0x093edb5c
    (cpBB) bb = {
      (cpFloat) l = 289.603
      (cpFloat) b = 11.5646
      (cpFloat) r = 417.52
      (cpFloat) t = 211.363
    }
    (cpBool) sensor = 0
    (cpFloat) e = 0.3
    (cpFloat) u = 0.8
    (cpVect) surface_v = {
      (CGFloat) x = 0
      (CGFloat) y = 0
    }
    (cpDataPointer) data = 0x00000000
    (cpCollisionType) collision_type = 4
    (cpGroup) group = 155114332
    (cpLayers) layers = 7
    (cpSpace *) space = 0x08459150
    (cpShape *) next = 0x093edc3c
    (cpShape *) prev = 0x00000000
    (cpHashValue) hashid = 453
  }
  (cpVect) a = {
    (CGFloat) x = -84.4253
    (CGFloat) y = 0
  }
  (cpVect) b = {
    (CGFloat) x = 84.4253
    (CGFloat) y = 0
  }
  (cpVect) n = {
    (CGFloat) x = -0
    (CGFloat) y = 1
  }
  (cpVect) ta = {
    (CGFloat) x = 392.52
    (CGFloat) y = 186.363
  }
  (cpVect) tb = {
    (CGFloat) x = 314.603
    (CGFloat) y = 36.5646
  }
  (cpVect) tn = {
    (CGFloat) x = 0.887163
    (CGFloat) y = -0.461456
  }
  (cpFloat) r = 25
  (cpVect) a_tangent = {
    (CGFloat) x = 0
    (CGFloat) y = 0
  }
  (cpVect) b_tangent = {
    (CGFloat) x = 0
    (CGFloat) y = 0
  }
}

(lldb) print *seg2
(cpSegmentShape) $5 = {
  (cpShape) shape = {
    (const cpShapeClass *) klass = 0x0044c2f4
    (cpBody *) body = 0x08b6f35c
    (cpBB) bb = {
      (cpFloat) l = 289.603
      (cpFloat) b = 11.5646
      (cpFloat) r = 354.478
      (cpFloat) t = 151.051
    }
    (cpBool) sensor = 0
    (cpFloat) e = 0.3
    (cpFloat) u = 0.8
    (cpVect) surface_v = {
      (CGFloat) x = 0
      (CGFloat) y = 0
    }
    (cpDataPointer) data = 0x00000000
    (cpCollisionType) collision_type = 4
    (cpGroup) group = 146207580
    (cpLayers) layers = 7
    (cpSpace *) space = 0x08459150
    (cpShape *) next = 0x08b6f43c
    (cpShape *) prev = 0x00000000
    (cpHashValue) hashid = 466
  }
  (cpVect) a = {
    (CGFloat) x = -45.357
    (CGFloat) y = 0
  }
  (cpVect) b = {
    (CGFloat) x = 45.357
    (CGFloat) y = 0
  }
  (cpVect) n = {
    (CGFloat) x = -0
    (CGFloat) y = 1
  }
  (cpVect) ta = {
    (CGFloat) x = 314.603
    (CGFloat) y = 36.5646
  }
  (cpVect) tb = {
    (CGFloat) x = 329.478
    (CGFloat) y = 126.051
  }
  (cpVect) tn = {
    (CGFloat) x = -0.986463
    (CGFloat) y = 0.163984
  }
  (cpFloat) r = 25
  (cpVect) a_tangent = {
    (CGFloat) x = 0
    (CGFloat) y = 0
  }
  (cpVect) b_tangent = {
    (CGFloat) x = 0
    (CGFloat) y = 0
  }
}

And the cpContact data:

Code: Select all

(lldb) print *arr
(cpContact) $6 = {
  (cpVect) p = {
    (CGFloat) x = 392.52
    (CGFloat) y = 186.364
  }
  (cpVect) n = {
    (CGFloat) x = 0.337226
    (CGFloat) y = 0.941424
  }
  (cpFloat) dist = -49.9978
  (cpVect) r1 = {
    (CGFloat) x = 43.8601
    (CGFloat) y = -105.673
  }
  (cpVect) r2 = {
    (CGFloat) x = 480.242
    (CGFloat) y = 0
  }
  (cpFloat) nMass = 0.661856
  (cpFloat) tMass = 0.224203
  (cpFloat) bounce = 0.00751949
  (cpFloat) jnAcc = 0
  (cpFloat) jtAcc = 0
  (cpFloat) jBias = 0
  (cpFloat) bias = -0
  (cpHashValue) hash = 1489560576
}

I'm not sure what it all means for the engine but maybe you can figure it out, at least you can reproduce the bad segment2segment call (if not, give a shout what's missing).

Posted: **Wed Sep 04, 2013 10:55 am**

Ooh. Detailed. Thanks, that is potentially helpful.

So the issue is that two of the segment vertexes are extremely close to each other. It's probably alternating back and forth between two of the vertexes on the surface of the minkowski sum trying to find the closest of the two. It shouldn't do that, but I guess there are still occasional precision issues still. :-\ I haven't seen any of those come up for months.

Out of curiosity, what compiler/OS/hardware is this on? Did you set it to use 32bit floats? (defaults to 64 bit on all platforms except iOS)

Posted: **Wed Sep 04, 2013 11:00 am**

Oh, Chipmunk 6.2 was released late last night. Give that a spin, though I don't suspect that the problem will magically be fixed.

Posted: **Wed Sep 04, 2013 12:22 pm**

slembcke wrote:Ooh. Detailed. Thanks, that is potentially helpful.

So the issue is that two of the segment vertexes are extremely close to each other. It's probably alternating back and forth between two of the vertexes on the surface of the minkowski sum trying to find the closest of the two. It shouldn't do that, but I guess there are still occasional precision issues still. :-\ I haven't seen any of those come up for months.

Yes, I looked at the GJKRecurse stack and the non-zero MinkowskiPoint is alternating between two points.

slembcke wrote:Out of curiosity, what compiler/OS/hardware is this on? Did you set it to use 32bit floats? (defaults to 64 bit on all platforms except iOS)

Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)
Target: x86_64-apple-darwin12.4.0
Thread model: posix

I get this on iOS simulator so cpFloat is 32 bits.

Upgrading to 6.2.0 didn't auto-fix the issue.

Chipmunk Physics

6.2-beta: High GJK iterations warning

6.2-beta: High GJK iterations warning

Re: 6.2-beta: High GJK iterations warning

Re: 6.2-beta: High GJK iterations warning

Re: 6.2-beta: High GJK iterations warning

Re: 6.2-beta: High GJK iterations warning

Re: 6.2-beta: High GJK iterations warning

Re: 6.2-beta: High GJK iterations warning

Re: 6.2-beta: High GJK iterations warning