New Mouse Handling

[bagnell]

The mouse handling has been changed to be consistent across all scene modes:

Left button drag moves the camera over the surface.
Middle button drag rotates about a point on the surface.
Right button drag and wheel zoom in and out.

[pjcozzi]

General comments

• I like the new controls. I especially like that we can navigate pretty well without the keyboard.
• In Scene/CameraColumbusViewController, the updateReferenceFrame test fails.
• Is the bounce back in 2D based on screen-space? It appears view-dependent; when zoomed in close, the map can go fully off the canvas in the vertical direction. Would making the map start to bounce back once the extreme edge passed the center of the canvas work?
• What exactly does shift do in 3D now? We'll need the ability to look up, but the lack of constraint makes this feel strange.
• In Columbus view, sometimes the zoom speed is way too fast. Perhaps because I used shift to look up?

[pjcozzi]

Given that the rest of the code uses AnimationCollection, why break the abstraction here and go behind its back to Tween? Why not add something to AnimationCollection instead and use it here?

[pjcozzi]

Or just keep a flag and avoid the search.

[bagnell]

@pjcozzi Some answers to the questions in the general comments:

• The updateReferenceFrame test in CameraColumbusViewControllerSpec was replaced with correctPosition. Maybe you need a clean build or clear the browser cache?
• The bounce back in 2D is view dependent. It estimates the height of map so it doesn't need to know about the projection used. There is a property in the 2D controller that we multiply with the estimated height to get the max distance away from the camera it can be. @emackey and I thought the current value to be OK. It will probably be tweaked or made public in the future.
• The free look in 3D now rotates around the camera up vector. This was how it originally worked. You should try it zoomed out with the whole earth visible and then zoomed in. I agree it does feel strange when zoomed in, but we might change it to have different behaviors at different altitudes. Am I missing anything @emackey ?
• The free look was removed in Columbus View so I'm not sure what you mean in the comment about the zoom. Can you clarify? Also what do you think about the removal?

[pjcozzi]

• I had the old branch; the tests look good now.
• In 2D, the closer you zoom in, the worse the height estimate is. The map will seemingly never snap back in some cases. How do we estimate the height? Wouldn't it be simple to come up with something correct based on the map projection?
• The free look in 3D is nifty when zoomed out, but it definitively needs work when zoomed in. It doesn't have to be part of this pull request. Perhaps make an issue.
• I had the old branch, which still had free look in Columbus view. Right away it feels missing, especially for satellite orbits. What's involved in implementing it?

[bagnell]

The maximum y coordinate was being estimated by ellipsoid.getMinimumRadius() * Math.PI * 0.5. After talking with Deron, we decided this will never work. I'll change it to use the projection instead.

The only problem with the free look in Columbus view is staying in the new constraints. For example, we want the map to always be in view, but what if we use free look so that the view vector doesn't intersect the plane the map is on?

[emackey]

I think if they're using the shift key for free look, that means they're probably not a novice user and they almost certainly don't want to be constrained to only see the map. Have to turn off the constraints at that point, or find some way to permit them to do what they want. Remember it's not always about preventing them seeing a black screen at all costs. We have to allow them to explore a 3d volume of interest, the box extending from the map up to geo and beyond. As long as any portion of this box intersects the view volume, even if it's empty, it's allowed.

[pjcozzi]

When looking up in Columbus view, the map doesn't always have to be in view. What is the map anyway? What about when we have terrain? A peak could be in view even though the base plane is in not. As @emackey says, users may want to look up at objects in the sky, and not necessarily have any of the ground in view.

[bagnell]

@pjcozzi The last set of commits fix the problem in 2D and adds free look back to Columbus view.

[bagnell]

I changed the max latitude to pi/2. The reason it seems like the map is not in view is because the Bing imagery only extends to 85 degrees. If you change the tile provider to something that is defined past 85 degrees, like the SingleTileProvider in the Sandbox, you can see that the map is always visible.