Sistemas de Coordenadas¶
Três aplicações, três ideias de qual lado é pra cima e de quão grande é uma unidade. Esta página explica o que o OTS faz a respeito disso — e o único erro que ele existe para evitar.
Você não precisa ler isso para usar o OTS. Leia quando algo chegar rotacionado de forma estranha, ou quando você quiser saber por que a ferramenta confia no arquivo em vez de confiar em quem mandou.
O espaço canônico¶
Tudo no disco é armazenado em um espaço:
| Up | Y |
| Handedness | Right |
| Unidade | Metros |
| Rotação (animação) | Euler XYZ, graus |
| Rotação (rest) | Quaternion, w x y z |
Essa é a convenção OGL do Harmony, o que faz do Harmony o caso identidade. Toda outra aplicação declara seu próprio espaço e converte na borda.
| Aplicação | Espaço nativo | Conversão para o canônico |
|---|---|---|
| Harmony | Y-up right-handed, metros (OGL) | Identidade, mais uma escala field ↔ OGL em runtime |
| Blender | Z-up right-handed, metros | Swizzle (x, z, −y) |
| Maya | Y-up right-handed, centímetros | ×0.01, sem troca de eixo (cenas Z-up também fazem swizzle) |
O cabeçalho¶
Todo arquivo carrega um bloco coordinate_system descrevendo o espaço em que foi escrito. Todo leitor olha esse bloco e converte conforme.
É por isso que todas as seis rotas funcionam sem código por rota. Um leitor não sabe nem se importa com qual aplicação escreveu o arquivo — só com que espaço ele declara. Adicionar uma aplicação é adicionar um espaço.
É também por isso que valores em disco nunca mudam de significado entre versões: os números são sempre canônicos, e o cabeçalho está sempre lá para dizer em relação a quê.
Quatro canais, quatro conversões¶
A parte interessante é que os quatro tipos de dado convertem de forma diferente.
Permutação de eixos com sinal, e então a escala de unidade.
Uma posição do Blender (x, y, z) vira a canônica (x, z, −y). Uma posição do Maya é multiplicada por 0.01.
O componente w é preservado; a parte vetorial é permutada como uma posição.
Sem escala de unidade — uma rotação não tem comprimento.
Uma permutação sem sinal, e sem escala de unidade.
Escala é uma magnitude. Negá-la espelharia o objeto, que nunca é o que uma mudança de convenção de eixos significa.
Não é uma permutação. É esta que pega as pessoas.
Veja abaixo.
A armadilha do Euler¶
Aqui está o erro, dito na lata, porque é a razão de o OTS existir na forma em que existe:
A mudança de base de uma rotação não é uma permutação dos seus ângulos Euler.
Parece que deveria ser. Se uma posição faz swizzle (x, y, z) → (x, z, −y), a rotação não faria também? E para a base identidade isso por acaso funciona, o que faz o bug sobreviver aos testes.
Mas permutar ângulos Euler para uma mudança Z-up ↔ Y-up produz uma rotação em torno dos eixos errados. O objeto gira — então nada parece obviamente quebrado — mas gira errado, e o erro se acumula ao longo de uma chain. Este é o sintoma clássico de uma ponte 3D feita na mão: "a rotação chegou, mas não está certa."
A transformação correta é uma conjugação da própria rotação:
- Converta os ângulos Euler para um quaternion.
- Rotacione o eixo desse quaternion pela permutação com sinal.
- Converta de volta para Euler XYZ.
O OTS faz isso, em todo lugar, com um caminho rápido que pula o trabalho quando a permutação é a identidade (que é por que Harmony ↔ Maya numa cena Y-up não custa nada).
A rotação viaja como quaternion onde dá
Junto com os ângulos Euler, cada key de animação também carrega um quaternion de verdade calculado a partir da world matrix bakeada. Ele é independente de ordem, então contorna a ambiguidade de ordem Euler por completo — e todo importador o prefere quando ele está presente. Os valores Euler permanecem como fallback legível por humanos.
Unidades¶
| Harmony | Metros, via uma escala field ↔ OGL de runtime que o OTS pede para a cena viva. Ela não é uma constante — depende de resolução, field of view e aspect ratio |
| Blender | Metros. Sem conversão |
| Maya | Centímetros. ×0.01 na saída, ×100 na entrada |
A opção Scale do .pvt é um multiplicador separado, voltado ao usuário, para rigs autorados num tamanho de trabalho estranho. Não é a conversão de unidade entre aplicações, que é automática e invisível.
O "falso quaternion" do Harmony¶
O Harmony tem um tipo de coluna chamado QUATERNIONPATH que não é um quaternion. É uma subclasse da coluna 3D-path que armazena três componentes de ângulo Euler mais uma velocidade.
Então a rotação de um peg do Harmony é sempre lida e escrita como Euler XYZ em graus, em todo modo de peg, independente de como a coluna se chama. Lê-la como um quaternion (w, x, y, z) produz lixo.
Veja No Harmony.
Mira da câmera¶
Câmeras ganham uma correção extra, porque "para que lado uma câmera aponta" é uma convenção por aplicação:
| Aplicação | A câmera olha pelo | No import |
|---|---|---|
| Harmony | Seu próprio −Z — já é a frente canônica | Só o roll |
| Maya | Seu próprio −Z — já é a frente canônica | Só o roll |
| Blender | −Z num mundo Z-up | +90° em X, mais o roll |
O tilt do Blender é removido de novo no export, então uma câmera olhando para a frente faz round trip para um peg identidade em vez de acumular 90° de drift a cada vez.
O FOV é carregado como ângulo vertical, casando com as scene settings do Harmony, e cada aplicação é explicitamente configurada para um sensor fit vertical. Veja Câmeras.
Limite conhecido¶
Cenas Maya Z-up emitem handles só de interpolação. Os valores de keyframe convertem corretamente, mas as tangentes bezier por key são simplificadas. Trabalhe em Y-up no Maya se formas exatas de tangente importam.