You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Using middle-mouse-drag to rotate the camera over terrain feels awkward and is difficult to navigate. I believe the current behavior is to fire a ray through the middle of the screen and hit the ellipsoid, and rotate around the ellipsoid intersection point.
Note that I'm NOT suggesting we fire the ray through the mouse location, as GE does (maybe we should add that option, but that's separate from this particular issue).
This issue relates to the ray that was fired (through the viewport center) hitting the ellipsoid instead of hitting the terrain. Really it needs to hit the terrain, if enabled, and rotate there. If it "misses" the terrain, we can fall back on the normal "closest-point-on-the-ellipsoid" trick.
Implementing this may require the "hit" point to be remembered once the mouse is pressed down. Otherwise, a mountain might move in between the viewer and the current center of rotation, and "steal" the center of rotation. Remembering this point is actually good for a number of reasons, such as preventing the rolling-towards-the-camera effect, and will make it easier to implement mouse-point-rotation later if someone requests it.
The text was updated successfully, but these errors were encountered:
Also, although this issue is titled "rotating", it affects panning as well. Cesium makes use of the concept of grabbing a specific point on the globe and moving it. When you "grab" a mountain, you miss the mountain and end up grabbing a point on the ellipsoid behind and below the mountain. It makes the camera feel clumsy and the terrain feel fake.
Using middle-mouse-drag to rotate the camera over terrain feels awkward and is difficult to navigate. I believe the current behavior is to fire a ray through the middle of the screen and hit the ellipsoid, and rotate around the ellipsoid intersection point.
Note that I'm NOT suggesting we fire the ray through the mouse location, as GE does (maybe we should add that option, but that's separate from this particular issue).
This issue relates to the ray that was fired (through the viewport center) hitting the ellipsoid instead of hitting the terrain. Really it needs to hit the terrain, if enabled, and rotate there. If it "misses" the terrain, we can fall back on the normal "closest-point-on-the-ellipsoid" trick.
Implementing this may require the "hit" point to be remembered once the mouse is pressed down. Otherwise, a mountain might move in between the viewer and the current center of rotation, and "steal" the center of rotation. Remembering this point is actually good for a number of reasons, such as preventing the rolling-towards-the-camera effect, and will make it easier to implement mouse-point-rotation later if someone requests it.
The text was updated successfully, but these errors were encountered: