파일과 최종 장면을 나누어 생각한다
OpenUSD는 장면을 기술하고 여러 자료를 합성하는 체계다. 여기서 Stage는 애플리케이션이 조회하는 합성된 장면이고 Prim은 그 장면 안의 객체다. Layer는 객체에 관한 의견을 저장하는 단위로 파일일 수도 있고 메모리의 익명 레이어일 수도 있다. 같은 Prim에 여러 파일의 내용이 기여할 수 있으므로 파일 하나와 화면의 객체 하나가 항상 일대일은 아니다. USD 장면을 읽는 것과 물리 엔진에서 운동시키는 것도 다른 단계다.
그림 M10.01-1. 각 칸은 서로 다른 역할/근거다. 나란히 비교할 항목이며 위아래가 시간 순서를 뜻하지 않는다. 직접 제작한 개념도이며 본문의 조건과 함께 읽는다.
Prim 경로 /World/Robot/Tool은 장면에서 객체를 찾는 주소다. /World/Robot 아래에 Tool이 있다는 계층을 나타내며 운영체제의 폴더 경로라는 뜻은 아니다. Prim은 Xform이나 Mesh 같은 타입, 자식, 속성과 메타데이터를 가질 수 있다. Attribute는 질량이나 색처럼 자료형이 있는 값이다. Relationship은 다른 객체/속성의 경로를 가리키는 연결이다. 예를 들어 Target의 사용자 정의 속성 label="cup"과 관계 observedBy→/World/Camera를 구분한다. 관계가 있다고 카메라가 실제 영상을 생산하도록 실행 코드가 자동 생성되지는 않는다.
이름을 바꾸면 해당 경로를 사용하는 센서 설정과 코드도 영향을 받는다. 따라서 장면을 수정할 때에는 ‘보이는 이름’만이 아니라 누가 그 경로를 조회하는지 조사한다. 참조 합성이 경로를 옮기는 경우 USD가 관리하는 관계 대상도 다시 매핑될 수 있지만, 외부 코드의 임의 문자열까지 모두 고쳐 준다고 기대하지 않는다. 기본 객체와 연결의 정의는 OpenUSD 공식 소개에서 확인한다.
값이 적힌 곳과 값이 보이는 곳
의견은 어떤 레이어에 작성한 값이나 설정이다. 이번에는 같은 경로의 같은 속성에 쓴 시간 불변의 직접 값만 비교한다. 변형 선택·상속·시간 샘플·값 차단 등은 없는 단순 사례다. 실제 USD 합성 전체가 ‘파일을 나중에 열면 이김’ 규칙인 것은 아니다. 레이어 스택과 합성 연결 종류의 강도 규칙이 있으므로 복잡한 경우에는 기여한 의견과 경로를 조사해야 한다.
가상 장면의 /World/Target에 있는 사용자 속성 task:massNoteKg를 보자. 이는 학습용 숫자 메모이며 물리 질량 스키마가 아니다. 약한 asset 레이어는 1.0, 더 강한 experiment 레이어는 1.2, 가장 강한 session 레이어는 0.8이라는 의견을 낸다고 명시하자. 이 조건의 최종 조회값은 0.8이다. 셋을 더해 3.0으로 만들거나 평균 1.0을 쓰지 않는다. 같은 물체에 대한 경쟁 의견이기 때문이다.
편집 대상 edit target은 새 의견을 어느 레이어에 쓸지 정한다. asset을 편집해 값을 1.5로 바꾸어도 session의 0.8이 남으면 조회값은 그대로다. 이것이 저장 실패의 증거는 아니다. 더 강한 의견에 가려졌을 수 있다. session의 해당 의견을 제거하면 experiment의 1.2가 드러나고, experiment의 의견도 제거하면 asset의 1.5가 드러난다. 0을 쓰는 것과 의견을 제거하는 것은 다르다. 0도 하나의 명시된 값이어서 약한 값을 계속 가릴 수 있다.
저장은 이 구분을 한 단계 더 요구한다. session은 임시 실험용 공간으로 쓸 수 있으며 UsdStage.Save는 session 레이어를 저장하지 않는다. 익명 레이어나 별도 의존 자산의 관리도 확인해야 한다. 다음 실행에서 실험을 다시 열려면 필요한 의견을 의도한 파일 레이어에 보존하고 그 레이어를 장면 구성에 포함해야 한다. 단지 화면에서 바뀌었다는 기록만으로 재현 가능한 자산이 만들어졌다고 보지 않는다. 공식 용어집의 Session Layer는 편집과 저장의 차이를 설명한다.
참조는 복사 없이 자산을 구성하는 연결이다
reference는 다른 자산의 Prim 내용을 현재 장면의 특정 Prim 아래로 가져오는 합성 연결이다. 예를 들어 원본 robot.usd의 /Robot을 /World/RobotA와 /World/RobotB에 각각 참조하면 장면에 두 배치가 생긴다. 각 배치의 위치를 달리하면서 원본 링크 구조를 재사용할 수 있다. 원본 전체 파일을 두 벌 복사하는 방법과 변경 전파/의존성 관리가 다르다. 참조 대상을 지정하지 않는 방식에는 defaultPrim 등 별도 조건이 있으므로 자산의 공개 진입점을 확인한다.
원본이 바뀌면 그 원본을 사용하는 장면도 영향을 받을 수 있으므로 파일 이름만 같게 두고 버전이 고정됐다고 말하지 않는다. 원본 경로/해시, 사용한 Prim, override 레이어를 함께 기록한다. 경로를 해석할 수 없는 자산이 있으면 참조가 선언됐다는 사실과 내용이 제대로 해석됐다는 사실을 나누어 검사한다. 화면에서 빈 모델을 본 뒤 무조건 좌표나 카메라 문제로 단정하지 않는다.
인스턴싱의 절약에는 편집 경계가 있다
scenegraph instancing은 호환되는 반복 자산의 하위 장면 구조를 공유하는 방식이다. reference를 여러 개 썼다고 항상 인스턴스가 되는 것은 아니다. instanceable 설정과 공유 가능한 합성 구조 등의 조건이 있다. 인스턴스 루트마다 배치 변환을 다르게 둘 수 있지만, 공유되는 하위 Prim을 각 인스턴스에서 마음대로 추가/삭제/override하는 방식에는 제약이 있다. RobotB만 손가락 모양을 바꿔야 한다면 공통 자산의 variant 설계, 별도 자산 또는 해당 배치의 비인스턴스화 같은 구조를 검토한다.
절약의 직관을 가상 비용으로 계산해 보자. 공유할 하위 구조 비용 S=100 단위, 배치별 비용 P=2 단위, 배치 수 N=10이라 정의한다. 독립 사본 모델은 N(S+P)=1020, 공유 모델은 S+NP=120이다. 차이는 900 비용 단위다. 이는 계산 학습을 위한 모형이며 실제 MB나 GPU 메모리 측정값이 아니다. 물리 상태·센서·렌더러의 비용까지 이 비율로 줄거나 실제 속도가 8.5배 빨라진다는 보장도 없다. N=1이면 두 모형 모두 102라서 반복 수가 적을 때 이 비용 가정의 이점은 사라진다.
또한 내부 prototype 경로는 실행마다 고정된 사용자 API가 아니다. 생성된 이름을 파일에 박아 두기보다 안정적인 장면 인스턴스 경로를 기준으로 관리한다. 공식 인스턴싱 설명과 기존 1.3 OpenUSD를 연결하면 원본·실험 의견·최종 조회값·공유 구조의 네 층을 분리할 수 있다.