A Pixel Composer node runs a Pixel Composer Graph inside a Standard Graph. The source defines the per-pixel algorithm; the instance decides which textures and public values it receives, its processing context and seed, how many iterations it runs, and—when the source allows it—whether the result is Color or Grayscale.
Pixel Composer Instances
Configure a reusable Pixel Composer Graph through ordered texture inputs, exposed parameters, output mode, resolution, seed, iterations, groups, and visual gizmos.
Use a Pixel Composer Graph as a Reusable Texture Node
Create the Instance & Read Its Interface
Inside a Standard Graph, add Shift+A → Generators → Pixel Composer, expand Parameters, and choose the source Pixel Composer Graph. WonderTexture reads the public schema and rebuilds the node around it.
Use Graph Properties → Interface → Input Texture Order in the source to control texture-socket order. One PC Input can be marked as the Primary Input, providing source context for input-dependent behavior and iterative feedback.
Parameters, Groups & Seed
Exposed source parameters become instance-specific values, so several Pixel Composer nodes can share one source while using different Strength, Offset, Rotation, or other settings. Compatible parameters also become value sockets; a connected socket overrides the stored static value during evaluation.
Groups authored in the source carry into supported instance interfaces and can be collapsed while Parameters are open.
If a source Integer is authored as the graph-seed control, WonderTexture uses the instance’s main Random Seed as that runtime context rather than exposing a second ordinary seed control.
Iterations, Processing Context & Output Mode
Pixel Composer instances use WonderTexture’s standard output-size and precision context. The resolved dimensions determine how many pixels execute the source logic. For inheritance modes and texture formats, see Core Concepts → Resolution & Precision.
Iterations defaults to 1 and supports 1–1024. Higher values repeat the operation so the source can use previous-pass feedback, while $iteration and $total_iterations let its logic react to the current pass.
The source PC Output defines the result contract. Grayscale produces a Grayscale result, Color produces Color, and Relative to Input adapts to source texture context. When PC Output is User Defined, each instance receives an Output Mode choice between Grayscale and Color.
Pixel Composer also receives WonderTexture’s standard Tiling context, which the source can inspect through $tiling. This is separate from Repeat/Clamp behavior on individual texture-sampling operations.
Optional Transform Gizmo
A source graph can enable Graph Properties → Pixel Composer Settings → Enable Transform Gizmo so compatible instances participate in WonderTexture’s transform-gizmo workflow. The current convention recognizes exposed controls named Center X, Center Y, Half Width, Half Height, Rotation, Anchor Offset X, and Anchor Offset Y.
The gizmo edits those public parameters; the source Function logic still determines what the values actually do.
Source Changes & Re-Syncing
The instance depends directly on the source schema. Adding or removing PC Inputs, changing their order or Primary status, changing public parameters, Labels or Groups, or changing PC Output behavior can rebuild the interface.
Configured instances provide Re-Sync Source Graph for the current relationship and Re-Sync All Instances for compatible instances across the Blender project. These are recovery and schema-refresh tools; normal source edits should continue through WonderTexture’s automatic update workflow.
Treat the Pixel Composer like a custom texture node: keep texture inputs ordered logically, choose the correct Primary Input, expose only useful controls, provide sensible defaults, and enable specialized features such as multiple iterations or the Transform Gizmo only when they improve the asset.
For the full recovery workflow, see Source Changes & Resyncing.