Re: BulletD needs your help!
On Friday, 8 July 2016 at 07:59:42 UTC, Dechcaudron wrote: Hey there, I'm sad this post hasn't called anyone's attention so far. While I am defintely interested to have BulletD become a thing, I sadly can't collaborate with it so far. It's been on my mind to give Bullet as a physics engine a try for videogame development for a good year now, and I've only been using D for the last two months. Reality is I don't have any actual experience working with Bullet itself, so I don't really see how my input in the project could be valuable. Aside from the issues I mentioned, the only major issue left is to fill in the many "holes" in the bindings, so if you end up using BulletD at some point (assuming I can get it back off the ground), just file an issue on the GitHub page for anything that's missing. That makes it easier to focus development efforts. Still, I believe that for D to be taken into consideration by the general programming community we defintely need to have as many libraries as possible, covering as many topics as we can. I don't know if we have any other general-purpose physics library though. Derelict includes a binding to the Open Dynamics Engine, which is a fairly capable engine. Last time I checked, though, Bullet was somewhat better. You have my +1 for trying, and I really hope the community notices this project. Thanks!
Re: BulletD needs your help!
On Monday, 4 July 2016 at 20:03:45 UTC, BLM768 wrote: Thoughts? Concerns? Tomatoes? Hey there, I'm sad this post hasn't called anyone's attention so far. While I am defintely interested to have BulletD become a thing, I sadly can't collaborate with it so far. It's been on my mind to give Bullet as a physics engine a try for videogame development for a good year now, and I've only been using D for the last two months. Reality is I don't have any actual experience working with Bullet itself, so I don't really see how my input in the project could be valuable. Still, I believe that for D to be taken into consideration by the general programming community we defintely need to have as many libraries as possible, covering as many topics as we can. I don't know if we have any other general-purpose physics library though. I currently don't have the time to get hands down into the project, but I might start learning about Bullet pretty soon. When that happens, I will let you know to see if I'm of any use in the project. Thanks for trying to make it happen, man. You have my +1 for trying, and I really hope the community notices this project. Cheers!
BulletD needs your help!
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?
