콘텐츠로 이동

Harmony에서

Harmony는 OTS가 모국어를 쓰는 곳입니다. 교환 포맷의 정규 공간이 Harmony의 OGL 관례입니다 — Y-up, 오른손 좌표계, 미터 — 그래서 들어오거나 나가는 길에 뒤섞이는 것이 없습니다. 다른 모든 애플리케이션은 Harmony가 이미 쓰고 있는 것으로 변환합니다.

실행하기

Scripts 툴바에서 OctoTransformSync 스크립트를 실행하세요. 창은 Harmony 위에 열리고 계속 그 자리에 머무릅니다. 창이 열려 있는 상태에서 스크립트를 다시 실행하면 그 창을 앞으로 끌어올릴 뿐입니다.

창 안의 용어는 Harmony의 것입니다: 목록에는 PEGPEGs가 나오고, import 버튼은 Apply to PEGs라고 되어 있습니다.

네 개의 페이지

맨 위에 포맷 둘, 그 아래에 방향 둘 — Harmony에서 갈 수 있는 모든 페이지입니다:

Harmony — .pvt import

막 구축되려는 rest 스켈레톤입니다. Build Skeleton이 peg들을 만들고, 이 파일이 카메라를 담고 있어서 Create Cameras에 불이 들어옵니다.

Harmony — .pvt export

스캔해 넣은 peg들이 Rig 열과 Scale 옵션과 함께 보입니다. 프레임 범위는 없습니다 — .pvt에는 애니메이션이 없으니까요.

Harmony — .anm import

매치 트리입니다. 행마다 체크박스가 있고 세 가지 동작이 있습니다: Apply to PEGs, Create Rig, Create Cameras.

Harmony — .anm export

.pvt export와 같은 목록에 — 하나의 씬, 하나의 그룹핑 — Start / EndScene range가 더해집니다.


OTS가 peg에서 읽는 것

export되는 각 peg에 대해 OTS는 다음을 기록합니다:

  • node graph에서의 경로, 그리고 가장 가까운 export 대상 조상을 부모로.
  • 정규 미터 단위의 pivot.
  • transform — 키가 찍힌 프레임마다 world matrix로 평가한 뒤 그 조상에 상대적으로 만든 값.
  • 저작 모드 — 분리된 위치, quaternion-path 회전, 분리된 스케일, 3D 활성화 여부 — 힌트로 기록됩니다.
  • CAMERA 노드가 매달려 있다면 카메라 구성.

keyframe은 peg의 실제 컨트롤 포인트에서, 그리고 export 범위의 첫 프레임과 마지막 프레임에서 수집됩니다. bezier handle은 컬럼 타입이 허용하는 경우 네이티브로 읽고, 그렇지 않은 경우 커브를 샘플링해 재구성합니다.

field ↔ OGL 스케일

Harmony는 미터가 아니라 field 단위로 작동하며, 둘 사이의 변환은 상수가 아닙니다 — 씬의 해상도, 시야각, 종횡비에 따라 달라집니다. OTS는 숫자를 하드코딩하는 대신 export와 import 시점에 살아 있는 씬에 그 값을 물어보는데, Harmony 어댑터가 작업하려면 열린 씬이 필요한 이유가 이것입니다.

Harmony의 카메라 clip plane 역시 field 단위입니다. 원래의 field 값은 변환된 거리값과 나란히 파일에 보존되므로, Harmony → 무엇이든 → Harmony 왕복은 시작할 때의 숫자를 정확히 그대로 돌려줍니다.


"가짜 quaternion"

Harmony에는 QUATERNIONPATH라는 컬럼 타입이 있는데, 이건 quaternion이 아닙니다.

이건 3D-path 컬럼의 서브클래스이고, (w, x, y, z) quaternion이 아니라 세 개의 Euler 각 성분 경로와 속도를 저장합니다. 이걸 quaternion으로 읽으면 말도 안 되는 결과가 나옵니다.

그래서 OTS는 모든 peg 모드에서 peg의 회전을 언제나 Euler XYZ 도(degree) 로 읽고 씁니다. 내부적으로 교환 포맷은 bake된 world matrix로부터 계산한 진짜 quaternion도 회전값으로 함께 지닙니다. 그쪽은 순서에 무관하고 Euler 순서의 모호함을 완전히 비껴가며, 다른 애플리케이션들이 import 시에 선호하는 값입니다.

이것에 대해 여러분이 뭘 할 필요는 없습니다. peg의 회전이 왜 이런 식으로 다뤄지는지, 그리고 Harmony 씬을 순진하게 quaternion으로 읽으면 왜 잘못되는지를 설명해주기 때문에 여기 적어둔 것입니다.


기존 peg에 import하기

Apply to PEGs는 매치되고 체크된 행에 애니메이션을 기록합니다.

Apply는 peg의 저작 모드를 다시 씁니다

기록에 앞서 OTS는 대상 peg의 3D-path나 quaternion-path 컬럼을 연결 해제하고, 3D가 활성화된 분리된 위치 / 회전 / 스케일 채널을 강제한 뒤, 새 bezier 커브를 씁니다.

결과 값은 정확하고 커브는 완전히 편집 가능합니다. 하지만 3D path로 저작되었던 peg은 그 이후로는 3D path 위에 있지 않으며, 다시 import한다고 되돌아오지 않습니다.

이건 의도적인 trade-off입니다: 임의의 들어오는 커브는 그렇게 하지 않고서는 Harmony의 path 컬럼으로 표현할 수 없습니다. 그 peg이 손수 만든 것이고 그대로 유지하고 싶다면, 대신 Create Rig 결과물 위에 apply한 다음 직접 병합하세요.

파일에 기록된 source_modes힌트일 뿐입니다 — 나가는 길에 peg이 어떻게 저작되었는지를 설명할 뿐, 들어오는 길에 어떤 값도 바꾸지 않습니다.


Create Rig이 만드는 것

Create Rig은 흩어진 peg 더미가 아니라 완결되고 정돈된 서브 그래프를 조립합니다:

  • 파일 이름을 딴 래퍼 group과 Multi-Port-In.
  • 그룹 전체를 위한 외부 peg — 결과물을 하나의 오브젝트처럼 옮길 수 있게.
  • 항목마다 peg 하나, pivot 속성에 rest pivot이 기록된 상태로.
  • 파일의 계층 구조를 따르는 부모-자식 링크.
  • 말단(leaf)들이 먹여주는 composite 하나와 Multi-Port-Out.
  • 부모 group의 메인 composite에 연결된 group.

빌드 전체가 하나의 undo 단계입니다.

Create Cameras는 카메라마다 peg 하나와 CAMERA 노드 하나를 추가하고, 카메라를 그 peg 아래에 연결한 뒤, 파일로부터 peg에 키를 찍습니다.


참고 사항과 한계

매칭 시 접미사는 제거됩니다. hip-P라는 Harmony peg과 hip이라는 Maya joint는 같은 항목으로 취급되므로, 흔한 -P / -G / -C 관례가 왕복을 망가뜨리지 않습니다.

Harmony는 파일을 조금 더 느슨하게 읽습니다. Harmony 어댑터의 reader들은 Maya와 Blender reader가 하는 것과 같은 엄격한 버전 검사를 하지 않으므로, 버전이 틀린 파일은 거기서 다른 에러로 드러납니다. 소스 애플리케이션에서 다시 export하면 사라집니다.

씬이 열려 있어야 합니다. Harmony 어댑터가 하는 모든 일 — field 스케일, matrix bake, node graph 기록 — 은 살아 있는 씬을 상대로 돌아갑니다.


함께 보기

  • 좌표계 — Harmony가 왜 항등 케이스인지
  • 카메라 — field ↔ 거리 clip-plane 문제
  • 매치 트리 — Apply를 누르기 전 호박색이 무슨 뜻인지