6.2-beta: High GJK iterations warning

[tomeksowi]

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.

[slembcke]

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. :-\ )

[tomeksowi]

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.

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.

[slembcke]

Hmmmmm... :-\

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

[tomeksowi]

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).

[slembcke]

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)

[slembcke]

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.

[tomeksowi]

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.

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.