View mode: basic / threaded / horizontal-split · Log in · Help
August 22, 2012
Bullet Physics in D
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.
August 22, 2012
Re: Bullet Physics in D
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
August 22, 2012
Re: Bullet Physics in D
> 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.
August 22, 2012
Re: Bullet Physics in D
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.
August 22, 2012
Re: Bullet Physics in D
>
> 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.
August 22, 2012
Re: Bullet Physics in D
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.
August 22, 2012
Re: Bullet Physics in D
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...
August 22, 2012
Re: Bullet Physics in D
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.
August 23, 2012
Re: Bullet Physics in D
> 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.
August 23, 2012
Re: Bullet Physics in D
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).
Top | Discussion index | About this forum | D home