Demo with Ammo.js Physics Engine

Recommended Posts

On ‎1‎/‎8‎/‎2018 at 4:23 AM, JohnK said:

@RaananW you probably are well aware of the following information but in case you are not you may find what I have learned useful.

Info on using BJS with Ammo

Threejs demos with Ammo from this github




Thanks JK for the bjs samples for ammo.js. Now that I feel very comfortable with this whole wasm, empscripten tool chain, js<->c++ interops, I am going to look into this with excitement! :)

Share this post

Link to post
Share on other sites
On 6/4/2018 at 8:26 AM, HoloLite said:

Thanks JK for the bjs samples for ammo.js. Now that I feel very comfortable with this whole wasm, empscripten tool chain, js<->c++ interops, I am going to look into this with excitement! :)

Holy crap... that bjs demo code looks good... I only have one question if you can do all the stuff with the ammo.js api and babylon.js api... WHY IS IT NOT A PLUGIN ???

I cant believe no one in the community has made this a plugin... wow

Share this post

Link to post
Share on other sites

Hey Mackey, good to hear from you again :)

Well there are problems with plugin:

- non standard, breaking cross browser compatibility, security issues etc. In the end, people won't use it. Remember silverlight? 

Not to mention the hassles of installing the plug in, which is against the spirit of webapp app development. 

I have high hopes for webassembly! 

Share this post

Link to post
Share on other sites

I been messin around with PlayCanvas to see what the other guys are doing... And man o man ... there Ammo.js implementation is KILLING our Cannon.js

Way faster, especially on mobile... much better heightmap and terrain imposters

cant tell how they do collision groups l. But that type of collision filtering has gotta be support in bullet physics... got to

i dont have the time to go figure out the whole time step and synchronize thing the cannon plugin does. With all the stuff I am trying to get the toolkit production ready.

again was hoping that would be a priority the community would be working on seeing how your physics engine does everything for you ... You NEED it for ANY type of presice movement with collision and collision detection and really ray casting ... I think a good C++ port of bullet ray cast will perform a bit better the Pick With Ray... especially when you Have to have mutiple rays casting from multiple characters in the scene. I’m just guessing... 

but PlayCanvas says they are achieving 1.5 x native speed ... that’s near full native performance

we should be working on this... for real 😳 

Share this post

Link to post
Share on other sites

Man ... I don’t really have time to figure out the whole would stepping and updating all the positions enough where I would be confident that it’s working right. But those guys over at PlayCanvas got a pretty smooth implementation of ammo.js 

So I know we can do it 

Share this post

Link to post
Share on other sites

Whats stopping us then?
Whoa, their whole engine is only 170 kb, when ours min is 1.7 mb.  I have not looked at PC in a while they are doing well it looks like.

Share this post

Link to post
Share on other sites

Hi girls.  I just wanted to keep this thread alive and bother ya'll.

Been thinkin'... 'bout physics.  I hear a rumor the @trevordev has jumped into the ammo.js "fire"... along with @JohnK and other ammo-testing pioneers.

Good to have you, t-dev!  @RaananW has been a bit real-life busy, but I'm wondering if any of you know about his "BJS Ammo Plugin" progress-so far? 

Tdev... are you building an ammo plugin... that started with his?  Just curious.  I'd love to hear a report about what you've been doing with Ammo, @trevordev.  Thx.

Have you guys seen this?

Looks a little stale, but... hmm.

Anyway, based upon names, I think Oimo is a basic clone of Ammo.  It's not important, but I wanted to talk about two parameters that we do not "honor" in our current Oimo plugin:

- collidesWith
- belongsTo

There is a guy over in another thread... wanting info about how to physics-activate a skeleton.  I know @Raggar was doing some playground work on activating @Samuel Girardin's ragdoll.  It's a good one.  Its joint work pretty well.  Rags' demos are currently broken.  Maybe he'll visit and teach us stuff.  Raggar is not scared to "go native"... talking-around the BJS plugins, and speaking in native rigidBody and joint language.

belongsTo and collidesWith - it is no problem that they are not DIRECTLY supported in the Oimo plugin.  @RaananW installed an easy system to send native calls directly to physics engines/objects.  SO, you can set collidesWith and belongsTo... just fine.

Now let's talk about collidesWith, which allows "belongsTo groups"... as values/settings (in hex).  Let's imagine a knee joint on a skeleton... and its bend limits and hinge type.  Let's roll-up a joint:
var myJoint = new BABYLON.HingeJoint({
    mainPivot: new BABYLON.Vector3(50, 0, 0),
    connectedPivot: new BABYLON.Vector3(-2, 0, 0),
    mainAxis: new BABYLON.Vector3(1, 0, 0),
    connectedAxis: new BABYLON.Vector3(1, 0, 0),
// this might be same as collidesWith 0x00000000 (nothing)
    nativeParams : {
        limit: [0, Math.PI], 
// not sure if same thing as min/max.
        min: 0,
        max: 100, 
// radians?  degrees?, who knows?
        // belongsTo: 0x00000010,
        // collidesWith: 0x00000011

source.physicsImpostor.addJoint(target.physicsImpostor, myJoint);
// late settings preferred?  Like this:
myJoint.setLimit(10, 10);
myJoint.setMotor(10, 100);
// research this
myJoint.executeNativeCall(yyyyyy);  // research this

When thinking about an upper leg and lower leg - connected by a hinge joint, we tend to want to make the mainPivot and the connectedPivot... NEAR each other.  We want a "tight hinge".

BUT... if your leg meshes are rectangular boxes(-impostors)... with some significant thickness... bending the hinge will collideWith the OTHER leg mesh... easily... due to low (vertical) distance between upper and lower leg (impostors).  (in humans, same as:  limited knee bend due-to too much thigh and calf fat)  (vomit)

See how the amount of allowed hinge-swing... was limited by a "tight hinge"? (pivot points vertically near each other).   The upper/lower leg mesh... collided with each other... after very little knee-bend allowed.  CollidesWith and grouping-tool BelongsTo... start becoming important properties/parameters, eh?

Lots of ragdoll makers... are happy using these collisions... as the motor limits (angle limits) for their ragdoll hinges.  Unfortunately... if another user comes along one day, and makes the upper and lower leg mesh be REAL SKINNY, all of a sudden.... the joint becomes very wobbly and unable to "stand up".  OR, if a future user decides to increase the distance between the two pivot points, ragdoll knee will ALSO go wobbly and faw-down-go-boom.  :)

The only way... to ensure that the knee joint ALWAYS acts like a knee joint... is to use setLimit calls (or, likely, min/max params)... and NOT depend upon collidesWith (lower leg mesh to upper leg mesh) to do your bend/rotation limits.  With setLimits on the joints, future users can spread the pivots apart or closer, or change leg mesh diameters, and the knee still acts like a knee.  It has math-set bend-limits and not impostor-collide bend-limits.

Heavy, eh?  So how do we turn a skeleton into a physics-active "jointed" skeleton?  Lots of friggin' work, I suspect.  A joint-add at the end of each bone, right?  Ow.

No real purpose or point to this post.  Just thinking about (Oimo) belongsTo and collidesWith... two parameters that, likely, we will ALSO see... in AmmoJS. 

Just thinking about how to keep ragdolls standing on their own... without having car-sized feet.  :)   In Sammy Girardin's Old Man ragdoll, I think he held them upright with an invisible mesh above their heads... and a single hinge2Joint dangling-down to their head-impostors.  The arms hung naturally, the legs did the same... setLimits or min/max on each joint.... and careful mainAxis and connectedAxis settings (natural limb-hang angles).  Phew.  Magical.

In humans, a joint's allowed bend-angles and upper/lower limits... are set by bone locations and/or muscle-extension abilities.  I haven't talked much about setMotor... but... setMotor calls are how you get a stretched muscle... to return itself to natural limb-hang.  Gravity on the limb impostors CAN do all the work... but a SWEET ragdoll... will keep increasing setMotor back-force IF another force is trying to move the hinge-angle beyond a limit.  In fact... the motor should start counter-forcing well-before the motor limit or hinge angle limit (same thing?).  Muscle stretch-ability.  Elasticity.  GRUESOME!

Constraints.  Everything is a "constraint".  Mesh are free to fly anywhere, unless they are constrained by forces such as impostors and joints.  FUN!  Mesh wrangling and roundups!  Mesh corrals.  Cowboy stuff!  I got cow poop on my boots!  Ki-Yi-Yippi-Yi-Ay, lil dowggies!  (spit)  (toothless grin)

And we're still NOT talking about skinning and weighted vertices.  This is ALL armatures.  BLECH!  :D

SO MUCH to think about, eh?  Good luck with the AmmoJS progress, guys.  I cannot find an API/docs for that thing, but I'm going to assume that it has some belongsTo and collidesWith stuff inside... along with setMotors and setLimits.  Should be a GOOD TIME!  PARTY!  Thanks for your work, guys! 

Warning:  There's still a guy/gal out there on the forum... asking how to physics-up his skeleton.  QUICK, EVERYONE HIDE... PRETEND NOBODY IS HOME!!!  heh

Somebody was doing SOMETHING... here:

Found it with playground search for mainAxis.  Its PG metadata has "Walker" in the name.  hmm.

Share this post

Link to post
Share on other sites

@Wingnut My current progress is here:

I have basic physics features working right now (Shapes, forces, etc) so this scene is good when using ammo (, whats left is collision events, parenting/joint types, gltf support and more testing/examples (eg. driving a car).

I still have an issue I am trying to solve: but havn't figured it out yet.

I may try to get a PR out soon and add additional requested features as desired. There is a lot of area to cover, I would like to support things shown here eventually:

Share this post

Link to post
Share on other sites

Thanks tDev... nice work.  Thx for the links, too.

lo-th?  That's the folks who made Oimo, right?  Interesting.  We're among friends.

Note:  If you are "on" the Firefox "ESR" update channel, like myself and other Firefox Quantum haters, you'll need to update to FF... oh... v60.0.3esr... to get your WASM activated (for the above lo-th links to work).

Their ragdolls are doing exactly as I described.  The mesh on each side of the joints are SO CLOSE TOGETHER, that the mesh impostor collisions make them "stiff".  None of the joints flex as well as a real human.  Hinge angle limits caused by colliding impostors - suck. 

The International Rag-Doll Society would give them a C- rating, at best.  :)

Smuck those ragdolls with a high-speed train, and we would probably yawn to death.  :o  About as flexible as a Pillsbury Dough-boy or Stay-Puft Marshmallow guy.

Generally speaking, if a fast-tumbling ragdoll carcass can't kick itself in the head a few times... before wrapping itself "around" a telephone pole, it hasn't met my stringent flexibility requirements. 

When that dragon grabs that medieval guardsman by the head... and starts SLAPPING his body repeatedly onto the brick floor, we need some limbs floppin' and bouncin'... violently.  And sounds, too.  We need to HEAR them bones bangin' on those bricks... SO morbidly demented!  ;)

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.