The box doesn’t fit inside the container in the example, or there are multiple boxes，how can I fix it?
Here is PG https://www.babylonjs-playground.com/#32M3IH#5
I used the physics engine for the first time, and I have some questions to ask.
Question
Thanks in advance.
Hi J. Wingy experiments with PG #6.
I turn-OFF physics on top of container line 190.
I changed to ArcRotateCam line 7+
I changed to SixDofDragBehavior() in line 96 (camera viewing angle NOW important for dragging UP.)
Things are acting differently, now. I am still learning/testing, too. You are rare person to try dragging physics-active mesh. Perhaps sometimes physics engine “mesh overlap-avoidance system” will fight-against drag movement. The “jitter” you see in your scene… is the overlap avoidance system… trying to eliminate an overlap. It is a fight between two or more collisions.
Perhaps, you will need to “watch” (inside renderLoop) the 5 active physicsImpostors of container… looking for collision-with isBeingDragged mesh. If there IS a collision with ANY of 6 sides of dragged mesh… against any of 4-sides and bottom of container, then drag on that axis/direction… must stop.
Your container is made from 6 planes. You may decide later… that each of the boxes you put inside the container… should also be made from 6 planes. Not sure.
In brief, dragBehavior must “yield” to physics collision. Perhaps drag is a REQUEST, allowed ONLY if physics engine says OK. Drag must get permission from physics engine/container… before drag-move is allowed. This could be difficult.
One idea… heavily modify dragBehavior system… to use physics-plugin-based applyForce()/applyImpulse()… to drag the mesh. This would make mesh-dragging… a “physics request” and the mesh would automatically stop moving when it collided with container walls.
I think you would be the FIRST BJS USER EVER… to try changing dragBehavior to physicsDragBehavior. You will be a hero/super-star… but it will be hard work. Dragged mesh will sort-of “hover” at end of drag pointer, using very precise applyForce/applyImpulse values to stay there (“smart thrusters” on the dragged mesh?). This will be especially difficult when dragging on Y-axis, where object mass vs. gravity vs. pointer-lift… are battling each other.
When drag-button is lifted (onPointerUp), you will need to…
Yuh, yuh, yuh, a physics-honoring dragBehavior system… NICE! Making dragged mesh “hover” nicely at end of drag pointer… LOTS of work. Lots of little setLinearVelocity() calls… nearly continuous when fighting with mass/gravity (y-axis drag). Essentially, you will be building an “auto-pilot” system for the dragged mesh physicsImpostor… to TRY to stay-with the drag pointer. Sort of “Do your best to stay with pointer, but container walls and ground/floor are the boss over pointer-to-mesh auto-pilot” - system.
Just like airplane auto-pilot. Physics inertia/forces are boss… until plane hits building or ground. Then building/ground becomes boss. 
https://www.babylonjs-playground.com/#15AFCG#48 This playground might be interesting. Objective… “physics-move” the big green box. ARROW keys and PageUp/Down buttons are active.
We will be moving the little gray ibox with dragBehavior-like non-physics FORCING. BUT… there is a physics lockJoint connected between little gray ibox… and big green box. BECAUSE of that joint… the FORCING move on gray ibox… becomes a physics REQUEST to big green box.
Start testing by using a single PageUp keypress… to lift the gray ibox, which lifts the invisible lockJoint, which lifts the green box. This makes the green box sort of “hanging on a physics rope”. Now move it around withthe arrow keys, colliding things. Feel free to add more mass to red and blue boxes, and reduce mass from green box… have some fun.
ibox is an abbreviation for “invisible box”… because it will likely be made invisible for end project.
YOU… could attach dragBehavior to invisible ibox (and probably make lockJoint shorter by lowering ibox closer to green box.)
The ibox moves could be called “hard moves” because it is “hard” keypress… which “HARD-forces” it to move (translate some distance). The green box moves could be called “soft moves” because they are NOT keypress-forced. They are instead… “joint-requested”. LockJoints have easy .enabled/.disabled properties for attaching to mesh. Most times, when you need to drag a DIFFERENT mesh, you will destroy old lockJoint and make new one between ibox and the new needs-to-be-dragged mesh.
LockJoints have no mainAxis and connectedAxis, and only have mainPivot and connectedPivot (which is WHERE upon the attached mesh… to put the connection… which, in your case… is often 0,0,0 center of mesh). That is likely the default placement, so you might not even need to set mainPivot and connectedPivot on a lock joint. Just position the ibox in the place you want it, and make the joint between ibox impostor, and the about-to-be-dragged mesh impostor.
Rotation drag… hmm. Rotating the green box around Y-axis… should be easy. I think rotating the ibox around Y-axis… will also rotate green box around Y-axis. Let’s try it.
https://www.babylonjs-playground.com/#15AFCG#49
Added lines 135-142… left and right brackets [ ].
Works. Try single pageUp and then try [ and ]. Again, these are “requests” for green box to move. Put heavy mass on blue and red box, then use arrow keys to put green box against red/blue, then try a rotate [ ] keys. The spin might not work, because physics refused the request… too much mass blocking the spin.
This is the behavior you want… inside the container, too. Don’t allow user to spin box if container says “no room to spin”. Make user lift box OUT-OF container, then spin, then put back into container.
Spinning green box around X or Z axis… could be trouble. Ibox would need to be positioned BESIDE the green box… and THEN lockJoint added. Then spin ibox, and if request allowed, green box will spin, too.
SO much talking from Wingnut, eh? Sorry. Perhaps coding new PhysicsDragBehavior system… is still the wisest thing to do. hmm.
I’m not very helpful, am I? Sorry. PhysicsDragBehavior system seems like a large project. We might need to gather a team of experts to help with your cool idea. hmm. Maybe others will have more/better ideas. Perhaps forum will be slow during holidays.
First, thank you very much for trying!
This is a packing-optimized project, want to use mouse to drag and drop cubes. This is my first time using a web 3d component, I can’t imagine how complicated it is.
So far at least, it seems that using a physics engine is not a good choice.
Thanks again for your reply.
Yeah, that is strange. We need to RUN twice to make scene render. hmm. Not sure why, yet.
Ping @Cedric our physix master (He ll be back on Monday)
Hi @jas0n
There are instability because collisions happens and the system can’t properly determine a solution with stability.
To eliminate the issues, you can start with a stable initialization Like I did in this PG:
https://www.babylonjs-playground.com/#32M3IH#10
Also, see that I set the cube position (line 83) before the impostor creation. If you change the cube position after the impostor init, you implicitly add a force to the object, and then it collides, more collisions, mor instability and so on.
I changed the box dimension so it can fit in the container. No better solution than that, I’m afraid.
Hi @Cedric
Thank you for your reply!
Because you can drag with the mouse, collision still occurs. I just want to make an effect similar to pushing a box, Is it better not to use a physics engine?
I guess you want to do something like drawers. Maybe you can try with a slider joint between the drawer and a static body for the furniture.
Not quite like a drawer, what I want to achieve is to put many different types of packaging into one container.
I’d try with hotspots. When a box you move gets inside the hotspot radius and you release le mouse button, then interpolate/rotate the box to the hotspot position.
This may not be what I want, but thank you for your reply
Hi @Wingnut
Bother again, I give up the physics engine, but the mouse pick up effect is not very good.
Can I replace it with PointerDragBehavior? 
This is new PG https://www.babylonjs-playground.com/#32M3IH#14
You can only move the mesh out from the front, and return to the previous position if it intersects with other after moving.
Hi @Cedric 
the effect I want to achieve, it would be better if there is a physics engine
Thank you all!
ok! Give me some minutes to make a playground test
Hey, that works pretty well. Nice work!
Great question. You want a dragBehavior… that uses line 131 moveWithCollisions(someDirectionAndMagnitude)… so then you can turn-off onPointerMove and ONLY use the dragBehavior for moving. Yep… good idea.
You got a game plan, doncha? dragBehavior.moveWithCollisions? I’m so curious… I pee’d a little. 
@Wingnut My bad, I answered in the wrong topic. Will take time to try somehing later today. But no, I have no plan yet.
I did a “restatement” of the wanted goal… in my last post… to try to make sure I understand jasOn wishes. At first, I didn’t see the onPointerMove installed, and I thought JasOn was ALREADY using dragBehavior with ellipsoid colliders system (.checkCollisions = true system).
But I think onPointMove is active, and dragBehavior is de-activated… in his PG. So, hmm. I don’t know if a .moveWithCollisions-like thing CAN be added to dragBehavior mover system. And even if it CAN… we have had troubles with colliding-with the top and bottom of .ellipsoids… sometimes colliding too high or too low. I hope that old issue doesn’t cause trouble.
Also, .ellipsoids “scrub-off”… so dragging a taller mesh… against a very short mesh… could make spherical/ellipsoid collider “climb over” or “dive under” or “slide past on the side” (not a clean dead-stop collision), because of differences in ellipsoid sizes. Dependent upon Engine.CollisionsEpsilon setting. (scrub-off tendency).
Weird stuff. Thx for helping. All non-physics engine stuff.
I know it’s weird stuff 
You’re very nice!
One more problem, when I try to rotate the mesh, the ellipsoids stay the same, there are some strange problems with collision detection.
Oh goody. hehe.
Thx for kind words. This is a good challenge… hard thinking… fun and painful at the same time.
JasOn… a long time ago, I made a function called .showEllipsoid() and another called setEllipsoidPerBoundingBox(). What it did… is create a wireframe sphere… exactly the size of mesh.ellipsoid (and honoring .ellipsoidOffset if one was set)… and parent that sphere to the mesh.
It is a reasonably handy “watch the ellipsoid” system.
There, two cylinders, ellipsoids showing, positioned ready for vertical moveWithCollisions testing. wasdqe and shifted WASDQE keys active… but for vertical tests like that one… mostly qe and shifted QE keys. And the keypresses seem to be broken right now. Not sure what happened… PG went stale or something. Old code, dumber Wingnut.
The wireframe ellipsoid is stored in mesh.ellipsoidMesh (a property added by Wingnut).
Just some tools, if you want to try them. That whole #WWCK0 playground SERIES… is full of various ellipsoid collision test playgrounds… some mouse-dragging, some keypress-moving… NONE using dragBehavior, though.
Why this is, similar playgrounds, I checked a lot, I’m curious about this.
I will read it carefully “watch the ellipsoid” system. 
