www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Box2D Lite D Port (Yet Another)

reply ketmar <ketmar ketmar.no-ip.org> writes:
hi. i was in need of very simple (yet usable for something more 
than "hey, this is how Big Players doing physics!") 2d physics 
engine for some of my pet projects, and i decided to use Box2D 
Lite as base (mostly 'cause it has simple joints implemented). so 
i ported it, mutilated it and had it working in less than 40 kb 
of source code. so far, so good. but suddenly...

but suddenly i realised that B2DL can operate only on boxes (no 
other body shapes were implemented), and it has O(N^2) broad 
phase. of course, this is perfectly fine for a demo purposes, but 
little limiting for my projects. so after mutilating the patient, 
i surgically enhanced it a little[1].

now my port supports the following features:
* convex polygonal bodies with different density
* SAT collistion detection
* hard and soft joints
* friction
* O(N*logN) broad phase
* source size is still ~65 KB

this is not a finished physics engine, of course, and you will 
have to do some more work to make it usable in real apps (like 
adding contact callbacks, for example), but it can give you 
something you can start with, still not really hard to follow, 
but more complete than original Box2D Lite.

among other things my port has (almost) standalone implementation 
of Dynamic AABB Tree, which powers new broad phase. even without 
further optimizations (like frozen bodies), it allows me to 
process 1100 bodies in less than 30 milliseconds. don't even try 
that with O(N^2) broad phase! ;-)

even if you aren't interested in physics engine per se, you can 
rip (and tear ;-) this implementation and use it in your 
projects. any project that needs some form of fast spatial 
selection (either 2D or 3D, the implementation supports both) can 
benefit from using dynamic balanced trees for that. it is based 
on "real" Box2D AABB Trees, and is fairly efficient (and taken 
from another project too ;-). it is using malloced pool of nodes 
internally, so it should be suitable for nogc realtime rendering.

you will need my iv.vmath[2] library for vector math. physics 
library doesn't draw anything on it's own, but the sample does, 
so it requires my iv.glbinds[3] and simpledisplay from Adam's 
arsd[4].

the code itself is not the cleanest one, but it is still readable 
(i hope), and should be easy to follow and modify.

good luck and happy hacking!


p.s. it looks like Chipmunk library has the same origins (and 
genesis, at least to some extent ;-).


[1] http://repo.or.cz/b2ld.git
[2] http://repo.or.cz/iv.d.git/blob_plain/HEAD:/vmath.d
[3] http://repo.or.cz/iv.d.git/tree/HEAD:/glbinds
[4] https://github.com/adamdruppe/arsd
Oct 30 2016
parent reply =?UTF-8?Q?Martin_Dra=c5=a1ar?= via Digitalmars-d-announce writes:
Dne 31.10.2016 v 2:36 ketmar via Digitalmars-d-announce napsal(a):

 hi. i was in need of very simple (yet usable for something more than
 "hey, this is how Big Players doing physics!") 2d physics engine for
 some of my pet projects, and i decided to use Box2D Lite as base (mostly
 'cause it has simple joints implemented). so i ported it, mutilated it
 and had it working in less than 40 kb of source code. so far, so good.
 but suddenly...
 
 but suddenly i realised that B2DL can operate only on boxes (no other
 body shapes were implemented), and it has O(N^2) broad phase. of course,
 this is perfectly fine for a demo purposes, but little limiting for my
 projects. so after mutilating the patient, i surgically enhanced it a
 little[1].
 
 now my port supports the following features:
 * convex polygonal bodies with different density
 * SAT collistion detection
 * hard and soft joints
 * friction
 * O(N*logN) broad phase
 * source size is still ~65 KB
 ...


Neat! Not that I need a physics engine right now, but it is always good
to have implementation of some structures at hand.

Anyway, tht Invisible Vector project of yours, is it a collection of
useful stuff like Adam's arsd, or is some standalone project? I am
asking, because it seems to contain some nice things (like a sat solver
port) that may help others and could benefit from being more accessible
than only with a programmer's spelunker gear. And I am saying this with
full knowledge of your passionate hate for github and to some extent for
dub.

Martin
Oct 31 2016
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Monday, 31 October 2016 at 09:22:22 UTC, Martin DraĊĦar wrote:

 Neat! Not that I need a physics engine right now, but it is 
 always good to have implementation of some structures at hand.


thank you.


 Anyway, tht Invisible Vector project of yours, is it a 
 collection of useful stuff like Adam's arsd, or is some 
 standalone project?


it is like Adam's arsd: a collection of random things. basically, 
when i need something for one of my projects, i'm going to 
steal/implement it "in-place" (i.e. in project source tree), and 
later i may see that implementation as a good thing to share 
between other projects. at this stage i'm doing some more work on 
it, and then moving it in IV. and even if it won't be shared 
between projects, i sometimes moving it to IV just to have it 
everything in one place. ;-)


 I am asking, because it seems to contain some nice things (like 
 a sat solver port) that may help others and could benefit from 
 being more accessible than only with a programmer's spelunker 
 gear. And I am saying this with full knowledge of your 
 passionate hate for github and to some extent for dub.


i investigated the possibility of having IV as collection of DUB 
projects (again), and it is still too intrusive. alas. actually, 
i'd like to feature IV as a set of libraries with dependencies on 
code.dlang.org, so people can easily use 'em, but DUB isn't very 
tolerant to things that aren't done in "DUB way". i am really 
saddened by that, but i have no desire to work on DUB, neither to 
"dubify" my workflow.

i'm trying to help those who wants to use my code, tho. ;-) i'm 
usually available on IRC.


p.s. to keep it all somewhat on-topic: if someone wants to add 
more joint types, it is possible to take 'em from Chipmunk code, 
almost unmodified. Chipmunk is using basically the same 
integration scheme (preStep/applyImpulse), so you'd have to do 
some simple renamings (cpFloat -> VFloat, etc.), and replace 
Chipmunk's vector math with iv.vmath. i deliberately avoied doing 
that to keep the code small (and to not spoil the fun of turning 
something simple to something more powerful ;-).
Oct 31 2016
next sibling parent =?UTF-8?Q?Martin_Dra=c5=a1ar?= via Digitalmars-d-announce writes:
Dne 31.10.2016 v 10:56 ketmar via Digitalmars-d-announce napsal(a):

 I am asking, because it seems to contain some nice things (like a sat
 solver port) that may help others and could benefit from being more
 accessible than only with a programmer's spelunker gear. And I am
 saying this with full knowledge of your passionate hate for github and
 to some extent for dub.


 i investigated the possibility of having IV as collection of DUB
 projects (again), and it is still too intrusive. alas. actually, i'd
 like to feature IV as a set of libraries with dependencies on
 code.dlang.org, so people can easily use 'em, but DUB isn't very
 tolerant to things that aren't done in "DUB way". i am really saddened
 by that, but i have no desire to work on DUB, neither to "dubify" my
 workflow.


Got it.


 i'm trying to help those who wants to use my code, tho. ;-) i'm usually
 available on IRC.


Ok, that is also a good option :-) I will ping you if I find myself
needing an assistance.

Thanks.
Oct 31 2016
prev sibling parent reply John Colvin <john.loughran.colvin gmail.com> writes:
On Monday, 31 October 2016 at 09:56:09 UTC, ketmar wrote:

 i investigated the possibility of having IV as collection of 
 DUB projects (again), and it is still too intrusive. alas. 
 actually, i'd like to feature IV as a set of libraries with 
 dependencies on code.dlang.org, so people can easily use 'em, 
 but DUB isn't very tolerant to things that aren't done in "DUB 
 way". i am really saddened by that, but i have no desire to 
 work on DUB, neither to "dubify" my workflow.


Are there any specific problems you came across?

If you could put up with putting each file (or maybe group of 
files that might form one dub package) in to a separate folder, 
add a dub.sdl for each folder, put a single dub.sdl in the root 
folder with all the other folders listed in it as subPackages, 
then push the whole thing to bitbucket, register on 
code.dlang.org and you're done?

If you really don't like having all those folders you could 
easily create a script to move everything in to place. Could even 
be in a git hook!
Oct 31 2016
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 01/11/2016 2:40 AM, John Colvin wrote:

 On Monday, 31 October 2016 at 09:56:09 UTC, ketmar wrote:

 i investigated the possibility of having IV as collection of DUB
 projects (again), and it is still too intrusive. alas. actually, i'd
 like to feature IV as a set of libraries with dependencies on
 code.dlang.org, so people can easily use 'em, but DUB isn't very
 tolerant to things that aren't done in "DUB way". i am really saddened
 by that, but i have no desire to work on DUB, neither to "dubify" my
 workflow.


 Are there any specific problems you came across?

 If you could put up with putting each file (or maybe group of files that
 might form one dub package) in to a separate folder, add a dub.sdl for
 each folder, put a single dub.sdl in the root folder with all the other
 folders listed in it as subPackages, then push the whole thing to
 bitbucket, register on code.dlang.org and you're done?

 If you really don't like having all those folders you could easily
 create a script to move everything in to place. Could even be in a git
 hook!


I've had a long chat with ketmar about getting it all dubified.
The biggest problem is not using GH or BB.

It was almost completed until having to change code.dlang.org to support 
his repo host, which was do-able but still more work then he or I was 
willing to put in.
Oct 31 2016
prev sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Monday, 31 October 2016 at 13:40:38 UTC, John Colvin wrote:

 If you could put up with putting each file (or maybe group of 
 files that might form one dub package) in to a separate folder, 
 add a dub.sdl for each folder, put a single dub.sdl in the root 
 folder with all the other folders listed in it as subPackages, 
 then push the whole thing to bitbucket, register on 
 code.dlang.org and you're done?

 If you really don't like having all those folders you could 
 easily create a script to move everything in to place. Could 
 even be in a git hook!


that's not something i'd call "non-intrusive". ;-)
Oct 31 2016
parent reply John Colvin <john.loughran.colvin gmail.com> writes:
On Monday, 31 October 2016 at 13:53:26 UTC, ketmar wrote:

 On Monday, 31 October 2016 at 13:40:38 UTC, John Colvin wrote:

 If you could put up with putting each file (or maybe group of 
 files that might form one dub package) in to a separate 
 folder, add a dub.sdl for each folder, put a single dub.sdl in 
 the root folder with all the other folders listed in it as 
 subPackages, then push the whole thing to bitbucket, register 
 on code.dlang.org and you're done?

 If you really don't like having all those folders you could 
 easily create a script to move everything in to place. Could 
 even be in a git hook!


 that's not something i'd call "non-intrusive". ;-)


I'm not saying it's non-intrusive, I'm suggesting that there 
might be a way to get what we all want - the code easily 
accessible for dub users - that might not be *too* 
intrusive/disruptive for you to put up with. Some sort of 
compromise in lieu of the perfect solution.

If it's really just the bitbucket / github thing then.... I mean 
there's such a thing as pushing a principle below its point of 
zero-benefit, but that's your choice. Hopefully code.dlang.org 
support for other hosts will come soon.
Oct 31 2016
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Monday, 31 October 2016 at 16:33:53 UTC, John Colvin wrote:

 I'm not saying it's non-intrusive, I'm suggesting that there 
 might be a way to get what we all want - the code easily 
 accessible for dub users - that might not be *too* 
 intrusive/disruptive for you to put up with. Some sort of 
 compromise in lieu of the perfect solution.


almost flat directory layout matters for anyone who is not using 
dub, but prefer rdmd. i never ever break rdmd in leu of dub, 
'cause rdmd is far superior. and creating a new repo with alot of 
dirs will break rdmd for those who will simply do "git clone 
<url> iv". that is what i am calling "thou should obey Me, Master 
DUB".

but it seems to be unnecessary to change my directory layout (at 
least that is what Rikki said when we tried to "dubify" IV last 
time).


 If it's really just the bitbucket / github thing then.... I 
 mean there's such a thing as pushing a principle below its 
 point of zero-benefit


"going dub" will not bring me a single dime. i didn't betrayed my 
beliefs for money (that's why i have none now), so of course i 
won't do it for free.
Oct 31 2016