A rendering pipeline is easier to improve when every pass has a clearly stated job. Start with the image your application needs, then work backward through the resources required to produce it.
The original research draft combined API architecture, shader development, textures, mobile behavior, and speculative benchmarks into a single “complete” guide. This revision focuses on the engineering decisions that remain useful without a universal speed claim.
Describe the frame
Write down the output of a frame in ordinary language. A customer should see the selected building, its material choices, plausible lighting, a readable selection highlight, and dimensions that agree with the configuration.
Then identify the passes: perhaps shadows, the main opaque scene, transparent objects, selection, and tone mapping. Add a pass only when it serves a visible requirement. Each extra target carries allocation and bandwidth costs even if the code looks compact.
A frame graph is useful when it records which pass writes a resource and which later pass reads it. It should reveal dependencies and lifetime, not merely decorate an architecture document.
Stabilize the material contract
Record texture channels, color interpretation, coordinate conventions, and material parameters. A roughness value interpreted differently in two rendering paths can make a migration look like a lighting problem.
Choose a few reference objects whose expected appearance is easy to judge: a matte painted panel, bare metal, glass, and wood with a known grain direction. Keep the environment and exposure fixed while comparing them.
The migration must also account for custom shader features. A material that relies on a renderer-specific shader patch is an integration task, even when the base material has an equivalent name.
Separate geometry from presentation
Dimensions, openings, and assembly relationships belong to the model. The renderer derives meshes and draw submissions from that model.
This separation lets you simplify a distant object without changing its quoted dimensions. It also makes it possible to test geometric constraints without a GPU.
Repeated members may share geometry and materials, but do not batch away the identity needed for selection or inspection. A good representation balances draw overhead with useful object boundaries.
Put compute where it earns its cost
A compute pass is attractive for work with substantial parallelism: updating many particles, producing a height field, or evaluating a large independent data set.
Count the full path. Data upload, synchronization, readback, and rebuilding downstream geometry can dominate a small calculation. If the CPU needs the answer immediately, measure that boundary rather than timing the kernel alone.
Keep the simplest correct version as a reference. A CPU implementation can provide test outputs and remain a useful fallback even after a GPU path is added.
Update the pass contract for current Three.js
The current Three.js guide builds post-processing with RenderPipeline, TSL pass(), and an outputNode; examples built around an older PostProcessing class need checking against their pinned release. Tone mapping and output color conversion normally happen at the end of this pipeline. Applying another conversion upstream can change the image twice. Current post-processing guide.
Write an attachment sheet for each pass: width, height, format, sample count, clear behavior, consumers, and last use. A normal or motion-vector attachment should exist because a downstream effect needs it. Do not allocate every possible output just because the renderer supports multiple render targets.
For a concrete experiment, disable one attachment and its consumer, hold the camera fixed, and compare GPU time and estimated allocation. Then restore them and inspect moving edges. This distinguishes a useful effect from a target that consumes bandwidth without improving the product.
Use recent GPU features behind small experiments
The June 2026 WebGPU update documents immediates and tighter validation for transient attachments. Transient attachments have restrictions, including use as resolve targets; they are not interchangeable with textures retained for later sampling. Chrome’s implementation notes.
Start with one frequently changed object identifier or one disposable depth attachment. Compare the candidate against the existing buffer or attachment path with identical draw submissions. Measure CPU encoding separately from GPU execution. If only the API setup changes, do not attribute an unrelated shader improvement to it.
Keep the experiment isolated in the pass that owns it. A compatibility decision should select a known resource layout, not leave half the frame configured for an unsupported optimization.
Budget resources together
Textures compete with render targets, geometry, instance buffers, and temporary allocations. An image file’s download size does not describe its runtime footprint.
Create asset tiers around visible requirements. A close material inspection may justify a larger texture than the same object in a distant overview. Load the smaller useful image first and retire resources through a defined owner.
The texture memory lab makes one part of that budget explicit. It cannot discover the memory available to your application.
Make failure part of the design
Before adding another visual effect, test a failed asset request, a resize during loading, repeated scene replacement, and loss of the graphics device. Preserve configuration independently so rebuilding the view does not erase the user’s work.
Use the WebGPU specification for API rules. Treat performance figures as properties of a specific workload and environment.
A dependable pipeline is one you can explain, measure, and rebuild. Those qualities make visual ambition easier to sustain.
Keep a good idea close.
Follow Signal Tower
