ZenFG

A composable FrameGraph for WebGPU and wgpu.

Build rendering features, compose GPU systems, and understand every frame.

YOUR FRAME, YOUR DESIGN

Build independently. Bring it together.

Keep control of scenes, materials, pipelines, and rendering policy. Give ZenFG explicit dependencies and resource accesses to coordinate the frame.

Connect an existing engine

Let a renderer keep its own commands and submissions. Declare its shared inputs and outputs as an external node, then combine it with work before and after that boundary.

Build graph-native modules

Use native WebGPU or compatible libraries to build domain-specific rendering and compute. Record nodes into the graph so their declared passes and resource flow can be inspected.

ComputeGraph-visible work

External rendererInternal passes stay opaque

Render / compositeGraph-visible work

Output

Conceptual composition on a shared device and queue. Edges represent declared resource flow and ordering; the application supplies compatible resources and access declarations.

Explore the three integration levels →

RUNNING EXAMPLES

See composition in practice.

Each example connects real GPU work to an inspectable frame graph. Open the result, follow its resources, and read the source.

NATIVE WEBGPU

Reference Renderer

GPU culling and indirect drawing, built without an engine dependency. A teaching renderer with an explicit Reset → Cull → Draw flow.

Open example ↗ SHARED COLOR + DEPTH

Three.js · Co-rendering

Three.js and a custom renderer draw into shared color and depth attachments. Their objects occlude each other in one scene.

Open example ↗ EXTERNAL ENGINE · NETWORK REQUIRED

PlayCanvas Streaming GSplat

Combine streaming Gaussian splats with custom drawing and compositing. Scene data loads from a remote host.

Open example ↗ COMPUTE + RENDER

TypeGPU · Slime Mold

TypeGPU defines shaders and pipelines; ZenFG connects native compute and render nodes through persistent simulation resources.

Open example ↗

Each example documents its dependency versions and integration details.

SNAPSHOT + INSPECTOR

Understand the frame you actually built.

Follow declared dependencies, resource lifetimes, and diagnostics. Inspect optional CPU/GPU timings alongside the structure that explains them.

Three.js and the Reference Renderer sharing a scene, alongside their actual captured ZenFG frame graph — Three.js · Co-rendering — a real rendered scene and its captured graph. The external renderer appears as a boundary, alongside visible native passes.

Capture
Capture an actual frame and locate the passes and resources that matter.
Analyze with context
Export Snapshot JSON with relevant code for human or AI-assisted analysis. Use the Inspector to give precise feedback about the flow.
Change and verify
Capture again after changes. Check the resulting graph and available timings rather than assuming an optimization worked.

External-engine internals stay opaque. GPU timing depends on device support and node coverage. Snapshots describe declared work; they contain neither replayable GPU commands nor resource contents.

Read the Inspector workflow →

TypeScript / Rust

One toolchain. Two ecosystems.

Idiomatic runtimes with shared semantics and portable diagnostics.

Resource management

Manage resources. Catch issues early.

Track dependencies, manage lifetimes, and reuse transient resources.

Snapshot & Inspector

Understand every frame.

Capture, navigate, and inspect your frame graph.

Start with your GPU stack.

WebGPU / TypeScript wgpu / Rust

The runtimes share semantics and portable snapshots, with idiomatic APIs for each language.

Toward reusable rendering building blocks

We are exploring reusable GPU-driven mesh, particle, and post-processing modules: independently built features that can come together in real applications.