I was messing around. and wanted to push around a cube. The collisions demo(https://playground.babylonjs.com/#U8MEB0#0) and tried to add cannon.js physics to the box and push it. It didn’t work. Here is the playground: https://playground.babylonjs.com/#U8MEB0#23
How HARD is it to just PUSH a BOX!?!?!?!?
If anyone knows, all help is welcome.
Givo
The thing is that you (the camera) are not a physic object so you apply no force on the physic objects 
Collisions is a mechanism for the camera to move around (ala quake) where physic is interaction between bodies.
But you can mix both by attaching a sphere (or a box) with an impostor to your camera
Oh. Thanks. But I have another issue. On my test website giv0.gitlab.io/fpsg I have some nice crates. If I apply physics to said crates, the "game won’t work! Any way to help?
ctrl+u to see code. the game code is in the js file.
Controls:
WASD to move
Mouse to look
Shift to move faster (or “sprint”)
C to crouch (makes you move slower)
F to toggle on/off freecam
If you fall through the test terrain at first, reload the page.
giv0.gitlab.io/fpsg/probs/phys.html is where I give a crate physics.
the js file is called crate-house because I’m gonna make a warehouse with some CRATES!
You can also see the “arm.”
I would prefer having a repro in the playground where we can update code easily
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.
https://www.babylonjs-playground.com/#15AFCG#40
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.
Sure, no problem. Here: https://playground.babylonjs.com/#UZ23UH#120
The only problem is that the crates can’t load.
thanks, that helps. Now all I need is for my crates to have physics so they can be pushed around.