The changes in #422 raise some implications about our current component design that I think we should consider, to improve code quality and clarity.
While working with XR, @azrogers found a scenario where:
The XR origin needed to be anchored by CesiumGlobeAnchor, but
The camera is a child game object that will contain CesiumCameraController and CesiumFlyToController.
It feels conceptually strange that the CesiumFlyToController is piloting a parent object, or more generally some object that it isn't actually attached to. Historically we have attached it to a camera in order to make it fly between locations, but we should look to decouple this from CesiumCameraController. Cesium for Unreal does this and also seems to account for movement interruption, so maybe we can take the implementation from there.
There may be more design implications to consider, but I can't remember completely what we discussed offline. @azrogers feel free to weigh in if I missed anything!
The changes in #422 raise some implications about our current component design that I think we should consider, to improve code quality and clarity.
While working with XR, @azrogers found a scenario where:
CesiumGlobeAnchor, butCesiumCameraControllerandCesiumFlyToController.It feels conceptually strange that the
CesiumFlyToControlleris piloting a parent object, or more generally some object that it isn't actually attached to. Historically we have attached it to a camera in order to make it fly between locations, but we should look to decouple this fromCesiumCameraController. Cesium for Unreal does this and also seems to account for movement interruption, so maybe we can take the implementation from there.There may be more design implications to consider, but I can't remember completely what we discussed offline. @azrogers feel free to weigh in if I missed anything!