Further adventures with 3d physics libraries

[codifiesParticipant]

Being that ODE has a nice flat C API I decided to look first at the feasibility of wrapping it for MX2, initially things looked very promising and indeed was very quickly bouncing balls and boxes all over the place (over 1000 without lag on my laptop!) however I was directly linking to a pre compiled version of the library.

Distributing binary blobs in a module is not a brilliant idea, can’t be audited, would probably need different blobs for each platform (external thread and malloc compatibility) and then there’s the whole other world of pain that is emscripten…

Compiling from source using MX2 to build a large project like ODE isn’t straight forward and I encountered a road block, that while probably not insurmountable, it gave me pause for thought. (it has a somewhat interesting build system, with an underlying system of defines….)

For a second time I remembered my experiences with Bullet physics on the Wii, where – not even sure if it would work – I just directly imported the C++ sources I needed, and to my joy and surprise it worked – alas it really showed me what a terrible CPU the Wii had…. anyhow I digress

So I thought if I can compile a simple C++ example, but with just one g++ call, basically a few import directories and a whole mess of cpp files ( its a 4KB!!! script with 1 command!), and I have some quite high confidence that MX2 will be able to compile bullet into a module without any major road blocks. (I’ve deliberately not included all sources but carefully discovered just the ones needed for it to compile)

The down side of bullet is that its a C++ API, so a lot of the work will be flattening the C++ API into a C API (unless I’m missing some trick here) it will also mean that the user will have to be responsible for deleting physics instances (far from ideal) unless I can figure out the GC system, I’d love to be able to figure out how to trigger the GC when a particular c++ pointer to a class instance is “garbage”… and so call its destructor… (although I might be able to wrap the pointer in a MX2 class if I could find out how to find out when a MX2 class instance is being GC’d)

Anyhow still early days, but still I think some progress …

I’d definitely welcome peoples ideas and thoughts.

[Mark SiblyKeymaster]

Bullet is one of the first c++ libs I want to try and mx2-ify once c2mx2 can handle c++, so you might want to hold off for a bit!

however I was directly linking to a pre compiled version of the library.

I avoid this by #importing the library c files in a .monkey2 file – see: sdl2/makefile_windows.monkey2 etc. There is no automated way to generate this list of c files yet, but “dir *.c >t” can be a good starting point!

This does mean you sometimes have to tweak config.h files along the way as configure/cmake based systems often generate different config.h files per target, but I think it’s worth it to get everything building with the same build system.

I’ve done this with both ODE and bullet (and a ton of other libs) in the past, but with c++ projects. However, the basic idea is the same – the library c files just become c files in my project.

it will also mean that the user will have to be responsible for deleting physics instances (far from ideal) unless I can figure out the GC system

IMO, leaving it up to GC to delete physics entities is not a good idea anyway – when you want to delete a rigid body,  you want to delete it *now* or it’ll continue to affect the simulation. Your code may have dangling references to stuff that don’t get nulled or overwritten for a while, and even then the incremental GC system may delay deleting things until some random time in the future. Best to bite the, erm, bullet here and just use Destroy().

[codifiesParticipant]

oh sure allow the user to remove bodies from a world of course – just deleting it without removing it from a “world” would probably be a crash anyhow!

what I was meaning is if someone does

abody = createBody()

the old abody should get cleared up (and hard luck if they didn’t properly remove it from the world first…) but its more things like collision shapes / motion states and alsorts of misc junk that could leak when someone initialises a new level for example…

[Mark SiblyKeymaster]

I see what you mean, but there’s no easy way to do this. Bullet objects aren’t bbObjects so they can’t be GC’d. If mx2 had finalize(), you could theoretically wrap the entire API so peer bullet objects were deleted when mx2 objects went out of scope, but as yet there is no finalize. This would also introduce overhead, both in terms of GC work and going through a wrapper for everything.

Besides, what about code like…

Monkey

For Local i:=0 Until 100 Local body:=New btBody(...) world.addBody( body ) Next

1 2 3 4 5

For Local i:=0 Until 100    Local body:=New btBody(...)    world.addBody( body ) Next

…probably not a good example of real world code, but still, you’d have to pretty careful about keeping objects alive!

I think the simplest/cleanest/fastest solution would be to implement something like ‘DeleteWorldAll’ in glue code that enumerates everything in the world and deletes it before deleting the world itself, plus if necessary variations of, eg: DeleteWorldBodies etc. Bullet already tracks all this stuff anyway so it allows you to work directly with native objects without any additional GC/wrapper overhead. Leaks can happen if you forget to add something to a world, but this is kind of the opposite of forgetting to remove something from the world before it goes out of scope – except in the DeleteWorldAll case you’ll probably just leak as opposed to crash.

[codifiesParticipant]

the bodies are still live they should be on some list inside the world object, okay the wrapper might have to keep a shadow list to keep them live, but I think you should see the principle…

while bullet objects aint bbObjects could another (wrapper) class extend both the bullet object and bbObject ? – could possibly even be an actual MX2 class integrated with the bullet object

There are pro’s and con’s to every approach but I think its worth considering long and hard before abandoning the advantages of having a GC…

[Author]

Posts