BulletD needs your help!

BLM768 via Digitalmars-d-announce digitalmars-d-announce at puremagic.com
Mon Jul 4 13:03:45 PDT 2016


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?



More information about the Digitalmars-d-announce mailing list