Inertia bounce interferes with camera flights in 2D

[mramato]

1. Start Cesium Viewer
2. Switch to 2D
3. Zoom out with the wheel to get a good camera "bounce" at max distance
4. Quickly enter a location in the Geocoder and fly there

The flight will happen but then you will get sent back to where you started. I can reproduce this easy enough, but it is timing dependent, so if you have problems let me know.

CC @bagnell

[emackey]

I discovered (in #1372) that multiple, overlapping camera flights are currently the norm. When a new camera flight begins, there's no good way to traverse the list of Tween animations and "weed out" only the old camera flight(s) that are still running. As a result, newly-added flights simply override the older flights, and if the older flight takes longer to complete, the newer one will lose control at its end.

Also, it's a bit of a UX sore spot that we lock the user out during the flight. Take a look at Google Earth's behavior: If you move the camera at all during a flight, the flight aborts right where you moved it. It doesn't jump to the end, nor lock the mouse, it just abandons the flight and lets you roam free wherever you were mid-flight. This is absolutely the correct behavior, and we need it.

Idea! We could have all flights keep track of the camera location, to detect any other forces acting on the camera. Each frame, a running camera tween looks at the camera's current location prior to moving it, and compares that to a variable remembering its location at the end of the previous tween update. If the camera isn't where it was left, then something else is controlling it, so the tween should abort itself and not write to the camera again. Brand-new flights might want to "stomp" the camera's location (as they do now) for about the first 3 updates or so to make sure they defeat all the old flight(s), but after that they should only write to the camera if the camera hasn't been moved by anything else. This could potentially fix a lot of flight issues.

[mramato]

@emackey There are plenty of valid use cases where you don't want flights to be interrupt-able, that being said, I don't have a problem with the flights we create as part of our core Ui having that capability (and maybe a viewModel option to control the behavior on each widget (HomeButton for example). It's also not a UX sore spot, for everyone I personally like the current behavior.

I consider this low-priority for now, as we all know, there are architecture/design issues that need to be addressed with animations before the above issue can be cleanly fixed.

[mramato]

I took a quick look at this and while the bug manifests differently, the end result is that bounce inertia will end up interfering with camera flights. I'm not sure there's an easy to fix this because the SceenSpaceCameraControlleris what knows about inertia while the Camera itself and the flights know nothing. We should probably take a hard look at camera architecture for Cesium 2.0

[bagnell]

There's no bounce back animation so I can't reproduce the original issue. Does it happen with inertia as well?

[hpinkos]

@mramato I can't reproduce this. Can this be closed?

[mramato]

Looks like we got rid of the inertial bouncing at some point (probably when we added infinite 2D) either way I can no longer reproduce this either.