Maintaining Babylon Fork Of Ammo.js

Questions
9

Yo @Wingnut and @trevordev … All this now not necessary. Kripken has merged my PR# 251 into the official repository. He still wants to better document the global property issue with the nature of how ammo.idl is really used to expose C++ class bindings. Its does not handle global externs.

When using native C++ bullet physics code you can access:

  • gContactAddedCallback
  • gContactProcessedCallback
  • gContactDestroyedCallback

from anywhere in your C++ code. So its not really a Babylon-Ammo issue. Im sure Will over at PlayCanvas will love this too.

But the mods i made where to create function pointer proxies in ammo.idl so you can set those global pointers using the main physics world object:

var contactProcessedCallbackPtr = Ammo.addFunction((cp, colObj0, colObj1) => { ... }
var contactDestroyedCallbackPtr = Ammo.addFunction((userPersistentData) =>  { ... }

var dynamicsWorld = new Ammo.btDiscreteDynamicsWorld(...);
dynamicsWorld.setContactProcessedCallback(contactProcessedCallbackPtr);
dynamicsWorld.setContactDestroyedCallback(contactDestroyedCallbackPtr);

But you still have to make ammo.js builds using

python make.py add_func

To enable the emscripten addFunction into the build. But now i dont need to create and maintain a babylon fork of ammo.js

Anybody can now make Native Contact Callback supported builds of ammo.js using the make.py add_func build command and submit that as a PR to BabylonJS to update to the latest builds of the official ammo.js repository.

But on another note @Wingnut… Now i know much more about the C++/JavaScript relationship and can better understand how to use the internal ammo.js stuff. I want to re-visit that collision filter group support you mentioned before. But i don’t remember what properties where talking about :frowning:

Please refresh my memory on collision filter groups stuff you found before :slight_smile:

2 Likes