Hi,
Not sure if this is a bug.
onDragObservable resets pivotPoint???
@Arte pointerDragBehavior only supports the latest version of pivots (eg. calling setPivot with the second parameter not specified or true) see https://playground.babylonjs.com/#UM0LX5#2
1 Like
Interesting! No more getCurrentGroundPosition() functions? hmm, I’m going to miss that. (j/k) (part of the old drag’n’drop playground demo)
Wouldn’t it be cool… if the drag behavior allowed alt-drag, shift-drag, or control-drag (progger choice)… to position the mesh up/down on the Y-axis, if wanted? hmm.
And wouldn’t it be cool… if the programmer could set the drag behavior… to position, rotation, or scale?
Ain’t it a shame that mobile device makers never added control, shift, or alt keys… to their devices? Not yet. They missed the boat. They COULD have had FOUR TIMES the currently-allowed “gestures”, but nooooo.
(alt-swipe, control-pinch, shift-spread, etc)
Four different “flavors” of a GUI button-press, too. (adding control-touch, shift-touch, alt-touch)
Ideally, the alt/shift/control “buckies” would be pressed by the hand the holds the device case, of course. They would likely be mounted along the edge of the device’s case… possibly called “squeeze switches”. 
I noticed that. But if setPivot have second param as option, that mean pointerDragBehavior has to be the same. To keep consistency.
@Wingnut We need to adapt to changes to be able to survive 
1 Like
Do you have a scenario that requires support for this, that cannot be easily modified to use the newer pivot mode or use a parent mesh?
That second parameter was added to provide a way to not break older apps, it is recommended to not use it anymore. Supporting it might be tricky and might make apis that need to support it more complex by making them have additional flags and more work to test.
I’m already using parent mesh
I solved my problem by adding:
drag.onDragEndObservable( reset pivot point )
You don’t have to change anything.
Thank you for your support.
1 Like