Maintaining Babylon Fork Of Ammo.js

Questions
1

Yo @Deltakosh and @trevordev … Hey guys… I think we (the babylonjs dev team) should create and maintain a fork of Ammo.js.

The Ammo js guy at (Kripken) main goal is to keep the base source build (like the one we are housing) as plain as possible. And our build is such a build. It does not support the main Bullet Physics Contact… So @trevordev ONLY option for detecting collisions is check every physics world execution step and checking and double checking contact pairs… Which does work… but this setup you ALWAYS have to know and reference ALL other impostors you want to detect collisions for… That kinda sucks… You should really use the Native Bullet Physics Contact Callback System. I made the neccessary changes to the PR #251 take a look at the details i made for the C++ source (Added function handlers to support contact callbacks) the Ammo.idl and the make.py to support teh emscriptem addFunction the only way you can wrap a javascript function as a pointer and pass as a integer (void*)

Works beautiful… and i now have an awesome pseudo Native Collision System for my Scene Manager Extension.

Kripen MAY or MAYNOT commit my PR… and if he does… WE STILL NEED to build a version of the Ammo.js with Native Function Pointer support. My PR will let you do this by simply calling

python make.py add_func

So we need a Babylon FORK of Ammo.js where can:

A: Make any needed changes to support FEATURES for BabylonJS Physics (like my PR #251)
B: Build our own versions of ammo.js using build switches like add_func

Now i have a fork that i made changes and build the dist for updated ammo.js and ammo.wasm.js

We can use that or you can add a fork to the BabylonJS organization…

I dont care which… But we need to UPDATE the ammo.js from our dist folder on github…

What do you guys think ???

2

I’m not sure I want to be in that business :smiley:

3

The PR is already made… I already made the code changes… We just need to run a build with:

python make.py add_func

I have already done this…

So basically i would like to update the ammo.js in our babylon githhub with this build here: ammo.js/ammo.js at master · MackeyK24/ammo.js · GitHub

And wherever the Ammo.js for playground is coming from :slight_smile:

Can i make a PR on Babylon js to update the ammo.js ???

4

Sure thing! As long as it works I’m all for it

5

Yo @Deltakosh and @trevordev … I made PR to update the Ammo.js library…

But … Question… Are we NOT loading Ammo.js in the Playground… ???

Is there a reason for this… ???

Does it conflict with cannon.js… ???

6

All the physics libs are included here for the playground: Babylon.js/index.html at master · BabylonJS/Babylon.js · GitHub

And that link should be pulling from Babylon.js/ammo.js at master · BabylonJS/Babylon.js · GitHub

7

Preview will be updated with next nightly (in a hour or so)

8

Hi guys, sorry to butt-in.

First, let’s call this new Babylon-ized version of Ammo… “Bammo”.

Ideally, you/we want Kripken to maintain Bammo FOR US, right? Expanding on that…

…when Kripken updates Ammo mainline production version, it triggers a fresh build of HIS Bammo as well, automated. The new build of Bammo would include changes made to Ammo… but re-add our BJS modifications (all done AT Kripken’s repo). Then, Kripken’s Bammo build would send us an email… “fresh Bammo available”, and we DL a fresh lib-only (no source) and re-install it in BJS folders/repos.

This way, Kripken maintains Ammo AND Bammo… perhaps for $50/year or something. This keeps Bammo maintenance… OUT OF our hands and done instead, at its home, near its author.

I can probably scrape-up $50/yr. from my lawn. :slight_smile: But we can just pass the hat (collect donations) at Team Redmond. :slight_smile:

Hell, Kripken should maintain Bammo FOR us for FREE, simply because he’s becoming famous… because-of BJS. He should be proud and honored to do something special and free… for the “Elvis” of the webGL world. :smiley: Heck, just Mackey’s limosine pulling-up in front of Kripken Inc… should be enough to make Kripken faint from star-struck. :slight_smile:

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
10

You don’t like doing forum searches, do ya, M? :slight_smile:

I think that’s where we talked about it… and where I contributed what little I know.

Umm… do these things need a for-Ammo-only custom Babylon physicsImpostor class? Or, maybe you are planning to reach-into native land to set/get these groups/masks? shrug (thx for your work on this stuff, guys. Advanced Ammo things.)

Background Info: Collision filters/masks COULD be important on the knee or elbow joints of a physics-active ragdoll. At these joints, the “shape” mesh attached to the physicsImpostors (on each end of the physics joint)… is sometimes a mesh with some “diameter” (fatness). And sometimes there is very little space/gap between the mesh shapes… AT the joint.

SO… when the joint bends WITH COLLISION ACTIVE… the shapes collide with each other… after the joint bends VERY LITTLE angle-amounts… and this gives you a stiff/inflexible ragdoll… like these. But MAYBE… these ragdolls are stiff because of using single spring-joints (as opposed to hinge-joints), and not stiff due-to shape collisions.

All in all, not much bend amount allowed on any joint, there. All of the joints on those ragdolls… have angle limits that are (possibly) dictated/controlled by shape collisions of the mesh on each end of the joint.

A BETTER ragdoll would not use shape collisions, and would allow the shapes to overlap. Then, the ragdoll would use joint angle limits/settings… which could be set to simulate ACTUAL HUMAN joint-bend-angle limits. More flexible, more realistic “raggies”. Or “raggars”, as @Raggar might call them. :slight_smile:

We want the shapes on each side of a joint… to STILL be collision-active, so they can impact with the cannonballs we fire at our raggies. BUT, we don’t want certain “specific” body parts to collide with each other. Precision collision… done with groups and filters. It’s similar to the includedMesh and excludedMesh… for our BJS lights.

I THINK… this is a decent example of when/where… collisionFilterGroups, collisionFilterMasks, and collisionObjectWrappers… might be used. Not sure, though, as I have ONLY done some of this stuff… in Oimo. Perhaps this flavor of talk… should happen in that other thread.

11

Yo @trevordev … Quick question… How do i SAFELY get a reference to the Ammo.btConvexHullShape assigned of the BABYLON.PhysicsImpostor attached to the BABYLON.Mesh ???

12

Yo @Wingnut and @trevordev … I dont know if the new builds exposed the interfaces or if was right there all along. Im just getting better at understandin the native C++ to JavaScript interface and dealing with C++ on the web… But anyways… I figured it out… Was pretty easy now that i know what im doing in ammo.js

Setting Collision Filter Groups And Filter Mask

First… Get the BroadphaseProxy for the body

var broadphaseProxy = mesh.physicsImpostor.physicsBody.getBroadphaseProxy();

Then you can call the get functions for filter group and filter mask

var currentgroup = broadphaseProxy.get_m_collisionFilterGroup();
var currentmask = broadphaseProxy.get_m_collisionFilterMask();

And set functions for filter group and filter mask

broadphaseProxy.set_m_collisionFilterGroup(newgroup);
broadphaseProxy.set_m_collisionFilterMask(newmask);

I think it was that easy all along :slight_smile:

2 Likes
13

I think you can do mesh.physicsImpostor.physicsBody.getCollisionShape() but this will give you the btCollisionShape which is a baseClass for the convexHull shape, you might need to do something to cast it to get hull specific values

14

Don’t know if this Native Function in AmmoJSPlugin might give you some ideas on accessing some ammo native stuff

15

GetCollsionShape did the trick… I thought so but always returns btCollsionShape and not ConvexHullShape … but the btCollsionShape was enough to create the ghost object from

16

So does this mean you have to now start imposing a filter group on every rigid body that gets added to the physics world? I guess what I’m wondering is, if static a object such as the ground is given a collision group, does that mean every non-static rigid body would need it’s collision mask to include the ground’s collision group in order to have object-to-ground collisions?