Rendering and Instancing Modes
OctoShaper can realize graph rows as ordinary GameObjects, conventional GPU-instanced draws, or indirect GPU draws. The graph can produce the same positions in every case; the final rendering node determines how Unity turns those rows into something visible.
The short version
Choose how much Unity object behavior you need
What batching and GPU instancing mean here
A mesh normally needs a draw submission that tells the GPU what geometry, material, and transform to use. Repeating that setup for every rock or blade of grass creates CPU work even when every copy looks nearly identical.
Batch rendering groups compatible rows—most importantly rows using the same mesh and material—and submits their transforms together. GPU instancing then draws those copies with shared geometry and material state while each instance keeps its own position, rotation, and scale.
Indirect drawing goes one step further: Unity reads the instance count and transform data from GPU buffers when it issues the draw. This reduces per-draw CPU submission work, but it does not make the whole OctoShaper graph GPU-only. OctoShaper still prepares and uploads instance transforms when the generated result is realized.
Compare the three realization modes
| Mode | What Unity creates | Good fit | Main tradeoff |
|---|---|---|---|
| GameObject | One object or prefab hierarchy per row. | Interactive objects, components, colliders, scripts, parenting, and spawn callbacks. | Object creation, hierarchy updates, component memory, and per-object work grow with the row count. |
| Draw Instanced | No individual objects; compatible transforms are drawn in batches of up to 1023 instances. | Repeated visual geometry that still uses a conventional instancing-compatible material. | No components or GameObject callbacks, and large populations require multiple batch submissions. |
| Draw Instanced Indirect | No individual objects; transforms and draw arguments live in GPU buffers. | Very large visual populations with a shader prepared for OctoShaper's indirect instance data. | The material setup is more specialized and the result has no per-instance Unity object behavior. |
GameObject assignment nodes
Each family has a Generator form that creates a new ElementSet with a requested count, and a non-generator form that assigns a rendering choice to rows already flowing through the graph.
One prefab
Spawn Prefab (Generator) creates the rows and assigns one prefab. Spawn Prefab assigns that prefab to existing rows.
Unity primitives
Create Primitive (Generator) creates rows for cubes, spheres, and other primitives. Create Primitive assigns a primitive to existing rows.
Independent weighted picks
Pick Weighted (Generator) and Pick Weighted select a prefab for each row from a weighted list using a deterministic seed.
Batch weighted sampling
Sample Weighted (Generator) and Sample Weighted fill the complete prefab column as one sampled batch. They honor the same list weights, but can produce a different deterministic sequence from Pick Weighted.
All of these paths produce real GameObjects when the graph output is realized. Use GameObject Callbacks when a spawned prefab hierarchy needs per-instance initialization.
Hierarchy nodes are for GameObject output
Create Parent Element creates one row that can represent a parent object. Assign Parent Element appends that parent and assigns the incoming rows beneath it with a stable sibling order.
GPU-instanced rows do not have transforms in Unity's object hierarchy. Keep parent and child rows in the GameObject path; a GameObject child cannot be attached beneath a GPU-instanced parent.
GPU rendering nodes
Draw Instanced
Marks every incoming row for conventional GPU-instanced drawing with the selected mesh, material, shadow mode, and receive-shadows setting.
Choose it when you want a simple transition away from GameObjects and the population is comfortable being divided into 1023-instance batches.
Draw Instanced Indirect
Marks every incoming row for buffer-backed indirect drawing with the selected mesh, material, and shadow settings.
Choose it for large visual populations after confirming that the material's shader supports OctoShaper's indirect instance-data convention.
Both nodes preserve or create the standard position, rotation, and scale attributes. Different mesh or material choices form different batches, so reusing a small set of combinations is usually more efficient than making every row unique.
A graph can mix rendering modes
OctoShaper partitions the final rows according to their rendering assignment. A graph can therefore keep a small set of interactive prefabs as GameObjects while drawing a much larger decorative population through GPU instancing.
Use mixed output deliberately
The branches may look similar in the Scene view, but only the GameObject rows participate in hierarchies, components, colliders, and spawn callbacks. Treat GPU rows as rendering data, not lightweight GameObjects.
Choose a mode by behavior first
- Start with GameObjects when generated instances need gameplay behavior, individual physics, or hierarchy access.
- Move purely visual repeated geometry to Draw Instanced when the material supports GPU instancing.
- Use Draw Instanced Indirect when the population is large enough to justify a specialized indirect shader and buffer-backed draw.
- Measure the real scene. Fewer GameObjects and draw submissions usually help, but shader cost, shadows, overdraw, graph regeneration, and mesh complexity still matter.
For a complete indirect-rendering example, continue with GPU-Accelerated Grass.