here is a playground example. Just press ArrowUp and you will see that camera cant go up on ramp. Can someone explain me why ?
https://playground.babylonjs.com/#5MT5D6
2 Likes
Hiya KW. Camera is too heavy to climb “lip” of ramp. Ramp too steep or scene.gravity.y is too strong.
Set line 4: scene.gravity = new BABYLON.Vector3( 0, -1.81 ,0 ) … all is fine.
Darned camera.applyGravity = true, huh? It helps us, and yet it sometimes bothers us. 
Perhaps we need some better climbing boots for our universalCamera, eh?
can i somehow keep this gravity (i have other features that work fine with it) and maybe reduce the mass of camera or something
I don’t have a good answer for that, but maybe others do, soon.
For now, I have an idea. Play with the value of Engine.CollisionsEpsilon. MAYBE you’ll see some results… with that. Chances are low, though.
This value is the angle needed… for the camera’s .ellipsoid (its collider) to “scrub-off” of a collided target. ie. What angle does camera need to hit a wall-at… where repeated up-arrow lets camera “scrub-along” the wall… vs. when repeated up-arrow refuses to move the camera at all.
Notice line 7: camera.ellipsoid = new BABYLON.Vector3( 2, 2, 2 ). I believe that is rather large… about 4x the default collider-size. You might want to remove that line, too… or change it.
Maybe you need it that big, though, and I understand why. If you have problems with mesh disappearing when camera gets too close/collides, be sure to adjust camera.minZ.
The camera also has a camera.ellipsoidOffset… a way to move the ellipsoid collider around-within the camera… but that is unlikely to change anything. (Changing ellipsoidOffset.y WILL change the height of your camera as it moves around, but the collider will still be against the ground, so same problem).
Having a .mass property on gravity-active cams… that’s a pretty good idea. hmm.
Stay tuned for more ideas from others.
2 Likes
Hi again. I found a way to “fake” a mass-reduction on universal cam. (a creepy way)
https://playground.babylonjs.com/#5MT5D6#2
In lines 2-27, I “hijacked” a piece of the UniversalCamera… bringing it into our local-scope… where we could hack on it.
In line 24, I added .scale(.4) … effectively reducing camera mass by 60%.
It is dirty and ugly… but we can climb ramps, now.
Caution… I down-scaled ALL THREE gravity axes… X/Y/Z. So, it MIGHT affect… oh… maybe camera.inertia and a couple of other camera behaviors. A wiser person might ONLY down-scale on the Y axis of gravity, and leave-alone X and Z axes.
Again, look for problems with this “creepy” mod. It could easily affect other camera traits.
Interesting note: Camera does not land well, after dropping from ramp. Also, with down-scale of 0.5… you need to tilt-up camera to climb ramp (slowly). If you look down at ramp… can’t climb. It’s a “heads-up” thing with 0.5, at least on my puter.
Nice one @Wingnut!
Ok here’s my terrible, awful, hacky follow-up idea:
https://playground.babylonjs.com/#9KFTRW#1
What I’m doing here is creating an ArcFollowCamera that looks at a sphere. I’ve also added physics to the world created a physics imposter for the ground, ramp, and sphere. The ground and ramp have mass of zero because they don’t need to move or be affected by gravity, but the sphere has mass.
Then there are player controls to move the sphere around with w,a,s,d, AND the final straw is to zero out the angular velocity of the sphere’s physics imposter any time a key input is detected. That way the sphere doesn’t roll back down the ramp.
Finally, if you toggle the visibility of the sphere on and off, you end up with the net result of what I think you’re after…the camera climbing up the ramp.
Again this is COMPLETELY hacky and there are FAR better approaches out there.
One of the best player control examples I’ve seen was done by @syntheticmagus for the Babylon KartRacer demo.
Here’s the direct link to the two methods to check out.
This is far more advanced, and uses raycasts as detection for ground/ramp etc.
Hope this is helpful in some way!
1 Like