ShaderWeave

A final image hides the program that produced it. ShaderWeave puts source editors, resource connections and live previews in one workspace. Each pass can be edited and inspected on its own, then connected to a larger system.

A fragment shader can remain a compact sketch. A larger experiment can combine persistent simulations, intermediate images and heterogeneous GPU work without hiding their dependencies inside one long program.

The desktop engine uses OpenGL/GLSL, including compute passes and persistent resources, with separate CUDA and OptiX integrations. Related browser experiments in WebGPU Atelier and RIVX explore similar graph ideas through their own implementations.

The workbench is my project; several shader artworks running inside it come from other creators. Those examples demonstrate importing, connecting and modifying GPU programs. Their original visual designs are credited separately below.

• Edit a pass: source and injected program remain available beside the output.
• Connect an image: a producer becomes an input to another stage.
• Retain state: old and new resources make frame history explicit.
• Inspect the consequence: compare intermediate previews before judging the final composite.

ShaderToy-style programs enter through the source library or pasted code. The wrapper supplies the expected entry point and familiar inputs such as time, resolution, mouse state and channels.

Raw and injected source views show both the authored program and the declarations presented to the driver. Expected buffers, samplers and feedback history still need matching graph resources; universal ShaderToy compatibility has not been established.

The editor derives resource sockets from shader declarations and recognized conventions. Read-only and write-only image access, texture dimensions and resource roles remain visible instead of collapsing every connection into an untyped wire.

Hot swapping replaces the producer of an input while retaining the downstream processing chain. An image, generated texture or rendered view can feed the same effect when its interface is compatible. This is useful for testing what belongs to the algorithm and what belongs to its source data.

The dynamic skybox example extends the idea to a surrounding environment. The environment is a resource supplied by the graph, so changing its producer can alter the scene without rebuilding the whole composition. The practical boundary is compatibility: dimensions, formats and update behavior still need to match the consumer.

CUDA nodes compile through NVRTC and supply image results through registered GPU resources. OptiX nodes provide programmable ray traversal and custom output. Both can become sources for downstream GLSL work, while retaining separate compilation, launch and synchronization requirements.

The phase-oriented OptiX recording belongs to custom ray programs and their accumulation model. OptiX itself is not a wave-equation solver. CUDA and OptiX require the corresponding NVIDIA runtime and hardware.

A persistent simulation must distinguish the state being read from the state being written. Ping-pong resources supply that distinction: one image contains the previous state, another receives the next state, and their roles swap after the update. A feedback edge therefore means a temporal dependency, not an instruction to recursively evaluate a cycle in the same frame.

The SmoothLife and compute examples make the dependency visible. The recording with ping-pong buffering disabled is deliberately a failure demonstration: simultaneous reads and writes create a conflict, and the resulting appearance is not a valid alternative simulation. Accumulation buffers use the same resource idea for a different purpose, retaining previous contributions instead of evolving a local field. Resetting their history is part of changing the experiment.

A rolling volume writes each source frame into another depth slice. The storage wraps; the viewer unwraps it into chronological order. A moving image becomes an inspectable time stack.

The documented example can record a shader, image, editor, screen or simulation. Volume depth sets the retained number of frames, while display rate determines how those frames relate to elapsed time. The small mutable volume is a practical starting resource.

Images, HDR environments and supported geometry or volume resources can be loaded, connected and inspected in the workspace. Drag-and-drop reduces the cost of replacing an input without rebuilding its consumers.

Viewers expose orientation, dynamic range and empty or unexpected output. Asset compatibility remains specific: HDR data needs meaningful exposure, volumes need a viewing convention, and a model needs attributes expected by its shader. Video-file drops currently report that decoding support is pending.

The editor and node workspace can render into framebuffers and become image inputs themselves. The same shader graph can project text into a scene or transform its own interface.

The editor also exposes desktop and selected-window capture. Windows capture paths try a modern texture source and retain platform fallbacks; an explicit capture-node control and window selector govern the input. Capture compatibility depends on the application and the available Windows capture path.

The application keeps intermediate images and active connections visible, so a problem can be traced back to the pass that introduced it. The launched build uses the implementation in legacy_sw; despite the folder name, this is the current desktop application. A second graph implementation at the source root remains separate.

The active path builds a render plan from connected components, the projected node and selected special outputs. It caches that plan by graph/selection revisions and visits each node once while constructing the preview order. Separate preview and viewer paths can still request additional evaluations; the plan alone does not guarantee one GPU execution per node per frame.