Hi guys. Maybe I can help. Remember, Givo… that the “collisions system” you WERE working-with… is a special system, and not associated with physics engines at all. Physics engines are a whole different thing.
First, let’s look at this physics-active playground: https://www.babylonjs-playground.com/#15AFCG#39
The little gray box is called ibox, the green box is player, and the red/blue boxes are crates.
Ibox and player are connected by a physics “joint”. You can think of it as a semi-firm piece of rubber. Ibox is short for invisible-box… because it COULD/SHOULD be invisible… just like its joint (joints are ALWAYS invisible).
Try some arrow keys, which move the gray ibox. The joint sort of “drags-around” the green player. It is like a “buffer”. We need this buffer… because keypresses are VERY fast and powerful. If we were to move greenbox without this buffer, collided things could fly FAR AWAY, because a keypress-movement is powerful. By moving ibox instead, with a joint connected to player, we soften the impact, and keypresses can be used a-ok.
So, what you would want to do… is set ibox.parent = freeCamera. But #39 playground has an arcCamera. Let’s change that, and do the parenting.
The parent is set at line 114. Also, freecam was added at line 7, minZ setting at line 8, setTarget in line 10, player position removed in line 29, ibox position nulled-out at line 72, and joint connectedPivot set to 0,0,0 at line 88 (its a very very short joint)
Try to use your WASD keys to collide camera with a crate. Works good, huh? It might be wise/fun to adjust the size of green player box (and perhaps make it a sphere/sphereImpostor), as that size is the distance from camera to collided object. It is perfectly “legal” to use a sphereImpostor on a box, or vice-versa, too.
I got some “jitters” seen at the bottom of the crates… not sure why, yet.
Essentially, by parenting ibox to camera, and by using no-position on green player, and by using no length between joint mainPivot and connectedPivot… we have wrapped the camera in the green player box, and the ibox is essentially inside the player… and so is the camera. The greenbox, ibox, and camera, all move with each other… but the green box is “soft-connected” to the camera… via our rubber baby buffer joint.
If we were to make green playerbox… double-sided, we could see that the camera is inside the green box. We don’t care about that, just so it is not in-camera-view, and that physics IS working with WASD camera moves. YAY.
This will all take some time to “absorb”, for you, but it gives you some starting code, and it gives Deltakosh and other forum helpers… something to work/test-with.
I have never used this joint-between-moved-thing-and-collider method… for ANY purpose. Some experts in physics told me it was a good idea. They said it was a bad idea to move a physics-active object DIRECTLY (without a buffer joint)… because collided mesh would fly far away.
I built this playground… just to test the theory/idea.
Naturally, your mass, friction, restitution (rebound/bounce)… are all still very important and will need tweaking. Lighten the mass on the crates… for less tumble-tendency and more slide-tendency. Reduce frictions… you know… have some fun.
Ignore line 96 - collision: false (in #40 playground). That simply means the impostors/mesh on each end of this joint… cannot collide. It is likely that ibox is INSIDE-OF green player box, so it is best to avoid letting the two objects collide. Sometimes, when joint-shape collisions = true, and the two mesh overlap… one object will “spit-out” the other object… sending it into an orbit around Mars.
I hope this helps. Collisions enabled, checkCollisions, ellipsoids, cam apply gravity, all NOT NEEDED for physics engines, but as Deltakosh mentions, it is possible/useful to mix the two systems, as wanted.