https://www.babylonjs-playground.com/#7PZ7QH#15
Goofing around with using box1 (blue) as a below-the-floor “keel?” and I used joint1 lockJoint as a connector between red sphere1 and it. Red sphere1 is set very heavy. It is also set with high friction, but we all know that friction doesn’t have much affect on low-surface-contact spheres.
Line 133 sets sphere1 connect point at bottom of sphere1 (which has been up-scaled on Y to create the classic Weeble “egg shape”. You can drag player greenbox against the red weeble (sphere1) and it gets a little “pendulum” activity happening.
Line 36 attempt to lower the physics center-of-gravity… has been removed. The thru-floor lockjoint down to the fulcrum-weight… does that “CG” lowering, now. But, the pendulum swings SO SLOW… erf. I wonder what its problem is. May be problem with mass settings on sphere1 and box1 impostors… testing.
Hey @Arte … did you see the NEWEST post wanting physics-active dragBehavior? Drag collision effect That guy/gal REALLY needs physics “snap”, eh?
That’s… what? Three requests for physics-active drag, in the last month/2? Amazing. Your greenBox “ghost” is working sort-of ok for dragging a p-mesh (although it could use a fixedRotation on its “y” rot).
But physics drag-to-snap… that’s going to be a serious challenge, if possible at all. I suspect that it would require turning OFF all physics during the drag’n’drop (to a snapped position), and then re-activating all physics, and hopefully… all p-bodies will remain isSleeping after the re-activation. Otherwise, mesh will move/fly-away upon re-activation.
And WHAT IS a physics engine de-activate? According to my earlier theories, setMass(0) on every scene-active impostor… will make all bodies become static (frozen in place)… but we know that when ground was set mass=0 as it is now… NO collide events are reported to us (even though the floor/staticBody IS acting like a good “wall”… keeping other p-mesh from falling thru it).
SO, even if we setMass(0) on every physics-active mesh (p-mesh) except green player’s ghost, the physics engine might not help us to KNOW when a collide (against a 0-mass static) has happened. 0-mass static pb’s (such as our floor)… don’t seem to “register”/report onCollides. (Needs more testing.)
SO… we go back to standard non-physics “snap” while dragging, and that means… working exclusively with boundingBox and its extends/extendsWorld values… to accomplish the snap-positioning (and rotation-snapping, too).
Then, as soon as user is happy with dragging/snap, they lift the mouse button, and we re-activate physics on the other/all mesh… and hope that shit doesn’t go flying. 
I better get another cup of coffee. These thoughts are “multi-cups-of-coffee” -level… brain tumor-causing. heh. Another test PG - #16… adds line 175 to prevent violent spinning… when dragging-around green player box. Exciting stuff.
Let’s invite @lp920133349 to share our experimental physics-drag playgrounds. Physics-active dragging is certainly possible, as @Arte has proven. But… physics-active dragging WITH POSITION AND ROTATION “SNAP” - that’s brain tumor land.
What might be fun… is to wire the dragBehavior… so that you can release dragged mesh… while it is moving. Essentially, this would be “throw a p-mesh”. We already have ice hockey, yes? Green box drag-player is hockey stick, red box is puck. 
But… “throwing” the greenBox player… by detaching it from ghost WHILE still being dragged… that’d be fun… and it would be the start of “slide-it-into-snapped-position”… somehow. Sort of like Curling Simulator 1.0 but not really. heh. Currently, greenPlayer box has no impostor, so it won’t slide anywhere, if ghost were to throw it. So, we need to throw the ghost… too.
if (dragEnd while pointer.isMoving) {
dragBehavior.unGrip(dragBehavior.grippedMesh.findAndRemove("ghost"));
}