Open vorg opened 5 years ago
I think i nailed it! Blue click arrow is (target) longitude and dark blue arrow is current latitude. Yellow is slerp angle. See when yellow is > 180deg slerp chooses shortest (red) path instead which is incorrect and the green position arc starts to zig zag backwards… so the problem is slerp but triggered by easing drag.
Possible solutions:
- get rid of quaternions and switch to only lat/lon (downsides = ?)
We'll still have the same problem of lerping to the closest target
- replace easing with inertia (1:1 tracking while dragging + "slide" on mouse up)
Probably the best alternative to lerping
- limit delta longitude to < 180deg
We'll need to track the dragging direction then
- limit dx (acceleration)
Will need to be relative to the currentLon and lon properties somehow
I’ve just realised that current code doesn’t use quaternions. Wouldn’t the fix be then to extend interpolateAngle with direction?
interpolateAngle( (toRadians(this.currentLon) + 2 Math.PI) % (2 Math.PI), (toRadians(this.lon) + 2 Math.PI) % (2 Math.PI), this.easing, dx //positive for cw? )
What if a sudden change in direction happen and the difference is > 180?
Dragging orbiter fast e.g. from right to left makes camera jump backwards before continuing rotation CW.