www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Bullet Physics in D

reply "BLM768" <blm768 gmail.com> writes:
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.
Aug 21 2012
next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
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
Aug 22 2012
parent "BLM768" <blm768 gmail.com> writes:
 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.
Aug 22 2012
prev sibling parent reply David <d dav1d.de> writes:
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.
Aug 22 2012
parent reply "BLM768" <blm768 gmail.com> writes:
 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.
Aug 22 2012
parent reply "BLM768" <blm768 gmail.com> writes:
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.
Aug 22 2012
parent reply "BLM768" <blm768 gmail.com> writes:
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...
Aug 22 2012
parent reply "BigSandwich" <bigsandwich gmail.com> writes:
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.
Aug 22 2012
parent reply "BLM768" <blm768 gmail.com> writes:
 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.
Aug 22 2012
parent Chad J <chadjoan __spam.is.bad__gmail.com> writes:
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).
Aug 22 2012