Compose¶
Compose는 여러분이 작성한 모든 것 — pose layer와 그 key들, control, knob, driver, constraint, visibility group, look-at — 을 Harmony 씬 안의 실제 Master Controller 노드와 그 노드에 필요한 파일들로 바꿉니다.
ORC에서 씬에 실제로 기록하는 유일한 기능입니다.
MC 이름¶
MC Name에 이름을 입력합니다. 접미사는 붙이지 않아도 됩니다.
| 여러분이 누르면 | ORC가 하는 일 |
|---|---|
| Enter, 또는 다른 곳 클릭 | 아직 없다면 -MC를 붙입니다. Head → Head-MC. |
| Enter 다시 | Compose를 클릭합니다. |
대소문자를 구분하지 않으므로, head-mc로 입력한 이름은 입력한 그대로 남습니다.
그 외의 검증은 없습니다 — 문자 제거도, 고유성 검사도 없습니다. 최종 노드 이름은 Harmony가 결정하므로, 이름이 충돌하면 바뀐 이름으로 돌아올 수 있고 ORC는 실제로 받은 이름을 보고합니다.
Compose가 비활성화되는 이유¶
툴팁이 항상 이유이며, 항상 조치할 수 있는 내용입니다.
| 툴팁 | 해결법 |
|---|---|
| 먼저 Master Controller의 이름을 입력하세요. | 이름을 입력합니다. |
| "Eyebrows" pose layer에 아직 key가 없습니다. F6으로 snap을 찍거나 빈 layer를 삭제하세요. | key를 넣거나, 삭제합니다. |
| 3개의 layer가 key는 있지만 target이 없습니다(…). 각각이 무엇을 움직여야 하는지 target 목록에 추가하세요. | target을 지정합니다. 아무것도 움직이지 않는 widget은 출시할 수 없습니다. |
| 아직 compose할 것이 없습니다. pose, driver, constraint, look-at을 추가하거나 — Front와 Back MC를 모두 설정해 병합된 runtime을 bake하세요. | rig에 아무것도 없습니다. |
Compose는 이름이 채워져 있고, 절반만 완성된 layer가 없으며, 다음 중 하나 이상을 만족할 때 활성화됩니다.
- 어디든 pose key가 하나 이상 있거나,
- Front와 Back MC가 모두 설정되어 있거나(병합하는 경우),
- pose layer는 0개이지만 driver, constraint, 활성화된 look-at이 하나 이상 있는 경우 — 오토메이션만 있는 rig도 정상적으로 compose됩니다.
key가 전혀 필요 없는 layer들 — control의 face, knob, 가져온 grid — 은 예외입니다.
Compose를 막는 두 가지¶
Blocker — 완전히 거부됨¶
| 충돌 | 작동할 수 없는 이유 |
|---|---|
| Knob 충돌 | 두 개 이상의 extra knob이 같은 노드와 채널에 쓰는 경우. runtime은 노드와 attribute마다 순수한 base를 하나만 캡처하므로, 이 쓰기들은 합산될 수 없습니다 — 마지막 것이 조용히 이길 뿐입니다. |
| Drawing 충돌 | 하나의 READ 노드가 두 개 이상의 형제(sibling) layer에 의해 교체되는 경우. drawing 교체는 이산적(discrete)이라 블렌딩될 수 없고, 형제 사이의 우선순위도 없습니다. |
충돌을 지목하는 빨간 줄이 표시되고, Compose는 시작하지 않습니다. 문제가 되는 Outliner 행도 빨갛게 표시됩니다.
계층(hierarchy) 아래로 공유되는 drawing 교체는 문제 없습니다 — 더 깊은 layer가 이기는 것은 의도된 동작입니다.
Warning — 확인 후 계속 진행¶
의심스러운 부분이 있을 뿐이라면, 버튼이 5초 동안 CONFIRM?으로 바뀌고 옆에 목록이 표시됩니다. 시간이 지나면 다시 Compose로 돌아갑니다.
No pose data loadedNo Front or Back face: import an MC or author one— 둘 다 없을 때만 표시됩니다. Front만 있는 것은 정상입니다.Driver 'Blink' (Eyelids) has no keyed valuesConstraint 'Arm Follow' has no target nodesConstraint 'Arm Follow' has no channels selected
Compose Settings¶
| 설정 | 결정하는 내용 |
|---|---|
Save states / script to |
.tbState 파일, runtime 스크립트, ORC의 데이터 파일이 기록되는 위치. 기본값은 씬의 scripts 폴더입니다. |
Connect MC to composite |
새 MC가 연결될 Composite. ORC가 가장 유력한 추측을 미리 선택해 두지만, 씬의 전체 composite 목록은 언제나 선택할 수 있습니다. |
추측이 이루어지는 방식
이 선택은 목록 순서가 아니라 rig 자체에서 도출됩니다.
먼저 ORC는 rig의 main group을 찾습니다. target 목록의 모든 노드는 자신의 조상 group 전부에 표를 던지고, target의 과반수를 가진 가장 깊은 group이 승리합니다. deformation group이 표를 가져가지 못하게 막는 것이 바로 이 깊이입니다 — deformation group은 항상 자신의 소수 멤버만 담고 있으므로, 과반수는 언제나 그 바깥의 character group으로 향합니다.
그 group 안에서는 다음 중 첫 번째로 맞는 것이 승리합니다.
- 이미 어떤 MC가 연결되어 있는 composite — MC 연결이 가장 많은 것이 우선입니다. 만약 main group 안에 있다면 무조건 승리합니다.
- 이름이 master-controller 관례를 따르는 composite —
master-controller,masters,controllers,ctrl,-MC… - group의 main composite — Multi-Port-Out에 연결되는 것입니다.
- group 안에 composite가 전혀 없으면 → group 노드 자신이 바깥에서 연결되는 것.
아무것도 맞지 않으면 → 씬의 첫 번째 composite. 무엇이 선택되든 이는 사전 선택일 뿐입니다 — 콤보 박스는 언제나 씬의 모든 composite를 나열합니다.
Compose 사이에 같은 출력 폴더를 유지하세요
incremental 캐시가 그곳에 저장됩니다. 폴더를 재사용하는 것이 re-compose를 빠르게 만드는 이유입니다.
composite가 선택되지 않으면 MC는 Top에 생성되고 연결되지 않은 채로 남습니다. 그렇지 않으면 해당 composite의 부모 group 안에 생성되고, 찾기 쉽도록 Node View에서 바로 위에 배치됩니다.
진행 과정¶
네 단계이며, 모두 실시간으로 보고됩니다.
| 단계 | 산출물 |
|---|---|
Slicing state files… |
layer/side/page별로 하나씩인 .tbState pose stack, 그리고 매니페스트. 상세 줄은 정확히 어디인지 이름을 붙입니다. "Layer 'Eyebrows-L' — Pose 3 of 25 · Knob 2 of 13". |
Constraint pre-wiring… |
각 constraint의 원래 컬럼을 기록해, 토글로 복원할 수 있게 합니다. |
Generating MC script… |
MC가 실행할 runtime 스크립트입니다. |
Assembling MC node in Harmony… |
노드 자체, 그 attribute, UI 스크립트와 데이터, 그리고 ORC 자체의 블롭입니다. |
아래 Recent activity 로그는 warning을 포함해 타임스탬프가 찍힌 기록을 유지합니다.
Ctrl+Z 한 번이면 Compose가 undo됩니다
전체 조립 과정은 ORC Compose라는 이름의 단일 Harmony undo 단계 안에서 실행됩니다.
slicing 단계는 실제로 컬럼에 씁니다 — pose를 읽는 방법이 그것이기 때문입니다 — 하지만 그 기록은 일시적이고 버려지며, Compose가 성공하든 실패하든 취소되든 여러분의 pose는 이후 복원됩니다.
취소하기¶
Cancel은 두 번 클릭으로 확인합니다. 첫 클릭은 4초 동안 대기시키고(CONFIRM? (4s)), 두 번째 클릭이 취소합니다. 창의 ✕도 같은 방식으로 동작합니다 — 실행 중인 Compose는 그냥 닫히지 않습니다. Enter는 절대 Cancel을 트리거하지 않으므로, 무심코 누른 키 입력이 절반만 만들어진 MC를 중단시킬 수 없습니다.
취소는 협조적(cooperative)입니다. 중간이 아니라 다음 안전한 지점에서 멈추므로, "Will stop after the current Harmony call returns…"라는 메시지를 보게 됩니다.
취소가 남기는 것:
- slicing 중 취소: 이미 기록된
.tbState파일은 그대로 남고, 캐시도 저장되어 다음 실행에 그 작업이 반영됩니다. MC 노드는 생성되지 않습니다. - assembly가 시작된 후 취소: 노드는 존재합니다. compose 전체를 아우르는 트랜잭션은 없으므로,
ORC Compose단계에 대한 Ctrl+Z가 되돌아가는 방법입니다. - 어느 쪽이든 여러분의 pose는 복원됩니다.
끝나는 방식¶
| 결과 | 의미 |
|---|---|
| Compose complete — Top/robin-head-MC | 12 state stack(s), 2 constraint(s) | 완료입니다. Node View가 새 노드로 이동해 선택합니다. |
| Compose finished with 3 warning(s) — see the log | MC는 존재하고 작동합니다만, 치명적이지 않은 단계에서 문제가 있었습니다. 로그를 읽으세요. |
| Compose failed — no state files produced | slice할 수 있는 것이 없었습니다. |
| Compose failed — script generation error | |
| Compose failed — MC assembly error: … |
디스크에 남는 것¶
선택한 출력 폴더 안에:
| 파일 | 내용 |
|---|---|
<Stack>.tbState, 또는 <Stack>/0.tbState, 1.tbState… |
pose stack들입니다. knob이 있는 layer는 폴더를 하나 받고, knob 위치마다 파일이 하나씩 생깁니다 — Toon Boom 고유의 네이티브 레이아웃입니다. |
<folder>_compose_state.json |
runtime 매니페스트. |
<name>_orc.js |
생성된 runtime 스크립트. |
orc_pose_data.json |
여러분의 전체 rig 구성 — re-edit과 독립 실행형 Widget Editor의 원천입니다. |
orc_session_state.json |
작성 UI 상태로, 다시 열면 작업 공간이 복원됩니다. |
.orc_cache/snaps.json |
incremental compose 캐시입니다. rig의 일부가 아니므로 삭제해도 안전합니다. |
Stack 이름은 여러분의 layer 이름에서 파생됩니다 — Eyebrows와 Eyebrow는 둘 다 Eyebrow가 되고, side는 L/R을 붙이고, back stack은 Back을 붙이며, page는 자신의 번호를 붙입니다.
노드에 남는 것¶
runtime 스크립트와 그 데이터 외에, ORC는 자체 블롭 세 개를 MC 노드에 씁니다. 여러분의 pose 데이터, 세션 상태, 매니페스트입니다. 이들은 각각이 충분히 작을 때만 인라인으로 임베드됩니다. 그보다 크면 디스크에 남습니다. 수 메가바이트짜리 텍스트를 Harmony attribute에 임베드하면 읽을 때 스크립트 엔진이 크래시하기 때문입니다.
작은 포인터 attribute가 출력 폴더의 씬 기준 상대(scene-relative) 경로를 기록하며, 이것이 re-edit과 unroll이 나머지 파일을 찾는 방법입니다.
출력 폴더는 씬과 함께 유지하세요
MC는 runtime에 상태 파일을 디스크에서 읽습니다. 상태 파일 없이 씬만 옮기면 rig가 불러올 pose가 없어집니다. 경로는 씬 기준 상대로 저장되므로, 둘을 함께 옮기면 안전합니다.
다시 Compose하기¶
같은 rig에 다시 Compose하는 것은 정상이며 예상된 일입니다 — 반복 작업을 하는 방법입니다.
ORC는 baked pose가 아니라 frame 참조를 저장하므로, frame 861로 돌아가 눈썹을 고치고 다시 compose할 수 있습니다. 변경 사항이 반영됩니다. key를 다시 넣을 필요가 없습니다.
incremental 캐시 덕분에 re-compose는 실제로 바뀐 것만 다시 slice하며, 같은 출력 폴더를 유지하는 것이 중요한 이유가 바로 이것입니다.
관련 문서¶
- Keying & Auto-Capture — Compose가 읽는 것
- Re-editing a Composed MC — 다시 들어가기
- Unroll — 반대 방향으로 가기
- Troubleshooting

