전송 경로¶

OTS는 세 개의 애플리케이션 사이에서 데이터를 옮깁니다. 즉 방향이 여섯 개라는 뜻입니다. 여섯 개 모두, 두 파일 포맷 모두에서 동작합니다.

출발 ↓ / 도착 →	Harmony	Blender	Maya
Harmony	—	✅ `.pvt` `.anm`	✅ `.pvt` `.anm`
Blender	✅ `.pvt` `.anm`	—	✅ `.pvt` `.anm`
Maya	✅ `.pvt` `.anm`	✅ `.pvt` `.anm`	—

왜 테스트한 것만이 아니라 여섯 개 전부인가¶

OTS에는 경로별 전용 코드가 없습니다. "Harmony reader"와 "Blender reader" 같은 건 없습니다 — 파일 포맷당 reader는 하나뿐입니다.

모든 writer는 자신이 기록한 공간을 설명하는 coordinate_system 헤더를 파일에 찍습니다: 어느 축이 위인지, handedness는 무엇인지, 단위 하나가 무엇을 뜻하는지. 모든 reader는 그 헤더를 보고 들어오는 길에 단 하나의 정규 공간(canonical space)을 거쳐 값을 변환합니다.

그러므로 경로는 따로 만들어야 하는 기능이 아닙니다. Blender → Maya가 동작하는 이유는 Harmony → Maya가 동작하는 이유와 똑같습니다: Maya의 reader는 누가 그 파일을 썼는지 알지도, 신경 쓰지도 않고, 오직 그 파일이 어떤 공간을 선언하는지만 봅니다. 좌표계를 참조하세요.

Blender ↔ Maya는 일급 경로입니다

분명히 말해둘 가치가 있습니다. 사람들이 없을 거라고 지레짐작하는 경로가 바로 이것이거든요: rig이든 샷이든 Blender에서 Maya로, 또는 Maya에서 Blender로 곧장 보낼 수 있습니다. Harmony를 경유할 필요가 없습니다. Blender에서 export한 뒤 Maya 안에서 결과 포즈를 검증하는 자동화된 애플리케이션 간 테스트가 이 경로를 커버하고 있습니다.

각 경로가 잘하는 일¶

Harmony → Blender / Maya¶

흔한 경로입니다. 2D 컷아웃 rig의 peg가 bone이나 joint가 되므로, 3D 씬을 레퍼런스 레이아웃으로 쓰거나, 카메라 이동을 3D에서 제대로 만들거나, 대응하는 3D 패스를 렌더할 수 있습니다.

peg 계층 구조 전체가 넘어갑니다 — 오직 카메라를 붙들기 위해서만 존재하는 peg까지 포함해서요.

Blender / Maya → Harmony¶

또 하나의 흔한 경로입니다. 카메라 이동을 — 또는 기계적인 rig이나, 3D에서 블로킹하는 편이 쉬운 무엇이든 — 애니메이트한 뒤, 그것으로 여러분의 Harmony peg을 구동하세요.

애니메이션을 적용하면 Harmony peg의 authoring 모드가 덮어써집니다

OTS가 기존 Harmony peg에 .anm을 적용하면, 그 peg에 붙어 있던 3D-path나 quaternion-path 컬럼의 링크를 끊고 대신 채널이 분리된 새 bezier 커브를 기록합니다.

값은 정확하고, 커브도 편집 가능합니다. 하지만 그 peg이 3D path 위에서 authoring된 것이었다면, 그 path는 이후 사라집니다. 이건 의도된 트레이드오프입니다 — 그렇게 하지 않으면 Harmony의 회전 컬럼이 들어오는 모든 커브를 표현할 수 없습니다 — 그래도 손수 만든 peg에 대고 하고 싶은 일은 아닐 겁니다. 갓 만든 Create Rig 결과물 위에 적용하면 이 문제 자체가 생기지 않습니다.

Blender ↔ Maya¶

3D 애플리케이션 둘, Harmony는 관여하지 않습니다. 파이프라인의 나머지가 Octo Tools이고, FBX 왕복 없이 bezier tangent와 카메라 렌즈 데이터를 실어 나르는 가볍고 읽기 쉬우며 diff 가능한 전송만 원할 때 유용합니다.

이 경로가 주로 시험하는 것은 양방향 Z-up ↔ Y-up 변환입니다. 좌표계를 참조하세요.

경로에 맞는 포맷 고르기¶

원하는 것	보낼 것
애니메이션, 그런데 반대편에 아직 rig이 없음	`.anm` → Create Rig
애니메이션, 이미 매치되는 rig 위에	`.anm` → Apply
스켈레톤만 — 샷은 빼고	`.pvt` → Build Skeleton
잃어버린 rig을 재구축	`.pvt` → Build Skeleton
카메라	둘 다 — 두 포맷 모두 카메라를 실어 나르지만, `.anm`은 그 움직임까지 함께 가져갑니다

Pivot 파일 (.pvt)과 애니메이션 파일 (.anm)을 참조하세요.

모든 경로에서 함께 가는 것¶

함께 가는 것	비고
계층 구조	각 항목의 parent는 가장 가까운 export된 조상으로 해석됩니다 — 그래서 일부만 export해도 일관된 chain으로 나옵니다
rest pose	pivot과 rest rotation
위치 / 회전 / 스케일 키	export된 범위 안에서, 프레임 단위로
보간	`BEZIER`, `LINEAR`, `CONSTANT`
Bezier handle	절대값, 축별로
카메라	FOV, near/far clip, offset, roll, 기본 카메라 플래그
rig 그룹핑	Rig 열 — 여러 캐릭터가 있는 씬이 분리된 채로 유지됩니다

함께 가지 않는 것	이유
드로잉, 메시, 머티리얼, 텍스처	OTS는 transform 브리지이지 에셋 파이프라인이 아닙니다
deformer, constraint, expression, IK	오직 그 결과로 나온 transform만
레이어 이름, 색상, 태그, 노드 메타데이터	매칭에 필요한 이름과 path를 넘어서는 것은 제외
peg의 authoring 모드	힌트로 기록되지만 값을 바꾸는 데는 절대 쓰이지 않습니다 — 파일 포맷을 참조하세요

결과 transform만 이동하기 때문에, 한쪽에서 복잡한 셋업으로 구동되던 rig은 반대편에 그냥 bake된 평범한 키로 도착합니다. 전송에서 대개 원하는 바가 그것이긴 하지만, 그건 곧 샷 단위로 전송이 단방향이라는 뜻이기도 합니다: 되돌려 보낸다고 원래 셋업이 다시 나타나지는 않습니다.