USD 레이어·레퍼런스·페이로드 차이: 무거운 씬을 나눠 여는 원리

USD 레이어는 부서와 수정 의견을 겹쳐 보존하고, Reference(레퍼런스)는 외부 에셋을 다른 위치에 재사용하며, Payload(페이로드)는 참조한 데이터를 필요한 시점에 불러오게 합니다. 무거운 씬을 나눌 때는 수정 책임은 Sublayer, 반복 에셋은 Reference, 지금 열 필요가 없는 큰 지오메트리는 Payload로 나누세요. 단, 후디니 솔라리스(Houdini Solaris) 19.5는 기본값으로 Payload를 모두 로드하므로 Payload를 붙이는 것만으로 씬이 가벼워지지 않습니다. Configure Stage LOP에서 실제 로드 범위를 조절해야 합니다.

구성	주된 역할	외부 데이터를 늦게 여나	먼저 고려할 때
Layer / Sublayer	같은 경로의 의견을 강도 순서로 합성	아니요	부서별 수정·샷 오버라이드
Reference	외부 에셋 계층을 특정 prim 아래 재사용	아니요	캐릭터·소품을 여러 위치에 배치
Payload	외부 에셋을 지연 로드 가능한 참조로 연결	예, 로드 설정이 있을 때	무거운 지오메트리 중 작업 대상만 열기
Variant Set	한 prim의 여러 대안 중 선택한 구성을 합성	아니요	모델·룩·LOD 등 대안 전환

USD Layer는 한 장면에 대한 수정 의견을 보존하는 단위입니다

USD에서 Layer는 prim과 속성, 메타데이터 같은 장면 설명을 담는 구성 단위입니다. 여러 Layer를 조합하면 USD Stage가 만들어지고, 화면에는 그 의견들이 합쳐진 장면이 나타납니다. 쉽게 말해 같은 배경 그림 위에 레이아웃, 조명, FX 수정이 적힌 투명 필름을 차례로 포개는 것과 비슷합니다. 조명 작업자가 새 Layer에 조명을 더해도 레이아웃 원본 자체를 바꾸지 않는다는 점에서 비파괴 편집에 유리합니다.

다만 Layer가 언제나 별도 파일 하나를 뜻하는 것은 아닙니다. Solaris LOP가 만드는 Layer는 메모리에만 있다가 출력 때 저장될 수도 있고, 한 USD 파일이 여러 Layer의 합성 결과를 담을 수도 있습니다. 파일 수를 늘리는 것만으로 로딩이 줄지 않습니다. Layer는 수정 책임과 의견 강도를 관리하고, 로딩 최적화는 별도의 Load 설정으로 합니다.

LayerStack은 루트 Layer와 그 아래에 포함한 Sublayer들을 강도 순서대로 묶은 것입니다. 루트에 직접 작성한 의견이 가장 강하고, Sublayer 목록에서는 앞에 있을수록 뒤에 있는 Layer보다 강합니다. 같은 prim 경로와 같은 속성에 값이 다르면 강한 쪽이 이깁니다. 의견이 다른 경로에 있으면 서로 덮지 않고 Stage에 함께 남을 수 있습니다.

Sublayer는 같은 경로의 장면 설명을 포개는 방식입니다

Sublayer는 루트 파일에 다른 LayerStack을 순서대로 포함합니다. 프림 이름을 바꾸어 다른 위치에 붙이는 기능이 아니라, 같은 장면 경로에 있는 내용을 겹쳐 보는 방식입니다. 예를 들어 `layout.usda`가 `/World/Prop`의 위치를 만들고, `lighting.usda`가 같은 경로의 조명 속성을 추가하며, `shot_fix.usda`가 특정 샷의 위치나 표시 상태를 바꾸는 식으로 나눌 수 있습니다. 새 레이어를 추가해도 기존 레이어를 직접 덮어쓰지 않아 여러 부서의 수정 책임을 분리하기 좋습니다.

# shot.usda의 간단한 예
(
    subLayers = [
        @look_A.usda@,
        @look_B.usda@,
        @asset.usda@
    ]
)

목록 첫 번째인 `look_A.usda`가 `look_B.usda`보다 강하고, 둘 다 루트에 직접 쓴 의견보다는 약합니다. 같은 속성 `user:rank`에 asset이 10, look_A가 20, look_B가 30을 썼을 때, 목록이 A 다음 B라면 최종값은 20입니다. 앞의 두 파일을 바꾸면 30이 됩니다. 루트 `shot.usda`에 40을 직접 쓰면 목록 순서와 관계없이 40이 이깁니다. 이 값은 Houdini 19.5.435의 hython에 포함된 USD 22.5로 작은 `.usda` 예제를 열어 확인한 결과입니다.

Solaris의 Sublayer LOP는 디스크의 Layer를 가져오며, 뒤의 LOP 노드는 대개 더 강한 오버라이드 Layer에 편집을 기록합니다. 원본 파일을 바꾸지 않고도 수정할 수 있습니다. 값이 다르면 편집 Layer와 LayerStack 위치, Sublayer 순서를 확인하세요.

Reference는 에셋 계층을 다른 위치에 재사용합니다

Reference는 외부 USD의 prim 계층을 현재 Stage의 지정한 prim 아래에 합성합니다. 복사본을 만드는 대신 원본을 가리키므로 같은 소품을 여러 위치에 놓거나 캐릭터를 여러 샷에서 재사용할 때 적합합니다. 기준 에셋이 갱신되면 참조하는 Stage에도 구성이 반영될 수 있습니다.

# asset.usda
(
    defaultPrim = "Asset"
)
def Xform "Asset" {
    def Cube "shape" {
        custom int user:rank = 10
    }
}

# shot.usda: Asset의 기본 prim을 /Prop 아래에 참조
over "Prop" (
    prepend references = @asset.usda@
) { }

`defaultPrim`은 참조할 때 기본으로 가져올 루트 prim을 지정합니다. 없으면 참조 쪽에서 prim 경로를 명시해야 할 수 있습니다. Solaris의 Reference LOP로 에셋 계층을 장면 경로에 붙일 수 있습니다. 하위 prim이 안 보이면 파일 경로, 대상 prim, defaultPrim을 확인하세요. 참조된 계층은 원본과 다른 Stage 경로 아래에 놓일 수 있습니다.

Reference는 지연 로드를 뜻하지 않습니다. 반복 배치는 Reference, 큰 장면에서 일부만 늦게 불러오려는 경우는 Payload와 Load 설정을 함께 검토하세요.

Payload는 필요할 때 여는 지연 로드용 참조입니다

Payload는 외부 prim을 합성하는 참조로, Stage를 LoadNone으로 열거나 해당 prim을 미로드하도록 설정한 뒤 필요할 때 Load하거나 Unload할 수 있습니다. 창고에 목록을 두고 필요한 상자만 가져오는 것과 비슷합니다. 언로드하면 다른 Stage 데이터는 남고 해당 Payload 경계 안쪽 내용만 합성에서 빠집니다.

# payload.usda에서 /PayloadAsset 아래에 연결
over "PayloadAsset" (
    prepend payload = @asset.usda@
) { }

# pxr.Usd를 사용하는 로드 예
stage = Usd.Stage.Open("payload.usda", load=Usd.Stage.LoadNone)
stage.Load("/PayloadAsset")
stage.Unload("/PayloadAsset")

작은 예제를 `LoadNone`으로 열면 `/PayloadAsset`은 남고 `/PayloadAsset/shape`는 보이지 않았습니다. `Load(‘/PayloadAsset’)` 뒤 하위 prim과 값 10이 나타났고, 다시 `Unload(‘/PayloadAsset’)`하면 하위 prim이 빠졌습니다. 파일이 열리는지만 보지 말고 로드 전후의 경로와 prim을 비교하세요.

주의할 점은 Houdini 19.5가 기본으로 Payload를 모두 로드한다는 것입니다. 기본 로딩이 전체라면 모든 데이터가 합성됩니다. Configure Stage LOP의 `Load Primitives`와 `Load Paths`에서 작업할 prim만 선택하세요. Payload를 붙이는 것만으로는 로드 범위가 바뀌지 않습니다.

Scene Graph Tree의 viewport load mask와 Configure Stage의 Stage load 설정도 다릅니다. 전자는 뷰포트 표시를 제한하고, 후자는 이어지는 LOP가 처리할 Payload를 제어합니다. 뷰포트에서 안 보이는데도 네트워크가 무거우면 Stage의 load set을 줄였는지 확인하세요.

Variant Set은 대안을 고르는 기능이지 언로드 기능이 아닙니다

Variant Set은 prim 아래 대안 구성을 묶고, 선택한 variant 하나를 Stage에 합성합니다. 캐릭터 의상, 소품 손상 상태, 모델의 proxy와 hero처럼 같은 에셋의 모양을 바꿀 때 씁니다. `look`에 `clean`, `dirty`를 두면 선택된 룩이 활성 구성이며, 선택은 Layer에 기록할 수 있습니다.

Variant는 버전 선택, Payload는 지연 로드입니다. 한 에셋의 대안 중 하나만 고르는 요구에는 Variant, 큰 데이터를 늦게 열려는 요구에는 Payload를 보세요. 둘을 함께 쓸 수도 있습니다. 바꿔도 모습이 그대로라면 선택 prim과 variant 이름, 더 강한 Layer의 직접 의견을 확인하세요.

USD 강도 순서는 같은 속성에서 누가 이길지 정합니다

각 Layer는 특정 prim과 속성에 대한 의견을 남길 수 있습니다. USD는 모든 값을 단순히 평균하거나 가장 최근에 저장한 파일의 값을 쓰지 않습니다. 같은 위치의 같은 속성에 충돌하는 의견이 있으면 composition strength 규칙에 따라 더 강한 의견을 선택합니다. 이를 이해하면 “왜 내 룩 값이 안 먹지?” 같은 상황에서 임의로 값을 여러 번 바꾸지 않고 어느 Layer가 이기는지 찾을 수 있습니다.

Houdini 19.5 Solaris 문서가 설명하는 전통적 강도 순서는 LIVRPS입니다. 강한 쪽에서 약한 쪽으로 Local(현재 LayerStack과 Sublayer 의견), Inherits, Variant Sets, References, Payloads, Specializes 순입니다. 이 중 Local 내부에서는 루트 Layer가 가장 강하고, Sublayer 목록의 앞쪽이 뒤쪽보다 강합니다. 예를 들어 화면의 현재 shot Layer가 `user:rank = 40`을 쓰고 참조 에셋이 10을 쓰면 40이 남습니다. 반대로 shot Layer가 해당 속성에 의견을 쓰지 않으면 Reference 쪽 값이 보일 수 있습니다.

최신 OpenUSD 26.08 공식 Glossary는 Relocates라는 composition arc를 강도 순서에 추가해 LIVERPS라고 부릅니다. 이때 순서는 Local, Inherits, Variant Sets, Relocates, References, Payloads, Specializes입니다. Houdini 19.5 문서의 LIVRPS 설명과 최신 OpenUSD 문서의 LIVERPS를 한 목록으로 섞지 마세요. Houdini 19.5.435에 포함된 USD 22.5로 확인한 실험은 Local/Sublayer와 Reference, Payload 동작이며 Relocates의 지원 여부를 확인한 것은 아닙니다. 현재 쓰는 Houdini와 USD 버전에 맞는 문서를 기준으로 삼으세요.

체험기는 같은 속성에 한 번씩 값이 있다고 가정하는 단순 모델입니다. 예시값은 루트 40, Sublayer 20·30, Reference 10, Payload 5이며 루트가 이깁니다. 루트를 지우면 첫 Sublayer 20이 선택됩니다. 실제 USD는 여러 prim과 arc, 시간 샘플, 리스트 편집 등도 함께 평가합니다.

무거운 씬은 수정 책임, 에셋 재사용, 실제 로드 범위를 순서대로 나눕니다

파일을 잘게 쪼개기 전에 달라지는 데이터를 적으세요. 레이아웃, 애니메이션, 조명, FX 캐시처럼 수정 책임이 다르면 Layer를 나눕니다. 같은 소품을 여러 위치에 배치하면 Reference를 쓰고, 그중 지금 열지 않을 큰 지오메트리는 Payload 경계 안에 둘 수 있습니다.

1. 같은 prim을 누가 고치는지 정하세요. 레이아웃과 조명처럼 수정 책임이 다른 데이터를 Layer로 구분하고, 어떤 Layer가 강해야 하는지 정리합니다. 값이 예상과 다르면 루트와 Sublayer 순서를 확인하세요.
2. 반복해서 쓰는 에셋을 Reference로 연결하세요. Stage에 에셋을 둘 위치와 참조할 파일 안의 prim 경로를 맞춥니다. 파일을 열었는데 자식이 없다면 defaultPrim 또는 명시 경로를 확인하세요.
3. 한 번에 열지 않을 덩어리만 Payload로 분리하세요. 큰 메시가 있는 prim에 Payload 경계를 두고, 지금 필요한 샷·부서의 경로만 Load할 수 있는지 확인합니다. 매 프레임 보거나 모든 노드가 써야 하는 데이터라면 무조건 언로드하는 것이 더 나은 것은 아닙니다.
4. Configure Stage LOP에서 로드 규칙을 정하세요. 기본값이 전체 Load인지 살펴보고, `Load Primitives` 설정으로 대상 경로를 조절하세요. Scene Graph Tree에서 화면만 숨긴 것과 Stage의 로드 집합을 바꾼 것을 혼동하지 마세요.
5. Stage를 다시 열어 구조와 값을 검증하세요. 필요한 prim은 보이고 제외한 Payload 하위 prim은 빠졌는지, 같은 속성 값은 의도한 Layer에서 왔는지 확인하세요. 저장한 USD를 다시 열어 참조 경로와 prim 구조를 확인하고, Payload 로드 규칙은 새 Stage나 LOP에서도 의도한 대로 설정됐는지 별도로 확인하세요.

파일을 나누는 것 자체가 속도 개선을 보장하지는 않습니다. 실제 반응 속도와 메모리는 에셋 크기, 저장 장치, resolver, LOP에서 요구하는 데이터에 따라 달라집니다. 같은 작업 범위와 설정에서 본인의 씬을 비교하세요.

값이 안 바뀌거나 씬이 여전히 무거울 때 확인할 것

Payload를 넣었는데 전체가 계속 보입니다. Solaris 기본 로드 설정이 모든 Payload를 포함하고 있을 수 있습니다. Configure Stage LOP의 `Load Primitives`에서 필요한 경로만 로드하도록 바꿔 보세요. 뷰포트에서만 감춘 상태라면 후속 LOP가 같은 데이터를 계속 처리할 수 있습니다. 씬이 느리다는 이유만으로 Reference를 Payload로 치환하기보다, 실제로 Load 규칙이 바뀌었는지 먼저 확인하세요.

Reference 파일은 연결됐는데 하위 prim이 안 보입니다. 참조된 파일의 defaultPrim이 올바른지, 선택한 경로가 존재하는지 확인하세요. 최상위 `/`가 아닌 실제 에셋 루트 prim을 참조해야 하는 흐름일 수 있습니다. 또한 경로가 상대 경로라면 USD 파일의 위치를 기준으로 올바르게 해석되는지 확인합니다. prim이 다른 네임스페이스 아래에 붙는 것은 Reference의 동작이므로, 원본 경로와 Stage 경로가 같을 것이라고 가정하지 마세요.

오버라이드 값을 넣었지만 결과가 바뀌지 않습니다. 먼저 그 속성이 정확히 같은 prim 경로에 기록됐는지 확인하세요. 그다음 편집 대상이 활성 Layer인지, 그 Layer가 더 강한 의견을 담고 있는지 봅니다. LayerStack의 루트와 Sublayer 순서를 바꾸면 같은 속성의 승자가 달라질 수 있습니다. 값을 강제로 다시 쓰기 전에 Stage에서 해당 속성의 의견이 어느 Layer에서 왔는지 추적하면 원본 데이터를 불필요하게 고치지 않아도 됩니다.

Variant를 바꿔도 외형이 그대로입니다. 선택이 실제로 그 prim의 Variant Set에 기록됐는지, 화면에 보이는 prim이 그 에셋의 참조 결과인지 확인하세요. 다른 Layer에 저장된 직접 의견이 더 강하면 선택된 Variant의 속성이 가려질 수 있습니다. variant 안의 지오메트리가 너무 무거워 작업 중 제외하려는 요구라면 Variant 선택만으로 로딩이 지연된다고 기대하지 말고 Payload와 함께 구성하세요.

무엇을 나눌지 마지막으로 결정하는 기준

상황	먼저 선택	다음 확인
같은 장면을 부서별로 수정하고 원본을 보존	Layer / Sublayer	같은 prim 경로, LayerStack 순서
하나의 에셋을 여러 위치에 반복 배치	Reference	defaultPrim, 대상 경로, 파일 해석
큰 에셋 중 일부만 지금 작업	Payload	실제 Load/Unload 규칙
같은 에셋의 여러 모양 중 하나 선택	Variant Set	현재 선택과 더 강한 오버라이드

Layer/Sublayer는 의견을 겹치고, Reference는 에셋을 재사용하며, Payload는 필요한 내용만 불러오게 하고, Variant Set은 대안을 선택합니다. 수정 단위와 에셋 경계를 나눈 뒤 Payload 로드 규칙을 조절하고, 결과 prim과 속성의 출처를 확인하세요. Solaris 기본값은 전체 Payload 로드입니다.

공식 문서