A while back, I tried porting Bullet Physics to D, and I decided to resume work on it. I've got the code I've ported so far at sourceforge.net/projects/bulletd. I wrote most of the code when I was early in my D learning experience, so it's fairly rough, and it's nowhere near complete (a rough line count analysis gave well under 5%), but it's a start. If anyone wants to help, it would be appreciated.

My main reasons for making a port rather than a binding are that SWIG doesn't like nested classes, so it's useless for Bullet, and I wanted to integrate it with the GC. D and C++ are close enough that getting a port of at least the basic features shouldn't take too long; I'm not sure what I'll end up doing about the OpenCL options and such.

On Wednesday, 22 August 2012 at 05:30:17 UTC, BLM768 wrote:
> A while back, I tried porting Bullet Physics to D, and I decided to resume work on it. I've got the code I've ported so far at sourceforge.net/projects/bulletd. I wrote most of the code when I was early in my D learning experience, so it's fairly rough, and it's nowhere near complete (a rough line count analysis gave well under 5%), but it's a start. If anyone wants to help, it would be appreciated.
>
> My main reasons for making a port rather than a binding are that SWIG doesn't like nested classes, so it's useless for Bullet, and I wanted to integrate it with the GC. D and C++ are close enough that getting a port of at least the basic features shouldn't take too long; I'm not sure what I'll end up doing about the OpenCL options and such.

You could make use of the OpenCL bindings for D.

https://github.com/Trass3r/cl4d

--
Paulo

> You could make use of the OpenCL bindings for D.
>
> https://github.com/Trass3r/cl4d
>
> --
> Paulo

That should work. I'll probably focus on the OpenCL stuff last, but I'll keep that in mind; it should help make the porting a little easier.

Am 22.08.2012 07:30, schrieb BLM768:
> A while back, I tried porting Bullet Physics to D, and I decided to
> resume work on it.

This is great!

> I've got the code I've ported so far at
> sourceforge.net/projects/bulletd. I wrote most of the code when I was
> early in my D learning experience, so it's fairly rough, and it's
> nowhere near complete (a rough line count analysis gave well under 5%),
> but it's a start. If anyone wants to help, it would be appreciated.

What do you think of moving to github? It makes contributing a lot easier.

>
> What do you think of moving to github? It makes contributing a lot easier.

I'm fine with that. I should have it moved within an hour.

On Wednesday, 22 August 2012 at 18:39:40 UTC, BLM768 wrote:
>
>>
>> What do you think of moving to github? It makes contributing a lot easier.
>
> I'm fine with that. I should have it moved within an hour.

OK; got it moved. It's at https://github.com/blm768/BulletD.

I'm trying to figure out the allocation model that the port should use. Bullet normally provides its own allocators for efficiency, but I've been trying to integrate the port with the GC where it's practical. Does anyone have suggestions on the best approach?
I'm not too familiar with Bullet's allocation system, so I should probably research that...

On Wednesday, 22 August 2012 at 20:26:37 UTC, BLM768 wrote:
> I'm trying to figure out the allocation model that the port should use. Bullet normally provides its own allocators for efficiency, but I've been trying to integrate the port with the GC where it's practical. Does anyone have suggestions on the best approach?
> I'm not too familiar with Bullet's allocation system, so I should probably research that...

I've used Bullet in a professional capacity, and I'd hesitant to force the GC on your users.  I'd port their allocators and supply implementations that map to malloc or the GC and let users that have their own heap implementations map them to those.

There are a couple of reasons for this:
1) Most large game engines/simulations probably already have several types of custom allocators that they'd like to map bullet allocations to.

2) GC is not necessarily the best model for keeping track of physics data.  Usually, physics objects are tied to their game entity counterparts and should be cleaned up as soon as those go away.  This ownership is mostly unambiguous, so its not much of a burden to remember to clean up the physics objects. I used ref counting when I set up my company's implementation but even that is probably not necessary.

> I've used Bullet in a professional capacity, and I'd hesitant to force the GC on your users.  I'd port their allocators and supply implementations that map to malloc or the GC and let users that have their own heap implementations map them to those.
>
> There are a couple of reasons for this:
> 1) Most large game engines/simulations probably already have several types of custom allocators that they'd like to map bullet allocations to.
>
> 2) GC is not necessarily the best model for keeping track of physics data.  Usually, physics objects are tied to their game entity counterparts and should be cleaned up as soon as those go away.  This ownership is mostly unambiguous, so its not much of a burden to remember to clean up the physics objects. I used ref counting when I set up my company's implementation but even that is probably not necessary.

I'll probably mainly keep Bullet's system in place, then. I might at least replace Bullet's C++ "new" and/or malloc with GC allocations, but I'm undecided on that.

On 08/22/2012 09:06 PM, BLM768 wrote:
>
>> I've used Bullet in a professional capacity, and I'd hesitant to force
>> the GC on your users. I'd port their allocators and supply
>> implementations that map to malloc or the GC and let users that have
>> their own heap implementations map them to those.
>>
>> There are a couple of reasons for this:
>> 1) Most large game engines/simulations probably already have several
>> types of custom allocators that they'd like to map bullet allocations to.
>>
>> 2) GC is not necessarily the best model for keeping track of physics
>> data. Usually, physics objects are tied to their game entity
>> counterparts and should be cleaned up as soon as those go away. This
>> ownership is mostly unambiguous, so its not much of a burden to
>> remember to clean up the physics objects. I used ref counting when I
>> set up my company's implementation but even that is probably not
>> necessary.
>
> I'll probably mainly keep Bullet's system in place, then. I might at
> least replace Bullet's C++ "new" and/or malloc with GC allocations, but
> I'm undecided on that.

I don't know much about this library, but what you're saying sounds like a good strategy.  Things in the D ecosystem tend to be safe by default (use GC by default in this case) but allow for optimizations or low level tweaking (allow users to supply their own allocators if they want to).