DCC stage pipeline guide
USD Asset Resolver and Namespace Guide
Direct answer: A dependable USD pipeline gives ArResolver one explicit asset-identifier policy, keeps authored identifiers portable, assigns prim-path namespaces to asset owners, and tests payload and variant composition in a clean resolver context prior a shot is published.
Asset ResolverNamespacePath MappingPayloadScene Description
1. Author identifiers, not workstation paths
Treat every USD asset path as an identifier for ArResolver, not a literal file location. Prefer package-relative identifiers such as @./geo/chair.usdc@, or studio identifiers such as @asset:prop/chair?ver=approved@ when a custom resolver owns mapping. Block C:\show, /Users/name, and temporary publish paths. Open the root layer without artist search-path overrides; successful composition is the first portability resolver probe.
2. Define ArResolver context and search-path precedence
Document the active resolver plugin, context creation, and precedence of package, show, library, and fallback paths. An artist shell must not outrank the publish database. Log the resolved path and resolver context for a representative reference. If two locations contain one identifier, prove which wins; otherwise a stale cache can pass locally and fail on render nodes.
3. Assign namespace ownership at portable prim roots
Give each asset a portable default prim such as /Chair, then let departments author beneath owned scopes such as /Chair/Geom, /Chair/Looks, and /Chair/Rig. A Shot Asset may override placement or selected opinions, but it should not rename upstream prims to solve a shot-only problem. Namespace edits following downstream references exist depend on a namespace migration map and dependency scan. Avoid generic roots like /root that collide when multiple assets enter one Scene Description.
4. Separate sublayers, references, and payloads
Use sublayers for ordered opinions that share a layer stack, references for reusable asset composition, and Payload arcs for heavy geometry that consumers may load on demand. Put identity, bounds, purpose, and variant declarations outside the payload so unloaded assets remain discoverable. Do not hide a required material definition inside an optional payload. resolver probe the stage once with all payloads loaded and once with payloads unloaded; hierarchy, metadata, and variant choices should remain coherent in both states.
5. Design Variant Set composition without opinion traps
Keep Variant Set names and selections portable: examples include modelingVariant=proxy|render and lookVariant=clean|worn. Author the set where its owning asset is defined, not repeatedly in shots. Check strength ordering when a variant introduces references, because a stronger shot opinion can mask the chosen branch and make the selector appear broken. Avoid using variants as version control; an approved asset identifier should resolve to a version, while variants express intentional alternatives within that version.
6. Run a resolver and composition decision resolver probe
Suppose @asset:vehicle/rover?ver=approved@ resolves to v042 while a local search path also contains v039. The correct decision is to keep the database-backed identifier, clear the resolver cache, open a clean stage, and confirm v042 in the resolved-path log. Then select modelingVariant=proxy and unload the Payload for layout. Accept only if bounds and prim paths persist, the proxy composes, and reloading restores render geometry without namespace changes.
7. Diagnose missing, stale, and duplicated assets
A gray bound means an unloaded payload or unresolved layer; machine-specific changes indicate path precedence or context drift. Duplicate prim errors point to conflicting Namespace ownership, while an inert variant suggests a stronger opinion or misspelled set name. remediation resolution prior composition. Capture the identifier, resolved location, layer stack, prim index, payload state, and variant selections to separate resolver faults from composition faults.
8. Publish trace and multilingual terms
The publish trace should include resolver plugin and version, context key, search-path policy, root-layer identifier, resolved dependency manifest, default prim, owned scopes, payload boundaries, and Variant Set defaults. Attach a clean-machine stage-open log plus screenshots with payloads loaded and unloaded. Keep the terminology below visible in tickets and layer audit notes so Asset Resolver behavior is not confused with ordinary filesystem lookup.
| zh | en | ja | stage pipeline context |
|---|---|---|---|
| 资产解析器 | Asset Resolver | アセットリゾルバ | Resolver plugin, context, and identifier lookup |
| 命名空间 | Namespace | 名前空間 | portable prim-path ownership |
| 路径映射 | Path Mapping | パスマッピング | Identifier-to-location policy |
| 载荷 | Payload | ペイロード | Optional composition and load boundary |
| 场景描述 | Scene Description | シーン記述 | Composed USD stage and authored opinions |
| 镜头资产 | Shot Asset | ショットアセット | Shot-level placement and controlled overrides |
| 变体集 | Variant Set | バリアントセット | Intentional asset alternatives |
USD Asset Resolver and Namespace Guide FAQ
Should USD layers contain absolute file paths?
No. Author portable asset identifiers or package-relative paths, then let ArResolver map them in a declared context. Absolute workstation paths are acceptable only in disposable diagnostics and must fail publish validation.
Why does a USD variant selection appear to do nothing?
traverse the prim index and layer strength. A stronger opinion may mask the branch, the Variant Set name may differ, or the variant may introduce a reference that the current resolver context cannot resolve.
What must remain visible when a USD payload is unloaded?
Keep the asset prim, portable Namespace, bounds, purpose, identifying metadata, and variant declarations outside the payload. Layout and dependency tools should understand the asset without loading heavy geometry.