When looking at the examples, the Collisions example has a bug. the scene has gravity (as seen on line 29) and it only affects the camera when moving. Here is a playground CLICK ME
I modified it to have 0 inertia for the camera, so when you aren’t pressing the keys the camera isn’t moving. I also added pointer lock, WASD to move, and slowed down the movement.
Any possible fixes?
Hello not sure to see where the problem is 
If I go on the edge, I will fall. So can you tell us what to do to reproduce the issue you are facing?
Hi guys. Perhaps you need magic line 17? (see playground scene below)
It makes camera start falling… when scene is-ready.
https://www.babylonjs-playground.com/#U8MEB0#22
Maybe I am off-topic. 
Hey, that works!
I was looking at the examples and I didn’t know if that was a fluke or something that was intended.
Thanks Wingnut!
My pleasure… good to hear you are rolling. Welcome to the forum, too.
Technically/Actually, gravity only affects the camera after first-move. @Deltakosh is the one who taught me about this line 17 feature, but he didn’t quite understand your problem. i didn’t understand either, but I guessed. I have used line 17 on 3 personal projects, and have passed-it-on to other users… about 5 times. It is my friend. 
I think camera gravity and checkCollisions things… are part of a “special” collisions system designed-for “first-person shooter” games. It is primarily-for freeCamera-to-mesh collisions, but SOME have tried using it for mesh-to-mesh collisions, via the mesh.moveWithCollisions() feature.
A little hint… avoid camera-colliding with low-height things. If your camera hits a low-height obstacle, and you keep pushing “w” more… the camera will try to climb-over the low-height obstacle (due-to the ellipsoid shape of the invisible colliders), but gravity will keep pulling the camera back to the ground. This makes the camera stutter/jiggle with continued/held-down “w” key-pressings.
A collisions-active freeCamera can/will also “scrub-off” the sides of round-sided things… such as cylinders/poles. This is made this way… so that if camera hits a wall at an angle… and user keeps moving forward, the camera will slide-along the wall. The amount of camera-mesh collision “offset-angle” needed… to make a held-“w” camera slide-along/scrub-off an obstacle… is user-adjustable.
engine.collisionsEpsilon = 0.001;
This setting also affects “climb-over”, so if you MUST have low-height obstacles, you might wish to adjust that value… to avoid the freeCamera climb-VS-gravity jitters… mentioned earlier.
Also, if you see the obstacle start disappearing when camera is REAL CLOSE, set camera.minZ to a low number… such as .01 or smaller.
Do you know how to mark someone’s reply as… “the solve”? If you do that, it helps the forum helpers.
Party on! Winona MN, eh? That’s near “apple country”, isn’t it? Love that hilly area! I use-to climb similar St. Croix River bluffs around Taylors Falls - too fun. I lived in Mpls for… 18 years. The band I played bass-in… use to play in St. Charles, sometimes. Good times. You guys are PARTY ANIMALS!
I’ve never heard that the “apple country” people are party animals, but I guess I could of figured it out with Winona’s “Mid West Music Fest” and “Ashley’s for the Arts” that takes place not too far from here. I’m not a party animal, but I am known as the family hermit. My computer is in my family’s basement and I like to stay down there a lot. My friends and I have been known to spend a couple hours on Discord at a time. Have you seen my latest post?