user interface - sacar - Ángulos de Euler vs. Quaternions: ¿problemas causados por la tensión entre el almacenamiento interno y la presentación al usuario?
matriz de rotacion pdf (6)
Se puede decir que los cuaterniones son una opción apropiada para representar rotaciones de objetos internamente. Son simples y eficientes para interpolar y representar una sola orientación sin ambigüedades.
Sin embargo, la presentación de los cuaterniones en la interfaz de usuario generalmente no es adecuada. Los ángulos de Euler son, por lo general, mucho más familiares para los usuarios y sus valores son un poco más intuitivos y predecibles.
Los ángulos de Euler adolecen de ser complicados a nivel de código: requieren que se almacene un orden de rotación, y componer una orientación práctica (ya sea matriz o cuaternión) utilizando este orden y los ángulos asociados es engorroso, por decir lo menos.
Las interpolaciones confiables se realizan más convenientemente usando la representación del cuaternión. ¿Significa esto que debemos convertir constantemente entre una representación de Euler y una representación de cuaternión? ¿Es esto factible en términos de rendimiento?
¿Podemos almacenar las orientaciones como cuaterniones y convertirlas solo para que se muestren al usuario? Esto puede no ser posible porque para cualquier orientación dada hay exactamente una representación de cuaternión pero muchas representaciones de Euler. ¿Cómo ''elegimos'' la representación de Euler que corresponde a la que originalmente definió esa orientación? Parece una tarea imposible: efectivamente hemos perdido información al convertirnos en un cuaternión.
¿Podríamos almacenar como ángulos de Euler y luego convertir a cuaterniones según sea necesario? Esto probablemente no es escalable: la conversión de un ángulo de Euler a un cuaternión, la interpolación y la conversión de nuevo probablemente sea un código relativamente caro.
¿Podríamos simplemente almacenar ambas representaciones y usar las más apropiadas para cualquier situación dada? Un gran costo en términos de memoria (imagina las curvas de animación para un esqueleto con alrededor de sesenta huesos) y mantener estos valores sincronizados podría ser costoso, o al menos engorroso.
¿Alguien ha visto, utilizado o pensado alguna solución inteligente para este problema? Sin duda, las tres opciones anteriores no son solo las únicas? ¿Hay algún otro problema similar a este que se haya resuelto?
¿Por qué no utilizar Quarternions en el código y convertir Q en ángulos cuando sea necesario para visualizar?
De cuántas conversiones estamos hablando. Parece que está pagando por dos operaciones trascendentales por conversión, que en hardware moderno está disponible en el orden de 100 millones por segundo. Guardaría ambos, Quaternions para precisión y estética y rotaciones euler para preservar la información del usuario. Tal vez agregue una bandera para indicar cuál es el preferido para cualquier objeto dado. Además de eso, solo tiene que realizar la conversión una vez por miembro girado. Una vez que haya calculado una matriz de transformación, se multiplicará hasta que se quede sin vértices.
No creo que tenga sentido usar ángulos de Euler internamente; querrá usar cuaterniones para todos sus cálculos y, por lo general, no podrá pagar las conversiones en todas partes. En cuanto a la conversión a ángulos de Euler para la UI, ¿sería tan malo si el usuario solo obtiene un ángulo que es equivalente a la entrada original pero se representa de manera diferente? Si haces la conversión correcta, deberías terminar con los ángulos de Euler "más simples" para cualquier cuaternión dado.
Puede representar la rotación como eje + ángulo de rotación, que es esencialmente lo mismo que quaternion (hasta un signo)
Soy un fanático de los cuaterniones. Para que funcionen, ¿podrías reconsiderar tu presentación al usuario? En lugar de presentar la rotación al usuario como una serie de ángulos de Euler en forma de texto, puede elegir un objeto 3D simple y aplicar la rotación del cuaternión al objeto para visualizar visualmente la rotación en vigor.
Soy un ingeniero aeroespacial; He estado usando cuaterniones para el control de actitud y la navegación de la nave espacial durante tres décadas. Aquí hay algunas ideas sobre su situación:
- Realizar cualquier tipo de proceso que cambie la orientación con ángulos de Euler es casi imposible. Los ángulos de Euler sufren de singularidades: los ángulos cambiarán instantáneamente hasta 180 grados a medida que otros ángulos pasen por la singularidad; Los ángulos de Euler son virtualmente imposibles de usar para rotaciones secuenciales. Cuaterniones no sufren ninguno de estos problemas
- Hay 12 diferentes secuencias posibles de rotación de ángulos de Euler: XYZ, XYX, XZY, etc. No hay un conjunto "simple" o "correcto" de ángulos de Euler. Para derivar un conjunto de ángulos de Euler, debe saber qué secuencia de rotación está utilizando y atenerse a ella.
- Sugiero que realice todas las operaciones de almacenamiento y rotación con cuaterniones y solo convierta un cuaternión a ángulos de Euler cuando se requiera una salida. Cuando hace esto, debe definir qué secuencia de rotación de Euler está utilizando.
Tengo algoritmos para todas estas operaciones y muchas más: cuaterniones hacia / desde ángulos de Euler de cualquier secuencia de rotación hacia / desde matrices de rotación (matrices de coseno de dirección), posición de correspondencia de interpolación de cuaterniones, velocidad, etc. en puntos finales o intermedios, rígidos y flexibles dinámica corporal y cinemática utilizando cuaterniones.
Por favor contáctame si puedo ser de ayuda en [email protected]