Documentation
    Preparing search index...

    Variable RENDER_GRAPHConst

    RENDER_GRAPH: PluginCapability<RenderGraph> = ...

    §81's "render passes" — differently shaped from the other five §81 tokens, and the shape is the point (RFC 0002 Q4; owner decision, register row 6: "include RENDER_GRAPH as a differently-shaped capability with that stated").

    There is no registry of pass kinds. §63's RenderGraph is an object the application builds per frame-configuration, so what this token hands over is the application's own graph, not a place to register a new kind of pass. A post-processing plugin can append its passes to it, which is the useful thing available today; a plugin that wants to teach the engine a new pass kind cannot, and that is RFC 0001's closed-union position rather than an oversight here.

    Not revocable. RenderGraph.removePass refuses while a later pass names the removed one's output, so removal is conditional on the state of a graph the host does not control — which is not a promise a lifecycle can keep.

    Provided only by a standalone @fourjs/core plugin host: §45 has no render-graph option, and inventing one would be the API invention RFC 0002 Q1 was careful to avoid.