A couple of years ago, I started writing some bindings for the Bullet Physics library (bulletphysics.org). This was well before D's new C++ interop features, so I wrote a hacky little chain of build scripts (which generated each other about 3 levels deep!). The thing actually worked to a certain extent, and there seemed to be some community interest in the project, but then life kept me from spending any time on the project, and it basically died.

That brings me to the topic of this post: if the community still has an interest in Bullet Physics bindings, I'm willing to revive the project, but I'll need some input from the community in order to figure out what direction to take the it.


As far as I can tell, D's C++ interop has improved to the point where it should cover all the C++ features that Bullet uses. That would make most of the binding generation code unnecessary (although some glue to semi-automatically instantiate C++ templates could be useful). However, I've never used the C++ interop features, so I don't know how stable they are in a cross-platform environment, especially with LDC and GDC.

The other option would be to clean up the binding generation code. The advantage I see here is that the code may be useful for creating bindings to other languages, i.e. Rust. However, the solution I had wasn't very elegant, and a better solution is unlikely to happen until PR 5290 gets merged.

To give an idea of how the binding generation would work, here's a basic idea of how the code would look when binding to a simple class hierarchy:

struct RayResultCallback
{
        mixin classBasic!"btCollisionWorld::RayResultCallback";

        mixin method!(void, "setCollisionFilterGroup", short);
        mixin method!(void, "setCollisionFilterMask", short);
        mixin method!(bool, "hasHit");
}

struct ClosestRayResultCallback
{
mixin classChild!("btCollisionWorld::ClosestRayResultCallback", RayResultCallback);

        mixin opNew!(ParamRefConst!btVector3, ParamRefConst!btVector3);
        mixin method!(btVector3, "getHitPointWorld");
        mixin method!(btVector3, "getHitNormalWorld");

mixin method!(ParamPtr!(btCollisionObject), "getCollisionObject");
}

It's not quite as readable as plain D, but that's because it's creating a whole C glue layer behind the scenes (with a little external help to produce the C(++) source files).

Thoughts? Concerns? Tomatoes?

Reply via email to