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…
- Remove all applyForce()/applyImpulse()/setLinearVelocity() that kept dragged mesh “hovering” at end of pointer. (all drag-requests removed, mesh is under normal physics control, again)
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.
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.