Sistemas de coordenadas¶
Tres aplicaciones, tres ideas de hacia dónde queda el arriba y de qué tamaño es una unidad. Esta página explica qué hace OTS al respecto — y el único error que existe para evitar.
No necesitas leer esto para usar OTS. Léelo cuando algo llegue rotado de forma rara, o cuando quieras saber por qué la herramienta confía en el archivo y no en quien lo envió.
El espacio canónico¶
Todo lo que está en disco se guarda en un solo espacio:
| Arriba | Y |
| Handedness | Right-handed |
| Unidad | Metros |
| Rotación (animación) | Euler XYZ, grados |
| Rotación (rest) | Quaternion, w x y z |
Esa es la convención OGL de Harmony, lo que convierte a Harmony en el caso identidad. Cada una de las demás aplicaciones declara su propio espacio y convierte en el borde.
| Aplicación | Espacio nativo | Conversión a canónico |
|---|---|---|
| Harmony | Y-up right-handed, metros (OGL) | Identidad, más una escala field ↔ OGL en runtime |
| Blender | Z-up right-handed, metros | Swizzle (x, z, −y) |
| Maya | Y-up right-handed, centímetros | ×0.01, sin intercambio de ejes (las escenas Z-up también hacen swizzle) |
El header¶
Cada archivo lleva un bloque coordinate_system que describe el espacio en el que fue escrito. Cada lector mira ese bloque y convierte según corresponda.
Por eso las seis rutas funcionan sin código por ruta. Un lector no sabe ni le importa qué aplicación escribió el archivo — solo qué espacio declara. Agregar una aplicación es agregar un espacio.
Es también por eso que los valores en disco nunca cambian de significado entre versiones: los números son siempre canónicos, y el header siempre está ahí para decir respecto a qué.
Cuatro canales, cuatro conversiones¶
Lo interesante es que los cuatro tipos de datos se convierten de forma distinta.
Permutación de ejes con signo, y después la escala de unidad.
Una posición de Blender (x, y, z) se vuelve canónica (x, z, −y). Una posición de Maya se multiplica por 0.01.
El componente w se preserva; la parte vectorial se permuta como una posición.
Sin escala de unidad — una rotación no tiene longitud.
Una permutación sin signo, y sin escala de unidad.
La escala es una magnitud. Negarla haría un espejo del objeto, que nunca es lo que significa un cambio de convención de ejes.
No es una permutación. Este es el que agarra a la gente desprevenida.
Ver abajo.
La trampa de Euler¶
Aquí está el error, dicho sin rodeos, porque es la razón por la que OTS tiene la forma que tiene:
El cambio de base de una rotación no es una permutación de sus ángulos de Euler.
Parece que debería serlo. Si una posición hace swizzle (x, y, z) → (x, z, −y), ¿seguramente la rotación también? Y para la base identidad da la casualidad de que funciona, lo que hace que el bug sobreviva a las pruebas.
Pero permutar ángulos de Euler para un cambio Z-up ↔ Y-up produce una rotación sobre los ejes equivocados. El objeto gira — así que nada parece obviamente roto — pero gira mal, y el error se acumula a lo largo de una cadena. Este es el síntoma clásico de un puente 3D hecho a mano: "la rotación llegó, pero no está bien."
La transformación correcta es una conjugación de la rotación misma:
- Convertir los ángulos de Euler a un quaternion.
- Rotar el eje de ese quaternion por la permutación con signo.
- Convertir de vuelta a Euler XYZ.
OTS hace eso, en todas partes, con un camino rápido que se salta el trabajo cuando la permutación es la identidad (que es por lo que Harmony ↔ Maya en una escena Y-up no cuesta nada).
La rotación viaja como quaternion cuando puede
Junto con los ángulos de Euler, cada key de animación lleva también un quaternion real calculado a partir de la world matrix bakeada. Es independiente del orden, así que esquiva por completo la ambigüedad del orden de Euler — y todo importador lo prefiere cuando está presente. Los valores de Euler quedan como fallback legible para humanos.
Unidades¶
| Harmony | Metros, vía una escala field ↔ OGL de runtime que OTS le pide a la escena en vivo. No es una constante — depende de la resolución, el field of view y el aspect ratio |
| Blender | Metros. Sin conversión |
| Maya | Centímetros. ×0.01 al salir, ×100 al entrar |
La opción Scale de .pvt es un multiplicador aparte, de cara al usuario, para rigs creados a un tamaño de trabajo raro. No es la conversión de unidades entre aplicaciones, que es automática e invisible.
El "falso quaternion" de Harmony¶
Harmony tiene un tipo de columna llamado QUATERNIONPATH que no es un quaternion. Es una subclase de la columna de 3D-path que guarda tres componentes de ángulo de Euler más una velocidad.
Así que la rotación de un peg de Harmony siempre se lee y se escribe como Euler XYZ en grados, en todos los modos de peg, sin importar cómo se llame la columna. Leerla como un quaternion (w, x, y, z) produce basura.
Ver En Harmony.
Apuntado de cámara¶
Las cámaras reciben una corrección extra, porque "hacia dónde apunta una cámara" es una convención por aplicación:
| Aplicación | La cámara mira hacia | Al importar |
|---|---|---|
| Harmony | Su propio −Z — ya es el forward canónico | Solo roll |
| Maya | Su propio −Z — ya es el forward canónico | Solo roll |
| Blender | −Z en un mundo Z-up | +90° en X, más roll |
La inclinación de Blender se quita de nuevo al exportar, así que una cámara que mira hacia adelante hace round-trip a un peg identidad en vez de acumular una deriva de 90° cada vez.
El FOV se lleva como ángulo vertical, coincidiendo con los ajustes de escena de Harmony, y cada aplicación se configura explícitamente con sensor fit vertical. Ver Cámaras.
Límite conocido¶
Las escenas Z-up de Maya emiten handles solo de interpolación. Los valores de keyframe se convierten correctamente, pero los tangents bezier por key se simplifican. Trabaja en Y-up en Maya si te importan las formas exactas de los tangents.