Improve camera zoom

[pjcozzi]

Currently, to zoom to a location, we have to go back and forth several times between zooming with the right-mouse button, and panning with the left-mouse button. We should be able to do this with much less mouse motion.

This isn't a short-term priority, but we should keep it in mind as we continue to improve the camera.

[netanelgilad]

Hey guys,
Any plans for this? Would improve the user experience much in our app...

[pjcozzi]

No progress yet, but we are going to do some camera improvements for KML (#2179), and given the number of GE plugin users that are moving to Cesium, I think this feature is going to become increasingly important.

What kind of app are you working on? Do you have a link?

[mykels]

I most certainly agree with @netanelgilad, this is a necessary feature. We can not provide any details on our project, but I can say that our clients use the zoom feature extensively to navigate from location to location.

I believe this should be a short-term priority as it is, as I understand, a pretty simple feature to implement. We will follow the subject closely to see if there are any updates on the issue.

[dical99]

Just wanted to add my vote in for this feature as well - our users have also been requesting it.

[mramato]

There's a discussion about this (and some links to various implementations) in this forum thread. We're happy to take pull requests for this into core Cesium.

[scothis]

We implemented a basic zoom to mouse feature in user land. Happy to wrap it into a PR if people like.

https://gist.github.com/scothis/c9f2695f03380ca5dd96

[netanelgilad]

@scothis This seems like exactly what we need. Would love to see you PR it and have it integrated into cesium.
Thanks.

[gberaudo]

@scothis, maybe you could take the terrain into account and instead of using the height of the camera, use the distance from the camera to the intersection of the directionToZoom ray with the terrain.

[rap2363]

@gberaudo I agree that the distance being scaled by the distance to the projected point-to-zoom is a stronger metric, but what if you're in a 2.5D view and try zooming directly into space?

[WarpDrive]

If the mouse ray (=camera origin & goes through pointer) doesn't intersect Earth it could instead scale using the camera's nadir vector intersect distance (nadir vector always intersects the Earth.) I've found zooming into open space to be quite useful (toward and away.)

Zooming along the mouse ray is very easy to implement, however it introduces a non-zero roll in the local ENU frame. Without a 3Dmouse roll is difficult to deal with. Shift left-click looking is not mentioned in the top right navigation help button probably for the same reason: the camera relative pitch yaw can introduce non-zero local ENU roll which can be tricky to undo with a 2Dmouse.

To fix the non-zero roll while at the same time keeping the pointer over the same spot on Earth what can be done is spin the camera around the mouse ray axis after zooming so that roll is zero again. The trick is figuring out the rotation angle needed to accomplish this as it's an arbitrary vector (not direction, right, nor up.) Anyone know of a good algorithm to determine the required rotation angle? Don't want to rotate around any other vector to undo roll as then the pointer won't be over the same spot anymore.

[WarpDrive]

Until an algorithm is discovered to determine a one time rotation around mouse ray, perhaps for the mean time a brute force method could be used.

The higher the dot product between the mouse ray and camera.direction the more roll action it will yield to the point of being 100% roll action (=camera.dirction.) At first rotate (0 minus current roll) and see how close that gets to 0 roll. Lets say you were at roll -40deg and you rotated +40 degrees around mouse ray and that put you at -5deg roll (35deg / 40deg = 0.875 deg roll per 1 deg rotate.) So to finish it off you rotate 4.375deg = 5 * 0.875deg. If roll still isn't exactly zero just finish it off by rotating around camera.direction.

ENU heading and pitch will alter a bit as you zoom, but that can't be avoided if you zoom in a straight line while keeping the same point under the pointer. It might be possible to zoom along a curved path while keeping the same point under the pointer and keeping a constant ENU HPR orientation, but the calculations for that might end up being even more difficult to figure out.

[WarpDrive]

How to figure out how much to rotate around mouse ray

Local up is camera.up in terms of the ENU reference frame. When you rotate camera around an arbitrary mouse ray, local up goes around circle A in 3D space. Local up.z is highest at roll 0 (if tilt it positive.) So the key is to figure out a way to determine the highest point of circle A in 3D space. That point is where up needs to point to and you already know the mouse ray direction, and if you know where 2 vectors point to from camera center you then can determine it's complete orientation. (it is already known how mouse ray and camera.up are situated relative to the camera's cardinal directions.)

[JayBlanchard-FugroSDES]

@scothis We're finding that this doesn't work on either 3D or 2D maps and throws no errors.

[pjcozzi]

This was added in #2810. It will be in Cesium 1.11 on July 1.