Thread overview
Box2D Lite D Port (Yet Another)
Oct 31, 2016
ketmar
Oct 31, 2016
Martin Drašar
Oct 31, 2016
ketmar
Oct 31, 2016
Martin Drašar
Oct 31, 2016
John Colvin
Oct 31, 2016
rikki cattermole
Oct 31, 2016
ketmar
Oct 31, 2016
John Colvin
Nov 01, 2016
ketmar
October 31, 2016
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
October 31, 2016
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

October 31, 2016
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 ;-).
October 31, 2016
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.
October 31, 2016
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!
November 01, 2016
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.
October 31, 2016
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". ;-)
October 31, 2016
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.
November 01, 2016
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.