Scene Graphs, Composition, and Variants: What a Flattened Scene Can Change

A visual scene is often a graph of relationships, not a folder of independent meshes. Parent transforms, instances, layer opinions, references, payloads, variants, overrides, and asset paths can all affect the scene a receiver resolves. Flattening may make delivery easier, but it changes which relationships remain available.

The scene graph carries meaning

At the visible level, a scene graph describes objects and their hierarchy. A child’s transform is interpreted in relation to its parent. Reuse through instances can keep repeated assets connected to a common source. Names and namespaces let a recipient identify the object that a camera, material, animation, or downstream override targets.

In USD, these visible relationships are combined with composition arcs:

Mechanism	What it contributes	What to verify
Layers and subLayers	Ordered, nestable opinions that contribute to a layer stack.	Which layers are present, their order, and the resolved opinion for critical properties.
Reference	Composes a target prim tree into another prim.	The target path, referenced file, namespace, and resolved geometry or assets.
Payload	Defers a reference so a client can load or unload part of the scene.	The initial load state, the parts required for the task, and behavior when the payload is loaded.
Variant set	Bundles alternatives that a consumer can select.	Selected variant, available alternatives, and whether the receiver exposes the selection.
Override	Supplies a stronger opinion over an existing composed value.	Which layer supplies the override and whether it survives the chosen delivery operation.
Asset path	Names an external file or other resource for the resolver to locate.	The path, resolver, search paths, and context available to the recipient.
Transform stack	Records ordered component operations and whether inherited transforms are reset.	Operation order, reset state, hierarchy, and representative time samples.
Point instancer	Connects ordered prototypes to per-instance indices, transforms, identities, and masks.	Prototype order, protoIndices, positions/orientations/scales, IDs, masks, and time-varying state.

The important question is not whether the source contains a file with the expected extension. It is whether the receiver can resolve the same relationships and select the same state.

References and payloads are not interchangeable

A reference assembles a target tree into the referencing prim. A payload is a deferred reference that can be selectively loaded after a stage opens. This makes a payload useful for managing a working set, especially in a large scene, but it also introduces a load-state requirement for the handoff.

If the delivery test checks only the initially visible portion of a scene, it may miss a payload that contains a required asset, animation, or high-detail variant. Test the load state that the recipient will actually use, and record whether the scene was inspected with the relevant payloads loaded.

Instances need more than a count

An instanced scene can look plausible while its instance relationships have changed. USD UsdGeomPointInstancer keeps an ordered relationship to prototype prims or subtrees. Each instance selects a prototype with protoIndices and carries per-instance positions, orientations, and scales; optional IDs, velocities, and invisible or inactive ID masks add more state.

Compare the prototype relationship and ordering before comparing the visible result. Check that every index still selects the intended prototype, that per-instance arrays align, and that IDs and masks have the expected effect at the tested time. Expanding instances may be acceptable for a static delivery, but record that as a deliberate representation change rather than treating the expanded mesh count as proof of preservation.

Variants are finite states, not generic configurators

An OpenUSD VariantSet can bundle alternatives that a stronger layer selects without rewriting the source asset. The selection is part of the resolved state and should be recorded with the layer that supplies it. In glTF, the ratified KHR_materials_variants extension is narrower: it describes finite, premade, asset-level material choices through named root variants and primitive-level mappings. A conforming viewer can apply at most one active variant per asset instance, and primitives without a mapping fall back to ordinary glTF behavior.

Treat those mechanisms as different contracts. Test every required selection, its mapped primitives, and its fallback state in the named receiver. The extension’s ratified status or a valid VariantSet does not establish that an importer or renderer exposes the same choices.

Transform operation order is part of the scene

For USD transformable prims, xformOpOrder records the ordered component operations used to position a prim and its descendants. A prim may reset its inherited transform stack, and operation values may vary at authored times. Comparing only one final matrix can miss a changed order, inherited parent relationship, or animated sample.

When transforms are material to the handoff, compare the operation order, reset-stack state, local-to-parent or local-to-world result, and representative named times. If the receiving representation intentionally bakes these into matrices, retain the source composition or transform description when later edits or diagnosis may depend on it.

What flattening changes

USD flattening bakes composition into a single layer that no longer contains the original composition arcs. That can simplify transport and produce a self-contained result, but it can also remove the live relationships that made the source scene maintainable or selectable.

Flattening can also change delivery characteristics:

• repeated referenced data may be duplicated rather than shared;
• the resulting file may become much larger;
• the operation can be memory- and compute-intensive; and
• a receiver may gain a simple layer while losing the ability to update a source reference, switch a variant, or apply a layer-specific override.

The result is not automatically worse. It is a different deliverable. Flatten when the recipient needs a resolved snapshot and the loss of live composition is acceptable. Preserve the composed source when later updates, variant selection, dependency inspection, or selective loading matters.

Localization is a different choice

Localization gathers scattered layers into a coherent file tree and retargets references, payloads, and other asset paths to the copied files. Unlike flattening, it does not bake the whole composition into one layer. It can therefore retain more of the source relationships while making the dependency tree easier to move.

Localization still requires inspection. A retargeted path can be syntactically valid but unusable in a recipient with a different resolver, search path, package layout, or context. A package that contains the root layer can still name resources outside its boundary.

Compare the source and delivery states

Before and after flattening or localization, record the following:

1. Open the source with the intended load state and record the resolved root, active layers, payloads, references, and variant selections.
2. Compare hierarchy, namespaces, transform-operation order, reset state, representative time samples, instance prototypes, instance count, and object identity.
3. Check that the selected variants, primitive mappings, and important overrides produce the intended result.
4. Resolve every asset path from a clean copy or clean receiver context. Do not rely on the author’s search paths.
5. Load the same payloads and inspect the same views, materials, cameras, and animation clips.
6. Record what was deliberately baked, expanded, removed, or left dependent on a resolver.

Keep the composed source beside a delivery derivative when the next workflow may need updates or alternate variants. The derivative can be the convenient handoff; it should not become the only copy if its flattening decision removed relationships that later work depends on.

For the dependency and clean-receiver side of this comparison, see Package and Test a Visual Scene Handoff. For surface relationships that can also be affected by composition, see Materials, Textures, UVs, and Shader Bindings.