Why have we arrived at the convention that rotations should be counter-clockwise then, even in engines where positive y is down?
Have we? Let us try CSS:
const box = document.getElementById("box");
let deg = timestamp/10;
box.style.transform = "rotate(" + deg + "deg)";
This is my solution, Google Earth like control with smooth animation (or not), when zoomed in it is user friendly and slows panning down.
The only thing I am not satisfied about is the quaternion slerp, at these defaults there won't be any sudden jumps but I would have loved to understand how to sub-interpolate quaternions so it works even when rotating ...
Here's an alternative approach: scale your mouse delta down if you zoom in and up if you zoom out. Now my math is a bit rusty, so I am not 100% sure, but I think if you just lerp between whatever speed that "looks" right at max and min zoom, you should achieve something that looks right all the way.
Turns out the solution to the fundamental problem is to avoid the complicated math and just use an appropriately-configured HingeJoint. When a player grabs an object, set node A to a kinematic body child node of that controller, and set node B to the object being grabbed. Set both paths to empty strings when they let go.
The actual result is a little wonky, ...
Waited more than I expected. I found a simple solution for this.
Vector3 mousePos = Camera.main.ScreenToWorldPoint(Input.mousePosition);
Vector2 direction = new Vector2(mousePos.x - transform.position.x, mousePos.y - transform.position.y
transform.up = direction;
It looks like your red points are rotated something like 60 degrees from your starting point, rather than the full 90 you expected. Let's investigate why that could be...
angle *= Math.PI / 180;
As we substitute in an initial value of 90 for angle, this translates to...
angle = angle * 3.141592653589 / 180.0
angle = 90 * 0.01745329251
angle = 1....