Not much animating (of any physics active mesh that the camera is parented/linked-to). If you have floor friction high, restitution low, and fixed-rotation (on the camera’s physics-active mesh)… then the camera will just sort of stop when it hits a wall… no bounce, no slide, no turn. Cameras are not a mesh, and physics engines only work-on mesh. SO… that is why a mesh needs to attach to the camera… somehow… in order to have a physics-active camera.
But it is not easy to nav a camera that has been parented/linked to a physics-active mesh (maybe invisible). It takes things like setLinearVelocity and setAngularVelocity on the physics object… via cursor or WASD keys… and the camera simply follows-along. A user named @givo was recently working-with navigating a physics object with a camera attached. You might wish to see what posts/playgrounds he has made. Not many try navigating a camera with physics.
More brief… in your case (rudimentary physics) we ONLY let the physics engine do the collision-testing on a single-mesh room… via the meshImpostor (which sort of accepts ANY shaped mesh). No bounce-off (restitution), no sliding (friction). Minimum/no animating… just stopping things at the walls, mostly.
With physics engines, .moveWithCollision is not used… nor is .checkCollisions = true, nor are ellipsoids. Different system. (It takes a while to get used-to the differences in the systems).
Cameras are not mesh, so when using physics engines, the camera SHOULD BE parented to a physics-active mesh. But this makes the mesh… THE BOSS of the camera… so we must use physics commands to turn/move the camera… not easy.
The only real reason why I tested a physics engine for in-room collisions… is to allow you to make the room/building out of a single mesh… without having to use many wall-sections and lots of .checkCollisions = true (used for non-physics engine colliding and freeCams - FPS Shooter games).
.moveWithCollisions is really a “barely legal” method… as it is moving mesh. The BJS built-in collision system was initially designed to ONLY use a freeCamera and its .ellipsoid… colliding with stationary mesh obstacles and THEIR ellipsoids. That system was never meant to .moveWithCollisions MESH… but some mad-scientist inventor added .moveWithCollisions… to move mesh into other mesh. I believe .moveWithCollisions can cause “stuck in collision” situations. Again, NONE of that stuff… is involved in physics engines. They are a different system. It’s easy to get the two systems confused/overlapped.
Umm… let’s see… Oimo doesn’t have a meshImpostor, as far as I know. Basic shapes only, for Oimo.
SOME nav-with-physics-engine was done here… https://www.babylonjs-playground.com/#IFN77Q#13
Also check #14, #17, #23… all use WASD keys… and no camera turning, yet. Only linear movements, so far. @givo MIGHT have stayed with this playground series… for his advanced tests… so check #30, #40, #50, etc. I know he advanced the project somewhat. These playgrounds are just “a taste” of what physics-engine “navigating” is like. Floor friction is everything, along with angularDamping and linearDamping .
Interesting non-physics-engine PG: https://www.babylonjs-playground.com/#LYCSQ#250
I might have more comments after I read your post a bit better. Good research you are doing!