Instance Attributes: Precedence and Nested Realization

Instance Attributes require more than a list of duplicated shapes. An instance can reference shared geometry while carrying information at the instance level. When that structure is converted into real geometry, Blender 4.5 defines rules for attribute propagation, name conflicts, data types and nested levels. Those rules determine which information accompanies the resulting geometry.

A reference and its base geometry can carry different information

Blender's official instances explanation describes instances referencing geometry, objects or collections without duplicating the underlying data. Each instance records its referenced geometry and its transformation relative to that source.

The representation therefore has a reference level as well as the geometry it points to. A property associated with an instance and a property stored on its base geometry can exist at different levels even when their visible shapes occupy the same location. Realizing that structure requires a data rule, not just another copy of a rendered image.

Realization propagates attributes to the resulting geometry

The official Realize Instances reference says named and anonymous attributes propagate from the instance domain to the realized geometry. It also explains that realization makes instance geometry available for individual processing.

This propagation relationship is separate from the familiar reason to realize instances before computing one envelope around combined geometry. An envelope question concerns which points are enclosed; the attribute question concerns which values accompany the geometry after conversion. Both can occur in one node system without having the same answer.

Base-geometry values take precedence in a name conflict

The reference explicitly states that when an attribute exists both on the base geometry and on an instance, the values from the base geometry take precedence. An instance-level value is therefore not a universal override merely because the instance is closer to the final output of a diagram.

Consider a purely illustrative attribute named category stored at both levels. The documented conflict rule determines the source of the resulting values. Merely knowing the two attributes have the same name does not tell a reader which value wins unless that precedence rule is retained.

Merging can change the resulting attribute type

When attributes from multiple geometry inputs are merged, Blender chooses the highest-complexity data type for the output attribute. The reference gives an example in which a Boolean attribute on one input and a vector attribute of the same name on another produce a vector attribute in the output.

The example concerns the type used to represent the merged data. It should not be read as a statement that every input value was already a vector, or that attribute names alone guarantee identical data interpretation. Type and name remain separate parts of the attribute record.

Identifiers receive a special combination rule

The id attribute receives separate handling to avoid duplicate values. Instance identifiers or indices are combined with identifiers from geometry data points. This is a specific rule for identity across the realized result, rather than a promise that every id is copied unchanged from only one source level.

The same reference also discusses vertex-group preservation and its relation to domain and type propagation. A resulting vertex-domain floating-point attribute can be represented as a vertex group on the output mesh. This gives another reason to retain domain and type information alongside the attribute name.

Nested structures introduce a depth question

Instances can themselves contain geometry that includes more instances. Blender's instances page calls this nested instancing. The Realize Instances node consequently distinguishes selected top-level instances from the number of nested levels to realize.

The Depth input specifies the number of levels for each top-level instance. Realize All overrides that depth choice and realizes all nested levels for the selected top-level instances. Selecting a top-level member and choosing how deeply to traverse it are therefore distinct decisions in the documented data model.

The instances page separately limits rendering and viewport display to eight nested levels. Deeper structures can exist inside geometry nodes but must be realized at the end for that display context. The existence of a data structure and its supported display depth are thus separate limits.

Data expansion has a processing cost

The instances explanation relates shared data to processing each unique geometry once, while realization requires processing the resulting individual geometry and uses more memory. The node reference also limits multiple volume instances: only the first volume component moves to the output.

Both complete Blender 4.5 pages were read on November 6, 2026. The original diagrams identify attribute precedence and nested levels without running a node tree or inventing benchmark results. Related learning appears in the procedural geometry category and technical reference directory. Names, types, domains and traversal depth together explain the information produced by realization.