scene.gravity = new BABYLON.Vector3(0, -0.9, 0);
scene.enablePhysics();
It set CannonJS by default.
On 4.0.0 in order to avoid ‘CANNON is undefined’ issue I have to do it like that:
scene.gravity = new BABYLON.Vector3(0, -0.9, 0);
let cannonPlugin = new BABYLON.CannonJSPlugin(true, 10, cannon);
scene.enablePhysics(scene.gravity, cannonPlugin);
But in this case objects falls much slower comparing to 3.2.0. In order to keep physics dynamics from 3.2.0 I have to pass to ‘enablePhysics’ another gravity vector:
scene.gravity = new BABYLON.Vector3(0, -0.9, 0);
let cannonPlugin = new BABYLON.CannonJSPlugin(true, 10, cannon);
scene.enablePhysics(new BABYLON.Vector3(0, -5, 0), cannonPlugin);
Why is this happening? Not sure that scene gravity and physics gravity desynchronization is a good thing.
If you don’t need to support mesh impostors and only need boxes and spheres for imposters; then I would personally use Oimo. It’s most likely going to be quite a bit faster - depending on your needs.
What you’re setting in Cannon.js is not abnormal. However, I believe you’re overwriting the scene gravity when you set the new vector. The Y value should not be additive in any way. I’ve run into this before where I have to set enablePhysics(); - but then I can remove the gravity setting. You’re using the same settings the two ways you have this written. But in the first example, you’re passing the gravity forward to your enablePhysics(); attribute. But the two ways do exactly the same thing. However, you don’t need to set gravity in the second example - unless there’s a redundancy that needs to be declared before setting a new vector. But if that’s the case, I’d call it a bug.
There doesn’t seem to be any substantial difference; as I can’t see any changes that affect gravity in babylon.js 4.0 alpha. But I personally wouldn’t migrate to 4.0 just yet; even though the babylon.js alphas are usually very stable (from my experience), unless you’re not in production and/or need a new tool available only in 4.0 alpha.
As for physics, I use both Canon.js and Oimo.js - depending on the scene. They both offer virtually the same level of control; however the settings for each will vary dramatically when compared to one another. I hope this answers your question. If not then the guys who write this should log on in a few hours.
@Galen, I am using scene.gravity for FreeCamera. The value -0.9 works good for jumping, crouchig and stairs ascending (in both versions). In 3.2 I had no need to pass this vector to physics engine (not sure which value was used in Cannon by default). But in 4.0 I have to. If I pass same -0.9 to enablePhysics, then meshes fall very slowly, despite camera still works OK. So, now I have -0.9 for camera behavior and -5 for physics engine.
If I will set -5 to scene.gravity then stairs ascending will not work.
Summary about my examples above:
First example:
3.2 => camera - ok, physics meshes - ok
4.0 => doesn’t work at all due to ‘CANNON is undefined’ issue.
Second example:
3.2 => didn’t try
4.0 => camera - ok, physics meshes - very slow.
Second example:
3.2 => didn’t try
4.0 => camera - ok, physics meshes - ok.
The question it self: why second example in 4.0 doesn’t work like first example in 3.2? Is it ok to use different vectors for scene.gravity and enablePhysics?
OK… I better understand what you’re doing. I hadn’t realized that you were setting different vectors for different components; as I didn’t see you apllying this in your code snippets; and I’ve not set up the physics engine in the manner before. I recall that @Deltakosh pointed out to me to enablePhysics() in a specific scene following the release of BJS 2.0 when the physics in a scene no longer functioned when I updated to a new release version.
It’s a bit maddening that there is little consistency in the use of the physics extensions from version to version - especially when I can’t find a change in the physics extensions or find specific changes to babylon.js file which might possibly affect the physics extension. I’ve reviewed the Babylon.js 4.0 min file and can’t see why we might need to define a difference between versions. Perhaps @trevordev can shed some light on this.
I do understand how to set up the physics extensions as little has changed in years. But I cannot find why the extensions are not fully backwards compatible when applying to a new scene. I just tested some old physics scenes from 2014, and they appear to work fine in babylon.js 4.0 alpha; but I’m using Omo.js not Cannon.js. So now I’m more lost than you perhaps. I hope we can put this to rest by tomorrow morning.
It seems scene.gravity was never used in the physics plugin from the code history I was able to find and Im not sure this logic was changed recently unless im looking in the wrong place.
From the physics consistency side, backwards compatibility between versions is a high priority but there are also things considered bug fixes (eg. CannonJS ignores connectedPivot joint parameter) that others may consider breaking if code was written expecting the original behavior and posts on the forum definitely help catch things missed or broke by mistake. The only major intended physics break I’m aware of was around BJS 2.0 time frame that Galen pointed out and I believe their was a forum post about it and described in the what’s new section of the release notes.
Oh, if i understand correctly, could you pass in undefined for the gravity parameter? This will default it to the same gravity it would normally use when calling scene.enablePhysics() without parameters like you used to (eg. new Vector3(0, -9.807, 0)). Let me know if that works.