Demo with Ammo.js Physics Engine

[JohnK]

For no good reason I was thinking about physics engines and came across this.

On 10/12/2017 at 8:37 PM, BitOfGold said:

Just one more thing: there is also ammo.js, which is the javascript port of Bullet. It has everything - but the APi is so horrible.
Maybe it is the best choice.
https://github.com/kripken/ammo.js/

As I was looking for a new challenge I took a look and as BitOfGold said the API is horrible but though I would give it a go. I took this example and had a go at making it work with Babylon. Never having worked with 'workers' before I had a go at doing a test with a direct implementation with Babylon.js which is here  and if anyone is interested the code is at github.

Very early days but slowly over the next year I will have a go at seeing what is possible and if getting somewhere will see whether it would make a good extension with added documentation. As a very amateur coder however I have a lot to learn for example how do I use ammo.js without enclosing everything in

Ammo().then(function(Ammo) {

})

Anyone else interested in seeing what is possible with Ammo.js and Babylon.js the let me know.

[Pryme8]

http://www.webappers.com/2012/12/11/a-comparison-of-javascript-physics-engines/

this goes over some of the aspects of ammo that might interest you!

[GameMonetize]

@RaananW told me recently he was interested in writing an Ammo driver for bjs

[RaananW]

This is planned for 3.2. and what is planned shall be done!

I really want ammo integrated, mostly the soft bodies... I have a few things on my plate right now, and ammo comes next.

[JohnK]

I am having a play with soft bodies at the moment seeing if I can get it to work with BJS. Will publish a demo here if I can get it to work. May be a few days yet.

[Wingnut]

Really, guys?  Do any of you think that Oimo and Cannon has been well documented or has decent BJS test examples?

Ya'll COULD help me advance that Oimo leg-joints project.  You COULD work-on the Babylon Canvas2d/GUI virtual joystick graphics/gfx library, originally scheduled for 2.5.

You COULD do the first Babylon GUI HUD, which is likely to be MEGA-popular.  You COULD teach custom BABYLON GUI control programming, and create a scrolling textBlock.

Someone COULD proof-read spell-check the new docs.

I beg of you guys... please don't get caught-up in chasing new things... when the old things are still in need of love.  Some of our best BJS clean-up people... have been lost to chasing bleeding edge crap and other VR/AR toys.  We won't get users to adventure deep into the BJS woodlands park, if the darned parking lot and entry gate... is a miserable mess.

Please consider my hopes... to make sure the OLD walkways are clear of treacherous gravel... before breaking new rocks. 

http://urbanproductions.com/wingy/babylon/misc/j2h02.htm

Really, that doc needs someone to XSLt stylesheet, or JS-massage that pig, so it's more readable/sane.  Any chance someone could work on that?  Perhaps a new jsDoc-to-Html from the newest Oimo src? 

Really, we need a GUI "layer" that 'labels' all impostors and joints, and these labels track them.  Joint labeling should TRY to show mainPivots, connectedPivots and active axes.  Impostors labeling could be JUST a label, but it could be stretched to the same size as the impostor.  Extra creds for min, max ,limit, spring/damping, and collsion true/false indicators... on the labels.

There's SO MANY old things that need work, in my opinion.  I'm not allowed to make decisions for anyone, but I am allowed to remind people to consider (re-) weighing priorities.  I personally feel that I am WAY WAY behind schedule in building widgets and tools for the 3D mesh-part of PBT's (playground-based tutorials).  SpinTo, MoveTo, ScaleTo, ColorTo... easy animators for moving mesh around and making arrows flash.  JohnK has the editor handled, DK has the GUI handled (except for scrolling textBlocks if we ever need those)... and I... am SLOW.

We BADLY need a terminology-teaching system/PBT.

If I said that it "felt like"... "my people" are being left-behind, as some folks chase fancy/new stuff, would that sound sane?  In my opinion, we lost Davrous to this.  We might have lost Temechon to this.  And Gwenael.  Sammy Girardin?  Andy Beliveau?   Are we about to lose Sebavan, Luaacro, Deltakosh?  Are the warriors of BJS... battling SO FAR AWAY from the peasants that they once fought-for... that they've lost touch of original objectives?  (make BJS SUPER-easy.)   Should I be worried?  Maybe not.  Maybe so.

[adam]

5 hours ago, Wingnut said:

Should I be worried? 

No

[GameMonetize]

@Wingnut: no need to worry. We have thousands of people expecting things to be done and few contributors so it is a matter of prioritization and also of want contributors are excited to work on

One place where you can certainly help will be to create issues describing precisely what could be improved. I sometimes receive emails from people willing to help and I always point them to our github repo

[Wingnut]

  *nod*

But there's an issue with issues.  github issues are "official" issues... and power programmers are strict "type" police (and so is typescript).

Many of the things I propose, the "by definition" czars will surely yell "That's not the job of a webGL framework... to teach/provide.  By definition, [whatever] is NOT part of a webGL framework."

Weird Wingnut ideas that have not been voted-on or campfire decision-by-committee'd... are not BJS issues.  They are ideas.  Their purpose is often... to smooth/speed learning curves.  Are bumpy learning curves... considered an issue?  Perhaps it's considered "not our job"?  The cold, strict, unfriendly environment of github... is not where you will find good ideas.  Good ideas are found in discussion groups, in topic-police-free areas like the wingnut chronicles, where newbies can flow without feeling embarrassed about asking dumb questions or saying dumb things.

I might have submitted an "issue"... once.  All other Wingnut-seen "things-that-could-be-improved"... are my opinion/idea, and likely poorly thought-out.  They are nowhere NEAR qualifying to be a github-grade "issue".    Those issues are where smart people talk, not whimsical storytellers and dreamers.   I'm scared of that area.  Too many geniuses around... I get too nervous.  It's safer out here in the forum, where I can rattle-on aimlessly, and people forgive me, because I didn't contaminate official "issues".

Even Q&A... it's not really the place for "What if we did this?  What if we had that?  Can this or that be done?  Would that help people?"

I dunno.  Wrong topic for here, I suppose.  Yay AmmoJS!  How's that?    (yet another monster to attempt to teach myself/others about).  Yay!  I'm looking forward to the pain.  EnergyJS next?  What do we figure?  About 120 different joints to teach/PBT-ize... before the next engine comes along?  I don't foresee us ever catching up.

[GameMonetize]

We can always discuss ideas here but for the sake of my mind I need to track what to do on the github repo or I will forget some for sure.

So we can discuss here about ideas / dreams and if we agree that the idea must be developed then we can "officially" add it to the repo

[Wingnut]

20 minutes ago, Deltakosh said:

if we agree that the idea must be developed

It never works that way.  Getting a "concensus" in a decision-by-committee community... phew.  Rough.  Just explaining the idea to everyone who wants "a say"... painful.  Justification and substantiation, ouch.  Bytes are in high demand.  And watch out for "That's not the job of a webGL framework".

Let's use an example from earlier.  Is it "our job"... to teach the terminology used within the BJS framework?  Is it a "good idea"?  Is it a good-enough idea... to become our job?

If we all voted on that, I wonder what the results would be.  Indecisive, I bet. 

But yeah, I understand your points, DK.  Personally, I would prefer that YOU make the final decisions.  For me, that's safer.    But you're always too kind to tell me "Wingnut, that's the dumbest idea I have ever heard from you!" 

[GameMonetize]

I would vote for that and I would be happy if someone volunteers to write it in the doc

[JohnK]

Finished my first playing with softbodies with ammo.js and BJS. This demo is just a proof of concept and is by no means efficient coding. Click to fire balls.

It is an attempt to recreate this http://kripken.github.io/ammo.js/examples/webgl_demo_softbody_volume/index.html which uses threejs.

Will be adding some of the things I have learned to the github ReadMe file over next few days.

Tried to add shadows but everything slowed down and then came to a halt when balls fired.

[Dad72]

I love soft bodies. Beautiful demo. Can be a little slow I feel.

[JohnK]

2 minutes ago, Dad72 said:

Can be a little slow I feel.

Agree, especially compared to the Threejs demo I mentioned. However when I or others learn more I am sure it can be tweaked. There are still some parameters I do not know what they do.

[Wingnut]

Nice, JK!  Thx.

As you might know, I recently learned some things about Oimo's world 'step' and Cannon's world 'dt' step speeds.

I noticed physicsWorld.getWorldInfo() in your demo.

Any chance you could paste the info which returns from that call... to the forum.  Or to scene display?

I am curious what info is returned. 

Goal:   It might be interesting to have a GUI slider in your scene... to adjust AmmoJS's "step" speed... if you can find its setting, and feel like adding a slider.  (thx either way)

[JohnK]

@Wingnut this page will now display the Physics World info in the console.

18 minutes ago, Wingnut said:

Goal:   It might be interesting to have a GUI slider in your scene

There are a number of parameters that could usefully  benefit from a GUI slider so I can see what effect they have. My to do list for ammo.js is currently to

1. write some documentation on what I have learned so far in my Physics repository wiki (so I do not forget)
2. Come up with a template of some sort to make coding in ammo.js with BJS more straight forward.
3. Work on playing with parameters (GUI)
4. Improve demos
5. Learn about ammo joints.
6. Learn about producing a plugin (hopefully @RaananW might be working on Ammo by the time I get around to it)
7. Write good documentation on using Ammo.

As for "step" speed I have found this page and will work on playing with this.

Now back to step 1.

[GameMonetize]

Love it!

 

[Pryme8]

6 hours ago, JohnK said:

Agree, especially compared to the Threejs demo I mentioned. However when I or others learn more I am sure it can be tweaked. There are still some parameters I do not know what they do.

Looks like your subdivs on your models are cranked up compared to the three demo.

[RaananW]

I am starting with ammo.js this week, right after packing and delivering commonjs modules

Will keep everyone updated as to the progress.

[JohnK]

@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

 

 

[RaananW]

Yep, but I am planning on making an ammo plugin that will integrate with the framework, so you wouldn't need to even know that you are using ammo. Let's see how it goes.

[MackeyK24]

On 1/8/2018 at 2:34 AM, RaananW said:

Yep, but I am planning on making an ammo plugin that will integrate with the framework, so you wouldn't need to even know that you are using ammo. Let's see how it goes.

Yo @RaananW ... how’s it going with ammo.js...

are  you still working on ammo.js or have abandoned it...

I need to know if I should start looking at this or if you are going to get this working in bjs

[RaananW]

Ammo support is now planned for 3.3 as there was a bit more work on the viewer than expected. I will gladly share the branch I am working on when I start, which should actually be in the following weeks.

[HoloLite]

@RaananW hello! any update on the ammo.js support ? Would love to see the branch if it is available.

I started looking into the wasm/emscripten side recently and very intrigued by the possibilities of porting c libs into wasm.