6.2.0 has been a long time coming, and is a MAJOR overhaul of the collision detection to to use the GJK/EPA algorithms for the primary collision detection instead of SAT. This has a couple benefits. It allows implementing polygon shapes with a corner radius (useful for smooth player shapes). It also allows you to find the shortest distance between any two shapes (though that's not exposed just yet). This will be very useful in later versions for queries and implementing swept collisions. Performance with GJK can also be faster than SAT. The contact point generation code has also been completely rewritten. It generates much higher quality contact points that solve some rare but long-standing collision detection bugs. It also guarantees that poly to poly collisions will generate no more than 2 contact points which is very useful.
A lot of people are going to ask how it affects performance. Well, poly to poly collisions are slightly slower (like 10%) if they have a rounding radius of zero. This is due to needing to fall back on the EPA algorithm for overlapping shapes. If you give your polygons a rounding radius of at least the collision slop amount, you should find performance to go up (again about 10%). So a little slower as a drop in replacement, a little faster if you use the new features. I'm not entirely happy about that, but it should be worth it I swear.
What's new in 6.2.0:
Collision detection now primarily uses the GJK and EPA algorithms instead of SAT. Internally this was a rather huge change. o_O
Improved collision point quality and better collision point identification.
All shape types can now be given a rounding radius.
Collisions are now guaranteed to have a maximum of 2 collision points.
Poly to poly collision performance is slightly better when they have a radius. Slightly worse with none.
Implemented smoothed segment collisions to prevent colliding with the "cracks" between segment shapes.
API: (Officially) added cpSegmentShapeSetNeighbors() used to enable smoothed line collisions.
API: Added cpBBCenter() to get the center of a bounding box.
API: Added cpPolyShapeInit2() and cpPolyShapeNew2() to create poly shapes with a radius. (Horrible names yes, but it will go away in Chipmunk 7)
API: Added cpBoxShapeInit3() and cpBoxShapeNew3() to create boxes with a radius.
API: Added cpPolyShapeGetRadius() and cpPolyShapeSetRadius() (the latter only in chipmunk_unsafe.h).
API: Added cpNearestPointQueryInfo.g which returns the gradient of the signed distance field for the shape.
BUG: cpMomentForPoly() will now return a correct value for degenerate 2 vertex polygons.
BUG: Fixed an issue where certain segment query calls would return a t value of 0 instead of 1 for a missed query.
MISC: Passing cpvzero to cpvnormalize() will now return cpvzero. No need to worry about NaNs or cpvnormalize_safe().
MISC: Demo app now uses GLFW instead of GLUT, and has improved drawing and text rendering routines.
Hrm. Do your video drivers not support VAOs maybe? (Can they be updated?) Shoot... I thought that was a terribly well supported feature even 5 years ago. Writing GL shader code without them is such a pain. :-\
(Ignore the "APPLE" tag. GLEW is smart enough to map that to the ARB or native version. I only used that as a workaround for another GLEW bug.)
Can't sleep... Chipmunks will eat me...
Check out our latest projects! -> http://howlingmoonsoftware.com/wordpress/
I'm pretty excited about the new solver, congrats on the release!
I did notice one possible issue! I pulled the new code from git today, and unfortunately I'm seeing a lot more overlap/slop in my poly/poly collisions than before.
To give some possibly relevant details, I have two vaguely round poly shapes with about a dozen vertices each. One is around 100 units in diameter, and the other is around 1000 units (not setting polygon radius explicitly). Both are situated about 15k units from the origin. Before I was seeing no more than one or two units of slop, and with the new version I'm frequently seeing it sit there with a good 10 units of overlap, with no forces pushing the shapes together. I have no gravity, a timestep of 1/60th of a second, using the bbtree with nearly a thousand shapes overall, this is on a mac using xcode, and chipmunk is using double precision floats.
I also noticed that my segment queries are no longer "seeing" shapes that they were seeing before, which may be related.
Anyway, is there anything immediately obvious I can try that might help reduce the slop?
- How do I replace cpSpaceRemoveCollisionHandler that doesn't exist any longer?
- For old code migration: Are you planning to have a quick upgrade guide?