Here’s a cool little tutorial… likely authored by Playground-Based Tutorial (PBT) inventor @JohnK.
Our playground app has a database of serious size. An in-code search for some pertinent keywords… returns plenty of results to tour/study.
Similar searches for ‘camera.ellipsoid’ may produce good results, too.
I don’t have much more to suggest? Sorry. I’ll share what little knowledge I have, though:
FreeCamera or UniversalCamera is likely the camera you want to use… for “first-person-shooter”-type view.
- Do you want to steer/turn player left/right… with mouse-drag, or with keyboard keys, or both?
- Do you want to walk player forward/backward… with mouse-drag, or keyboard, or both?
- Do you want the allow player/camera to turn/tilt head/view… WITHOUT turning body?
Sometimes, these answers will determine if player is ONLY a camera, or is it a camera that has been parented to an invisible mesh “body”.
Both the invisible mesh AND the camera have .checkCollisions properties. No issues there.
FreeCamera already does move-with-collisions, using its arrow keys.
FreeCam Note1: FreeCameras can SOMETIMES climb-over low-height obstacles, due-to camera colliders being spherical-shaped. Sometimes camera-moving is not powerful/fast enough… to climb-over a low-height obstacle, and continued “pushing forward” can make camera jiggle. This is because the camera attempts to climb-over the obstacle, but camera.applyGravity tries to pull camera back-to the ground.
FreeCam Note2: FreeCameras can also collide with something narrow, like a pole. Continued “pushing forward” will often make the camera “scrub-off” to one side of the pole (push past the collided mesh). It is like pushing two bowling balls together. Keep pushing, and eventually, one ball will go-around the other.
If walls/obstacles are somewhat tall, freeCameras will not “climb-over”. But freeCameras WILL start sliding sideways if they hit a wall at a slight angle (when continuing forward movement after collision occurs). The amount of angle required for “scrub-off” (sliding along collided wall or around narrow mesh) is adjustable. See engine.collisionsEpsilon.
For invisible mesh with camera attached... you will need to use invisibleMesh.moveWithCollisions() function (you can search playgrounds for THAT, too). Moving mesh with moveWithCollisions... definitely has a problem with getting "stuck in collision". We have done SOME thinking about "predicting collisions"... to try to avoid "stuck". Using slower movement speeds... might help the problem, too.
I always liked this PG: https://www.babylonjs-playground.com/#LYCSQ#256
It is a programmer-made, custom following-camera, not a first-person camera. Still, I like way it collides with walls… never getting “stuck” in collision state (which happens sometimes). It might be worth some study.
Please be patient and stay tuned for more comments/playgrounds.