Systèmes de coordonnées¶
Trois applications, trois idées de quel côté est le haut et de la taille d'une unité. Cette page explique ce qu'OTS fait de tout ça — et la seule erreur qu'il existe pour éviter.
Vous n'avez pas besoin de lire ceci pour utiliser OTS. Lisez-le quand quelque chose arrive bizarrement tourné, ou quand vous voulez savoir pourquoi l'outil fait confiance au fichier plutôt qu'à l'expéditeur.
L'espace canonique¶
Tout ce qui est sur le disque est stocké dans un seul espace :
| Haut | Y |
| Chiralité | Droite |
| Unité | Mètres |
| Rotation (animation) | Euler XYZ, degrés |
| Rotation (rest) | Quaternion, w x y z |
C'est la convention OGL de Harmony, ce qui fait de Harmony le cas identité. Toutes les autres applications déclarent leur propre espace et convertissent aux extrémités.
| Application | Espace natif | Conversion vers le canonique |
|---|---|---|
| Harmony | Y-up droitier, mètres (OGL) | Identité, plus une échelle field ↔ OGL calculée au runtime |
| Blender | Z-up droitier, mètres | Swizzle (x, z, −y) |
| Maya | Y-up droitier, centimètres | ×0.01, pas d'échange d'axe (les scènes Z-up font aussi un swizzle) |
L'en-tête¶
Chaque fichier transporte un bloc coordinate_system décrivant l'espace dans lequel il a été écrit. Chaque reader regarde ce bloc et convertit en conséquence.
C'est pour ça que les six routes fonctionnent sans code par route. Un reader ne sait pas — et se moque de savoir — quelle application a écrit le fichier : seulement quel espace il déclare. Ajouter une application, c'est ajouter un espace.
C'est aussi pour ça que les valeurs sur le disque ne changent jamais de sens d'une version à l'autre : les nombres sont toujours canoniques, et l'en-tête est toujours là pour dire par rapport à quoi.
Quatre canaux, quatre conversions¶
Ce qui est intéressant, c'est que les quatre types de données se convertissent différemment.
Permutation signée des axes, puis l'échelle d'unité.
Une position Blender (x, y, z) devient (x, z, −y) en canonique. Une position Maya est multipliée par 0.01.
La composante w est préservée ; la partie vectorielle est permutée comme une position.
Pas d'échelle d'unité — une rotation n'a pas de longueur.
Une permutation non signée, et pas d'échelle d'unité.
Le scale est une magnitude. Le négativer produirait un miroir de l'objet, ce qui n'est jamais ce que signifie un changement de convention d'axe.
Pas une permutation. C'est celle qui piège tout le monde.
Voir ci-dessous.
Le piège d'Euler¶
Voici l'erreur, dite platement, parce que c'est la raison pour laquelle OTS existe sous cette forme :
Le changement de base d'une rotation n'est pas une permutation de ses angles d'Euler.
On dirait pourtant que ça devrait l'être. Si une position se swizzle (x, y, z) → (x, z, −y), la rotation le fait sûrement aussi ? Et pour la base identité ça marche par hasard, ce qui fait survivre le bug aux tests.
Mais permuter les angles d'Euler pour un changement Z-up ↔ Y-up produit une rotation autour des mauvais axes. L'objet tourne — donc rien n'a l'air manifestement cassé — mais il tourne mal, et l'erreur se cumule le long d'une chain. C'est le symptôme classique d'un pont 3D bricolé à la main : « la rotation est passée, mais elle n'est pas correcte. »
La transformation correcte est une conjugaison de la rotation elle-même :
- Convertir les angles d'Euler en quaternion.
- Faire tourner l'axe de ce quaternion par la permutation signée.
- Reconvertir en Euler XYZ.
OTS fait ça, partout, avec un chemin rapide qui saute le travail quand la permutation est l'identité (c'est pourquoi Harmony ↔ Maya dans une scène Y-up ne coûte rien).
La rotation voyage en quaternion quand elle le peut
À côté des angles d'Euler, chaque key d'animation transporte aussi un vrai quaternion calculé à partir de la world matrix bakée. Il est indépendant de l'ordre, donc il contourne entièrement l'ambiguïté d'ordre d'Euler — et tous les importeurs le préfèrent quand il est présent. Les valeurs Euler restent en repli lisible par un humain.
Unités¶
| Harmony | Mètres, via une échelle field ↔ OGL calculée au runtime qu'OTS demande à la scène live. Ce n'est pas une constante — elle dépend de la résolution, du field of view et du ratio d'aspect |
| Blender | Mètres. Pas de conversion |
| Maya | Centimètres. ×0.01 en sortie, ×100 en entrée |
L'option Scale du .pvt est un multiplicateur séparé, exposé à l'utilisateur, pour les rigs créés à une taille de travail inhabituelle. Ce n'est pas la conversion d'unité entre applications, qui est automatique et invisible.
Le « faux quaternion » de Harmony¶
Harmony a un type de colonne nommé QUATERNIONPATH qui n'est pas un quaternion. C'est une sous-classe de la colonne 3D-path qui stocke trois composantes d'angle d'Euler plus une vélocité.
Donc la rotation d'un peg Harmony est toujours lue et écrite en degrés Euler XYZ, dans tous les modes de peg, quel que soit le nom de la colonne. La lire comme un quaternion (w, x, y, z) produit n'importe quoi.
Voir Dans Harmony.
Visée de la caméra¶
Les caméras reçoivent une correction supplémentaire, parce que « de quel côté pointe une caméra » est une convention propre à chaque application :
| Application | La caméra regarde vers | À l'import |
|---|---|---|
| Harmony | Son propre −Z — déjà l'avant canonique | Roll seulement |
| Maya | Son propre −Z — déjà l'avant canonique | Roll seulement |
| Blender | −Z dans un monde Z-up | +90° en X, plus le roll |
L'inclinaison de Blender est retirée à nouveau à l'export, pour qu'une caméra regardant vers l'avant fasse un aller-retour vers un peg identité au lieu d'accumuler une dérive de 90° à chaque passage.
Le FOV est transporté comme un angle vertical, ce qui correspond aux réglages de scène de Harmony, et chaque application est explicitement réglée sur un sensor fit vertical. Voir Caméras.
Limite connue¶
Les scènes Maya en Z-up n'émettent que des handles d'interpolation. Les valeurs des keyframes se convertissent correctement, mais les tangentes bezier par key sont simplifiées. Travaillez en Y-up dans Maya si la forme exacte des tangentes compte.