Chipmunk's Future (5.x, and beyond)

[slembcke]

So the list of features I wanted to add to Chipmunk 5.x is growing pretty short at this point. Chipmunk 5.3.3 will probably be the last 5.x release.

• Shape queries: Allow you to use a shape that has not been added to a space to query for overlaps.
• Add a data field to cpSpace. Bodies, shapes and constraints already have a data field, so why not the space?
• Allow rouge bodies to marked as static. Shapes attached to static rogue bodies will be added as static shapes, and shapes resting on them will be allowed to sleep.
• Force groups of objects to sleep. You can currently sleep individual objects, with a group if any object wakes up, they all wake up.

For 6.x I feel that I need to fix some long standing issues with Chipmunk, and I need to break API and binary compatibility slightly to fix them:

One of the biggest problems is that as a C API, Chipmunk is wide open. I consider much of it to be private, but it's not exactly well documented which parts. I think I'm going to fix this in two waves. I created a macro that I can use to mark struct fields as private. It basically does C++ style name mangling when a certain flag is enabled. In 5.3.3 I'll mark all all the private fields, but make it optional to enable the name mangling. This gives people a little warning before 6.0 is released to know how to fix up their code and gives them a chance to request public APIs to do the same things. When 6.0 is released, you still have the option of disabling the name mangling if you want to continue using code that accesses the private APIs, but you are at least well warned that minor versions may make private changes and break things. Does this seem reasonable?

There are also a number of more minor issues like a few names that don't follow the convention ("cp_bias_coef" and the bounding box functions), and a number of now unused struct fields that I want to remove.

The biggest feature that I have planned for 6.0 is supporting different collision detection broadphases. I've been meaning to do this for a very long time, but it simply never got done. I already have a working dynamic bounding box tree implementation, and have started on a static tree as well. It's not terribly optimized yet, though it does outperform the spatial hash for scenes with < 100 shapes. Additionally, I've made a nice generic API that will allow people to use the spatial indexes easily from their own code. The only downside is that any code that iterates space->activeShapes will break. Even though I tell people not to do it, everyone seems to do it anyway. (sigh)

Are there any other features that people are itching to have in Chipmunk 6.0?

[dieterweb]

I would like to have the function activateShapesTouchingShape to be made public.

Also it would be great to have breakableJoints back again. We are still using them and do not have any problems. You just have to take care when to remove them and how to free them.

The changes you are planning sound great.

Thomas

[Tam Toucan]

Additionally, I've made a nice generic API that will allow people to use the spatial indexes easily from their own code.

Does this mean use the collision detection without using the physics? I can see a lot of people wanting that (given all the posts I've seen of people trying to do that). The downside is you could end up with more posts etc from people.

[slembcke]

Well, not the collision detection system, but the spatial indexes. You could use them for your own spatial queries that don't involve physics for things like view culling of sprites or AI perhaps.

[mobilebros]

At the moment the SpaceManager project "queries" the contact set to find out information about: shape touching any shape or, if two given shapes are touching. There's probably some other useful queries as well. I imagine a formal API for this might be more appropriate.

Sounds like a good lil' roadmap all in all.

[tatt61880]

Are there any other features that people are itching to have in Chipmunk 6.0?

The polygon must be convex. Concave polygons are much more expensive to do collision detection with and Chipmunk (and most other physics engines as well) doesn't support them. I'm fairly certain that the validation function is correct.

How about implementing concave polygon in Chipmunk 6.0?
Actually, concave polygon can be much more expensive but better than nothing.

As everyone know, we can simulate concave polygon with assembled polygons, but it will be useful if it can be dealt with easily.

Regards,
Tatt

[slembcke]

Gearing up to do the 5.3.3 release soonish. I've added a number of the new features to trunk:
Shape queries are done and the API is probably final
Rouge bodies can be marked as static with cpBodyMakeStaticRogue()
Sleeping Bodies can be grouped with cpBodySleepWithGroup()
Marked out the private API with the CP_PRIVATE macro.

It would be handy if people who are using trunk to edit their chipmunk.h files to disable private access (CP_ALLOW_PRIVATE_ACCESS). What APIs do people need to replace the private accesses?

I would like to have the function activateShapesTouchingShape to be made public.

I added cpSpaceActivateShapesTouchingShape() to trunk.

At the moment the SpaceManager project "queries" the contact set to find out information about: shape touching any shape or, if two given shapes are touching. There's probably some other useful queries as well. I imagine a formal API for this might be more appropriate.

Similar features have been requested a few times now (are two bodies touching, are two bodies jointed together, etc). I'll have to think about what would make a good API for 6.0.

[mcc]

The single feature I personally am most interested in in Chipmunk is acceleration using SIMD units where available, like SSE on Intel or the VFP on the iPhone/Android ARM. (I will happily implement the VFP thing myself if I can ever find clear documentation on how to use the darn thing! Actually for all I know GCC auto-vectorize could handle this if things were configured right...)

[slembcke]

I looked into SIMD stuff a year or two back, but came to the conclusion that it didn't make a lot of sense for Chipmunk. The problem IIRC is that most SIMD instruction sets work with vectors of 4 floats. You can't really boost the performance of 2D stuff very well this way without some major rewriting. This is what other people told me too before I tried, and it turns out they were right. :-\

I looked more specifically into VFP on the iPhone, but the result was pretty much the same. After a couple of days fiddling around with a basic understanding of VFP and some inline assembly I wasn't able to actually make it any faster. The extra overhead of working with the SIMD instructions prevented any real benefits when only working with 2D math.

[bobike]

Another vote for concave poly's. This is particularly necessary for games that allow free hand drawing. Otherwise everything the user enters has to be tessellated and that leads to all sorts of problems with pointy tessellations and objects getting embedded and passing through other objects. Aside from the point that tessellating anything is somewhat of a pain. Tessellation also increases the computation time due to the time to tessellate and the increased number of objects in chipmunk on every iteration.

I'm guessing that the increase in computation time for the collision algorithm wouldn't be that different than the time from doing it the hard way.

And for those who don't need concave polys, or only have a a few that can be done manually but don't want the performance hit, then maybe a setting to switch off concave poly support.

Thanks.