PassAttachmentOptions

interface PassAttachmentOptions

import type { PassAttachmentOptions } from '@driftengine/core';

In depth

The asymmetry with PassDefinition.reads is the whole design and is worth reading first. What a pass writes into the frame is not negotiable and is refused: every built-in verb writes the current target, the executor replays a flush's nodes into one open pass, and a node declaring some other write-set would schedule as a pass nothing opens — so letting a package name its writes hands it the one declaration nothing can enforce. A target the pass owns is outside that set by construction, which is exactly what makes it declarable when a write to the frame is not.

What it is for: a package's own shadow map, blur pyramid, picking buffer or intermediate. A @driftengine/splats pass wanting a depth prepass of its own, a UI package wanting a cached layer, an XR package wanting a per-eye scratch.

Two implementations behind one call, the same split PassDevice itself takes, and for the same reason: a neutral device abstraction would be a second renderer API and would buy nothing, because a package's shader, buffer layout and pipeline differ per backend anyway. The union makes the branch explicit and typed.

Single-sampled, and that is a decision rather than an omission. A multisampled pass-owned target needs a resolve target beside it and a decision about who allocates it, and no contributed pass has asked. What that costs is that a pass wanting antialiased geometry of its own supersamples instead. What would reverse it is a contributed pass that needs it, at which point samples joins the options and the resolve target is created with the colour one.

dispose is the pass's to call, from its own dispose, and nothing calls it for you: the renderer knows what it created and this is not that. A target left undisposed is a texture the driver holds until the context goes.

Properties