Closed noncom closed 5 years ago
I think the problem is unfortunately more complicated than that. Dragging is done in world space... so basing dragging on the world space coordinates is correct. The issue is that the results are not applied in a local-space friendly way.
For example, I think if you rotate your node then things will behave very strangely. Essentially, DragHandler is not written to properly handle children where local and world translation are not the same. It could be... but it's more complicated than just basing the starting position on local space. At least I think. It's possible some other magic makes it work if node is rotated but I don't think so.
Note: I'm going to leave this issue open because I would like DragHandler to be able to handle these child cases.
Well, my guess would be what about something along these lines?:
When the mouse is pressed:
When moving the mouse, dragging the element:
When releasing the mouse:
That should work with rotated parents too? The whole idea is to have an intermediate entity that can handle the projections easily.
I don't think it requires all that. I haven't tested it or anything but I believe it's as simple as: -continue calculating dragging in world space as before -instead of calling spatial.setLocalTranslation() with the world space coordinate, convert that world space coordinate to local space with spatial.getParent().worldToLocal()
Fix committed and confirmed it works in the demo. Closing this issue.
There is a bug in the
DragHandler
class. Theline in
startDrag()
should probably instead bebecause everywhere else the handler is working with the local translation and getting the world translation here introduces an abnormal initial offset on drag start if the spatial is a child of some other spatial and its relative location is not 0, 0, 0.
It is easy to demonstrate this behavior by modifying the
com.simsilica.lemur.demo.BasicDemo
class: replace the linein
simpleInitApp()
withand try to drag the testPanel.