The problem most likely originated here:
For now, I would just use an older version of Ammo.
Edit: and of course, you could also try Oimo or Cannon.
1 Like
This is not an Ammo issue since I have tried the latest Ammo build with the 4.0.0.alpha.21 and it works as expected. I would gladly go back to the alpha version if not for the chrome webgl issue.
@Cedric Not sure how it would help but I could make a video of the result. What kind of information do you need?
That is good to know.
You can:
I will try this out but if this works you have saved my project from being simply dropped 
I will update you.
This did not work for me since the maxShaderCompilerThreadsKHR function is called right after the engine initialization but I managed to simply comment it in the babylonjs code. I am using an unsupported version anyway. Whatās interesting is that from the alpha.21 and the current version seems like the sphere behavior differs drastically ( same Ammo ) .
Maybe the parameters with which the Bullet world has been initialized are different? I never checked the world initialization to be honest but something which is quite noticeable is the damping effect. The ball stops moving much more quickly in the alpha.21 than in the latest version.
Thank you so much for the support guys. I really appreciate it !
Basically, I want to see the range of positions once you stopped (or at least tried to) the impostor.
Did you try with that line of code ?
sphere.physicsImpostor.physicsBody.setActivationState(2);
I tried everything. There is no change. changing mass as you correctly pointed out changes the sphere to a kinematic body but recalculating inertia ( turning to dynamic ) makes it rotate again. What is interesting is that in alpha.21 its not the forceUpdate which stops the sphere, the damping does. The forceUpdate just makes the movement 0. Seems like in the latest version the damping effect has changed.
So as I was peeking at the AmmoJS initialization code, I noticed the initialization has changed since the addition of soft bodies. I guess this affects at how stuff is computed in overall.
4.0.0.alpha.21
this._collisionConfiguration = new this.bjsAMMO.btDefaultCollisionConfiguration(); this.world = new this.bjsAMMO.btDiscreteDynamicsWorld(this._dispatcher, this._overlappingPairCache, this._solver, this._collisionConfiguration);
latest version
this._collisionConfiguration = new this.bjsAMMO.btSoftBodyRigidBodyCollisionConfiguration(); this.world = new this.bjsAMMO.btSoftRigidDynamicsWorld(this._dispatcher, this._overlappingPairCache, this._solver, this._collisionConfiguration, this._softBodySolver);
Would it be possible for us to choose whether to use soft bodies in initialization of the Physics engine? If this changes how the world computes stuff I think it makes sense for us to be able to choose whether we want a discrete world or a soft bodies world. Maybe giving it as an argument in the plugin initialization ?
2 Likes
Glad to be helpful!
@Null @Cedric Some further investigation on the update to the ammo plugin which was changed at the point mentioned to accommodate softbodies.
Have done some experimenting and produced two files based on the PG https://www.babylonjs-playground.com/#B5BDU#66 with a couple of minor changes.
- Made the time to call forceUpdate shorter so I could actually see the sphere stop.
- Added a printPosition = false after 5 seconds to stop the console continually printing and locking things up.
I produced two babylon.js files, babylon.max.js is the preview version from yesterday and babylon.max solid.js which is the preview version from yesterday with the ammojsplugin replaced by that from 4.0.0.alpha21.
The files index.html and index solid.html load babylon.max.js and babylon.max solid.js respectively.
These files can be found on github
You can run the index files at
Soft and Solid Bodies and
Solid Bodies Only
Although the sphere appears stationary checking the console for the sphere position values shows that in both cases they continue to change by small amounts.
This seems to imply that changes in the ammo plugin are not responsible for the problem.
From index.html
From index solid.html
1 Like
Hi John. Sorry to butt-in againā¦ I realize you were talking to Cedric and Nullā¦ butā¦
The reason for Nullās āball shakingā in HIS home projectā¦ has not been hard-linked to this floaty-floats thing. So, we should be careful when we say āThis seems to imply that changes in the ammo plugin are not responsible for the problem.ā
Really, we should say āThis seems to imply that changes in the ammo plugin are not responsible for the āfloaty-floatsā stuffā (the minor poz-drift after damp-to-stop, and/or killing velocities, and/or forceUpdate).
The only thing proved hereā¦ is that the floaty-floats-after-forceUpdate problem/stuff is not version-related. But the floaty-floats thing was foundā¦ as a side-investigationā¦ when Nullās damp-to-stop started failing after the version change.
We CAN still assume that Nullās home shaky-ball-after-damp-to-stop issueā¦ IS version-related, because Nullās home-gathered evidence is still leaning in that direction.
SO, yeah, John, you have probably eliminated āfloaty-floats-after-forceUpdateāā¦ as the reason for Nullās home problemsā¦ and this is good. Thanksā¦ nice work! I just wanted to remind anyone concernedā¦ that we still show a version-related issue for Nullās shaky balls. The side-investigation of floaty-floats as the cause for damped-to-stop shaky-ballā¦ can be set-aside for nowā¦ and other version-related thingsā¦ researched.
Ok, thx for listening and letting me weigh-in without being grumpy at me. 
Physics engines are a very meticulous thing and thereās just no room for slop and workarounds. Too preciseā¦ too performance sensitive.
Very happy for you to butt in. I agree I was being very focused on the problem as specified by the PG and the last paragraph in the first post of this topic and hence only included null and cedric as I was replying to their points in their last posts.
Thanks to your post I can now see that there is a wider issue.
So very true - it gets very confusing 
1 Like
Hey John,
Thank you so much for the thorough investigation. I tried using your latest BJS build with only solid to try and see whether the softbodies are the cause of the what I am experiencing but it crashed while calling getLinearVelocity.
I will try to capture a video to show what I mean, unfortunately I do not seem to be able to reproduce it in the playground. But in the end what I am experiencing is totally related to what I experienced in the 4.0.0.alpha.21.
Since I build my game around that version, when I tried upgrading the world seems to act differently. As I said, the ball never stops or stops VERY slowly. It slows down using dampening but not at the same rate as it used to. Also, forceUpdate does not seem to stop it, nor whatever I have tried, and trust me, I have tried almost everything.
I have also experienced a few weird things with collisions. I seem to not get all collisions in the new version. I will try to get your solid version to work so that at least we can rule the soft bodies out of the equation.
When first adding the solid body only plugin to the recent BJS I also had problems. Specifically with some webpack lines in babylon.max.js which I replaced with the equivalent lines from oddsNEdnds/babylon.max.js at master Ā· BabylonJSGuide/oddsNEdnds Ā· GitHub. This seemed to work but I only replaced enough to get the specific code in my index.html working. This could be the issue with the crash for getLinearVelocity.
So I was able to make it work with your solid version and it works like a charm. Definitely a plugin issue ( but we already knew that ). I did some further testing with the current version of BJS. What I did was change the world and the collision configuration from with soft bodies to only rigid. The issue persists so this means it is not an issue with the softbodies but with something else. Will try to do some further investigation in the differences which may cause the anomaly.