Closed azrogers closed 7 months ago
This approach is an approximation to the geodesic (cough jargon cough), and the approximation has the problem that the velocity over the ellipsoid isn't constant as one changes the angle between the start and end vectors. If this is going into cesium-native, I wonder if it would be better to have real solution to the geodesic problem? Either follow the methods in the wikipedia page and the linked reference https://doi.org/10.1007%2Fs00190-012-0578-z, or punt and use libPROJ.
I'm not aware of any requirement for constant velocity for Unreal or Unity. The "fly to" animations have other aesthetic aspects, like height and progress curves, that make their use less than scientific.
I do like the simplicity and performance of this class. It's at least a good place to start if you're starting from scratch.
@kring I've updated the PR based on your feedback, and implemented the geocentric calculation you recommended. As far as I can tell I still think the CesiumJS solution is just lerping between cartographic coordinates - see here. I think our solution is probably more accurate.
Required for CesiumGS/cesium-unity#395.
Both our Unreal and Unity implementations implement a fly-to class that animates a camera movement from one position on the globe to another. For one, the math between these two implementations is identical, and it would be nice to share code between the two implementations. But more importantly, Unity lacks double-precision implementations of the math functions we need to calculate this path, and trying to do the math with floats results in precision errors that cause jumping at the end of the flight (see CesiumGS/cesium-unity#390). By moving this implementation to the C++ side, we can use glm's double-precision math to solve these issues, while also eventually allowing us to unify the Unreal and Unity implementations.
This is implemented as a class that can take a normalized value representing position along the line and return ECEF coordinates for that point. This allows the path to be sampled continuously for each frame, while also allowing each implementation to choose how that normalized value is computed. This keeps things like the
_flyToProgressCurve
on the implementation side, letting us use the engine's curve classes with the side effect of allowing use-cases beyond just the fly-to controller. For example, you could use this class to place markers along the flight path, or to turn the curve into a set of vertices to display the line an object is moving along.