
## Introduction

You have two options if you want to create a custom post-process task for use in a frame graph:
* Implement a frame graph task from scratch
* Use the wrapper class [FrameGraphCustomPostProcessTask](/typedoc/classes/babylon.framegraphcustompostprocesstask) around your post-process
<br/>
If you want to go the first route, you can draw inspiration from the many existing post-processing tasks (located at https://github.com/BabylonJS/Babylon.js/tree/master/packages/dev/core/src/FrameGraph/Tasks/PostProcesses).

However, in most cases, using `FrameGraphCustomPostProcessTask` should meet your needs, and we will see how to use it in the next section.

## Using the FrameGraphCustomPostProcessTask class

Creating a post-process task using `FrameGraphCustomPostProcessTask` is very simple.

Suppose you use this code to create your post-process in the traditional way:
```typescript
const edges = new BABYLON.PostProcess('edges', 'edge', ["escale", "threshold"], [], 1, camera);

edges.onApplyObservable.add((effect) => {
    effect.setFloat("escale", 3);
    effect.setFloat("threshold", 0.1);
});
```

You can create a task that can be used in a frame graph as follows:
```typescript
const task = new BABYLON.FrameGraphCustomPostProcessTask("edgeDetection", frameGraph, {
    fragmentShader: "edge",
    uniforms: ["escale", "threshold"],
});

task.onApplyObservable.add((effect) => {
    effect.setFloat("escale", 3);
    effect.setFloat("threshold", 0.1);
});
```
Note: Both examples assume that `BABYLON.Effect.ShadersStore["edgeFragmentShader"]` contains the post-process fragment shader.

In the case of a frame graph task, you can also provide the shader code directly via the **fragmentShader** parameter, but you must then set the `useShaderStore` parameter to `false`:
```typescript
const task = new BABYLON.FrameGraphCustomPostProcessTask("edgeDetection", frameGraph, {
    fragmentShader: "/** shader code */",
    uniforms: ["escale", "threshold"],
    useShaderStore: false,
});
```

Here is a simple PG that illustrates the two code paths (update line 21 to use either the standard or frame graph path):

<Playground id="#F494TC" image="/img/playgroundsAndNMEs/pg-ZC3Y12-2.webp" title="Custom post-process in frame graph" description="Using a custom post-process in frame graph with FrameGraphCustomPostProcessTask" isMain={true} category="Frame Graph"/>

## Making the task available in NRGE

We can go even further and make this post-process usable in the Node Render Graph Editor (NRGE)!

As a general rule, to create a block that can be used in NRGE, you need to create a class that extends `NodeRenderGraphBlock`. However, in the case of post-processes, there is already a base class called `NodeRenderGraphBasePostProcessBlock` that simplifies the implementation of a node render graph block for this case.

First, we create a small wrapper class around the edge detection post-process:
```typescript
export class EdgeDetectionPostProcessTaskWrapper {
    public readonly task: BABYLON.FrameGraphCustomPostProcessTask;
    public escale = 3;
    public threshold = 0.1;

    constructor(frameGraph: BABYLON.FrameGraph) {
        this.task = new BABYLON.FrameGraphCustomPostProcessTask("edgeDetection", frameGraph, {
            fragmentShader: EdgeDetectionFragment,
            uniforms: ["escale", "threshold"],
            useShaderStore: false,
        });

        this.task.onApplyObservable.add((effect) => {
            effect.setFloat("escale", this.escale);
            effect.setFloat("threshold", this.threshold);
        });
    }
}
```
Note: **EdgeDetectionFragment** is the shader code of the post-process.

This is the same code as above, but it allows you to easily modify the **escale** and **threshold** properties.

As for the implementation of the node render graph block `NodeRenderGraphEdgePostProcessBlock`, it is quite simple thanks to the use of `NodeRenderGraphBaseWithPropertiesPostProcessBlock`:
* First, we declare a private variable to contain the wrapper class and initialize it in the constructor:
```typescript
export class NodeRenderGraphEdgePostProcessBlock extends BABYLON.NodeRenderGraphBaseWithPropertiesPostProcessBlock {
    protected override _frameGraphTask: BABYLON.FrameGraphCustomPostProcessTask;

    public override get task() {
        return this._frameGraphTask;
    }

    private _wrapper: EdgeDetectionPostProcessTaskWrapper;

    public constructor(name: string, frameGraph: BABYLON.FrameGraph, scene: BABYLON.Scene) {
        super(name, frameGraph, scene);

        this._finalizeInputOutputRegistering();

        this._wrapper = new EdgeDetectionPostProcessTaskWrapper(frameGraph);
        this._frameGraphTask = this._wrapper.task;
    }
```
Note: `_finalizeInputOutputRegistering` is a method of the base class that adds the `dependencies` input and the `output` output to the block.

We now add the code to modify the **escale** and **threshold** properties:
```typescript
@BABYLON.editableInPropertyPage("Edge scale", BABYLON.PropertyTypeForEdition.Float, "PROPERTIES", { min: 0, max: 30 })
public get escale(): number {
    return this._wrapper.escale;
}

public set escale(value: number) {
    this._wrapper.escale = value;
}

@BABYLON.editableInPropertyPage("Threshold", BABYLON.PropertyTypeForEdition.Float, "PROPERTIES", { min: 0, max: 1 })
public get threshold(): number {
    return this._wrapper.threshold;
}

public set threshold(value: number) {
    this._wrapper.threshold = value;
}
```
Thanks to the use of decorators, implementation is very simple, as you can see above: just write a getter/setter for each property and you're done!

The last step is to implement code generation, serialization, and parsing:
```typescript
protected override _dumpPropertiesCode() {
    const codes: string[] = [];
    codes.push(`${this._codeVariableName}.escale = ${this.escale};`);
    codes.push(`${this._codeVariableName}.threshold = ${this.threshold};`);
    return super._dumpPropertiesCode() + codes.join("\n");
}

public override serialize(): any {
    const serializationObject = super.serialize();
    serializationObject.escale = this.escale;
    serializationObject.threshold = this.threshold;
    return serializationObject;
}

public override _deserialize(serializationObject: any) {
    super._deserialize(serializationObject);
    this.escale = serializationObject.escale;
    this.threshold = serializationObject.threshold;
}
```
Note: Implementing `serialize` and `_deserialize` is mandatory for the block to work in NRGE (unlike `_dumpPropertiesCode` - but if you don't implement this method, the "Generate Code" button won't work as expected)!

Once again, the code is very simple: just serialize and parse the properties used by the post-process.

You must register this class in Babylon's class system:
```typescript
BABYLON.RegisterClass("BABYLON.NodeRenderGraphEdgePostProcessBlock", NodeRenderGraphEdgePostProcessBlock);
```

In order for your block to be discoverable by NRGE, you must add it to `NodeRenderGraph.CustomBlockDescriptions`:
```typescript
if (!BABYLON.NodeRenderGraph.CustomBlockDescriptions.find((desc) => desc.name === "Edge_Detection")) {
    BABYLON.NodeRenderGraph.CustomBlockDescriptions.push({
        name: "Edge_Detection",
        description: "Edge detection post-process",
        menu: "Post_Processes",
        factory: (frameGraph: BABYLON.FrameGraph, scene: BABYLON.Scene) => new NodeRenderGraphEdgePostProcessBlock("Edge detection", frameGraph, scene),
    });
}
```
Note: Since a playground can be launched multiple times, we first check whether the block has already been added to the array during a previous execution. In a real project, this check is probably unnecessary, as you would refresh the page after updating your code.

You can use this PG to test it:

<Playground id="#ZC3Y12#8" image="/img/playgroundsAndNMEs/pg-ZC3Y12-4.webp" title="Custom post-process in NRGE" description="Making a custom post-process available in NRGE" isMain={false}/>

The scene is displayed normally. To use a frame graph with the edge detection post-process, proceed as follows:
* Open the inspector
* Right-click on the "Frame Graphs" container, and choose "Add new Frame Graph"
* Edit the frame graph
* In NRGE, add an "Edge Detection" post-process between the **Main rendering** block and the **Output** block.
* To see the change in the Playground, go back to the inspector and set this frame graph as the scene's frame graph
<br/>
The scene will now use the frame graph for rendering, and you should see the edge detection post-process in action!

![Final scene with edge rendering](/img/frameGraph/example_custompp_scene_edge.webp)

Note that you can save the frame graph to the snippet server and reload it with a few lines of code:
```typescript
const nrg = await BABYLON.NodeRenderGraph.ParseFromSnippetAsync("XQF0ML", scene);

await nrg.buildAsync();
```

<Playground id="#ZC3Y12#10" image="/img/playgroundsAndNMEs/pg-ZC3Y12-2.webp" title="Load node render graph with custom post-process" description="Loading a node render graph from the snippet server with custom post-process" isMain={false}/>

**Important**: editing the node render graph with the [standalone NRGE](https://nrge.babylonjs.com) will not work!

This means that this URL will not work: https://nrge.babylonjs.com/#XQF0ML. The edge detection block cannot be created by NRGE because it does not know it.

This is because the implementation of the node block for the edge detection post-process is not available in the standalone version of NRGE. You must edit the graph by first opening the playground where the class is defined and then accessing it through the inspector.

Note that you can also open NRGE using this code:
```typescript
const nrg = await BABYLON.NodeRenderGraph.ParseFromSnippetAsync("XQF0ML", scene);

await nrg.buildAsync();
nrg.edit();
```




## Introduction

VAT (Vertex Animation Texture) or BVA (Baked Vertex Animation) is a way to support a large number of animated meshes by precomputing the animations. For more information, see [Baked Texture Animations](/features/featuresDeepDive/animation/baked_texture_animations).

VAT is not supported by the [geometry buffer renderer](/typedoc/classes/babylon.geometrybufferrenderer). Therefore, if you use it to generate a normal map (or any other geometry texture) with VAT meshes, it will not work as expected.

For example: <Playground id="#VI0JUJ#3" title="VAT and geometry buffer renderer" description="VAT not working with the geometry buffer renderer" isMain={false}/>

You can see that the spiders are not animated in the normal texture (which is used as the emissive texture on the plane facing the camera).

Let's use a frame graph to make it work!

## Using a frame graph

We will use a frame graph to generate the normal texture, instead of using the geometry buffer renderer as in the previous example.
Note that the frame graph will not take control of the entire scene rendering loop: we will not set `scene.frameGraph` to our frame graph, but rather execute it manually.

The frame graph is actually very simple; we only need a geometry renderer task and to configure it to generate the normal texture.

First, we create the frame graph and the depth texture that will be used by the geometry renderer. We also clear the depth texture:
```javascript
const frameGraph = new BABYLON.FrameGraph(scene);

const depthTexture = frameGraph.textureManager.createRenderTargetTexture("depth", {
    size: { width: 100, height: 100 },
    sizeIsPercentage: true,
    options: {
        createMipMaps: false,
        types: [BABYLON.Constants.TEXTURETYPE_UNSIGNED_BYTE],
        formats: [BABYLON.Constants.TEXTUREFORMAT_DEPTH32_FLOAT],
        samples: 1,
        useSRGBBuffers: [false],
        labels: ["depth"],
    },
});

const clearTask = new BABYLON.FrameGraphClearTextureTask("clear", frameGraph);

clearTask.clearColor = false;
clearTask.clearDepth = true;
clearTask.depthTexture = depthTexture;

frameGraph.addTask(clearTask);
```
We can now create the geometry renderer task:
```javascript
const rlist = {
    meshes: [mesh],
    particleSystems: []
}

const geomRendererTask = new BABYLON.FrameGraphGeometryRendererTask("geomRenderer", frameGraph, scene);

geomRendererTask.depthTexture = clearTask.outputDepthTexture;
geomRendererTask.objectList = rlist;
geomRendererTask.camera = camera;
geomRendererTask.samples = 1;
geomRendererTask.textureDescriptions.push({
    type: BABYLON.Constants.PREPASS_NORMAL_TEXTURE_TYPE,
    textureFormat: BABYLON.Constants.TEXTUREFORMAT_RGBA,
    textureType: BABYLON.Constants.TEXTURETYPE_UNSIGNED_BYTE,
});

frameGraph.addTask(geomRendererTask);
```
Note how we configure the task to generate the normal texture: this is an entry we add to the `geomRendererTask.textureDescriptions` array of the task.

That's all it takes to create the graph. Now we need to retrieve the texture and set it as the emissive texture of the plane material:
```javascript
let texture = null;

frameGraph.onBuildObservable.add(() => {
    const geomTexture = frameGraph.textureManager.getTextureFromHandle(geomRendererTask.geometryViewNormalTexture);
    geomTexture.incrementReferences();

    texture?.dispose();
    texture = new BABYLON.Texture("", scene, {
        internalTexture: geomTexture
    });
    texture.name = "GeomRenderer normal";
    mat.emissiveTexture = texture;
});
```
The texture can only be retrieved after the frame graph has been built, so `frameGraph.onBuildObservable` is the appropriate place to add our code. The code itself retrieves the actual texture (an `InternalTexture` instance) from the texture handle. Note that we increment the number of references to the texture because we wrap this internal texture in a `Texture` instance (an `InternalTexture` instance cannot be assigned to `mat.emissiveTexture`), and the `Texture.dispose` method decrements the number of references.

All that remains is to write the code to build the frame graph and execute it:
```javascript
await frameGraph.buildAsync();

engine.onResizeObservable.add(async () => {
    await frameGraph.buildAsync();
});

scene.onBeforeRenderObservable.add(() => {
    frameGraph.execute();
});
```
The full PG: <Playground id="#CP2RN9#322" title="VAT and frame graph" description="VAT working when using a frame graph" isMain={false} image="/img/playgroundsAndNMEs/pg-VI0JUJ-3.webp"/>

You can see that the spiders are now animated in the normal texture.

## Using a node render graph

For completeness, here is the same thing using a node render graph:

Node Render Graph: <NRGE id="#USAV67#5" title="VAT and frame graph (NRGE)" description="VAT working when using a frame graph (NRGE)" isMain={false}/>

PG: <Playground id="#CP2RN9#324" image="/img/playgroundsAndNMEs/pg-CP2RN9-324.webp" title="VAT and frame graph (NRG)" description="VAT working when using a frame graph (NRG)" isMain={false} image="/img/playgroundsAndNMEs/pg-VI0JUJ-3.webp"/>

Notes:
* We disable `autoFillExternalInputs` when loading the node's render graph, because the list of meshes used by the geometry renderer task must not contain the plane on which we display the geometry texture (otherwise, you will get an error such as “GL_INVALID_OPERATION: glDrawElements: feedback loop formed between the frame buffer and the active texture").
* We disable the `Output` block in the render graph to avoid copying the result of the graph execution to the default frame buffer, which is a waste of GPU resources as it will be overwritten by the actual rendering of the scene.



## Introduction

![History Texture in Frame Graphs](/img/frameGraph/example_historytexture.webp)

Babylon.js supports a simplified version of history textures: ping-pong textures.

For more information on this feature, see [History textures](/features/featuresDeepDive/frameGraph/frameGraphClassFramework/frameGraphClassOverview#history-textures).

We will use a ping-pong texture to implement onion-skin rendering, which leaves a trail for all moving objects. This effect is achieved by accumulating several renderings over time and blending them appropriately.

## Implementing the FrameGraphOnionSkinObjectRendererTask class

To simplify the implementation, we will extend `FrameGraphObjectRendererTask` and implement our own `record()` method with the minimum amount of code needed to show the use of history textures. Notably, we will not reimplement OIT, camera rigs, or bounding-box rendering support: you can refer to the implementation of the `FrameGraphObjectRendererTask.record()` method if you want to add support for these features.

### Initializing the full screen effect

We will apply post-processing to the rendering, which will blend the current output with that of the previous frame.

To do this, we need to create an effect to encapsulate this shader code:

```typescript
BABYLON.Effect.ShadersStore["onionSkinPixelShader"] = `
    uniform sampler2D lastFrame;
    uniform sampler2D textureSampler;

    void main(void) {
        vec4 curr = texelFetch(textureSampler, ivec2(gl_FragCoord.xy), 0);
        vec4 last = texelFetch(lastFrame, ivec2(gl_FragCoord.xy), 0);

        curr.rgb = mix(curr.rgb, last.rgb, 0.8);

        gl_FragColor = curr;
    }
`;
```

The shader code is very simple: for each pixel, we blend the previous color with the current color. You can change the value 0.8 to strengthen or weaken the effect.

The effect can be easily created using the `EffectWrapper` class:

```typescript
export class FrameGraphOnionSkinObjectRendererTask extends BABYLON.FrameGraphObjectRendererTask {
    protected readonly _effectWrapper: BABYLON.EffectWrapper;
    protected readonly _drawWrapper: BABYLON.DrawWrapper;

    constructor(name: string, frameGraph: BABYLON.FrameGraph, scene: BABYLON.Scene, options?: BABYLON.ObjectRendererOptions) {
        super(name, frameGraph, scene, options);

        this._effectWrapper = new BABYLON.EffectWrapper({
            engine: engine,
            fragmentShader: "onionSkin",
            samplerNames: ["lastFrame", "textureSampler"],
            name: "effect wrapper",
            useShaderStore: true,
        });
        this._drawWrapper = this._effectWrapper.drawWrapper;
    }

    public record(): BABYLON.FrameGraphRenderPass {
        // TODO: implement the method
    }
}
```

### Implementing the record method

Let's implement the `record()` method.

#### Checking input parameters

First, we perform a number of checks on the input parameters to ensure that we will not generate any errors when running the graph:

```typescript
if (this.targetTexture === undefined || this.objectList === undefined) {
    throw new Error(`FrameGraphOnionSkinObjectRendererTask ${this.name}: targetTexture and objectList are required`);
}

const textureManager = this._frameGraph.textureManager;
const targetTextures = Array.isArray(this.targetTexture) ? this.targetTexture : [this.targetTexture];

if (textureManager.isBackbuffer(targetTextures[0]) || (this.depthTexture !== undefined && textureManager.isBackbuffer(this.depthTexture))) {
    throw new Error(`FrameGraphOnionSkinObjectRendererTask ${this.name}: the back buffer color/depth textures are not allowed. Use regular textures instead.`);
}

const outputTextureDescription = textureManager.getTextureDescription(targetTextures[0]);

let depthEnabled = false;

if (this.depthTexture !== undefined) {
    const depthTextureDescription = textureManager.getTextureDescription(this.depthTexture);
    if (depthTextureDescription.options.samples !== outputTextureDescription.options.samples) {
        throw new Error(`FrameGraphOnionSkinObjectRendererTask ${this.name}: the depth texture and the output texture must have the same number of samples`);
    }

    depthEnabled = true;
}

this._textureWidth = outputTextureDescription.size.width;
this._textureHeight = outputTextureDescription.size.height;
```

These checks are fairly basic. Note that we cannot allow the use of the back buffer texture for the **targetTexture** input, as we will be reading this texture during the blending process.

#### Creating the ping-pong texture

We can now create the ping-pong texture and set it as our output texture:

```typescript
const textureCreationOptions: BABYLON.FrameGraphTextureCreationOptions = {
    size: outputTextureDescription.size,
    options: {
        createMipMaps: outputTextureDescription.options.createMipMaps,
        types: [BABYLON.Constants.TEXTURETYPE_HALF_FLOAT],
        formats: [BABYLON.Constants.TEXTUREFORMAT_RGBA],
        samples: 1,
        useSRGBBuffers: [false],
        creationFlags: [0],
        labels: [""],
    },
    sizeIsPercentage: false,
    isHistoryTexture: true,
};

const pingPongHandle = textureManager.createRenderTargetTexture(`${this.name} history`, textureCreationOptions);

textureManager.resolveDanglingHandle(this.outputTexture, pingPongHandle);
if (this.depthTexture !== undefined) {
    textureManager.resolveDanglingHandle(this.outputDepthTexture, this.depthTexture);
}
```

We create the texture with the same dimensions as the target texture. Since this is an example, we hardcode the type **TEXTURETYPE_HALF_FLOAT**, but you can let the user choose it via an input parameter of the class. We also set the **isHistoryTexture** option to *true*, to make it a history texture.

It is important that we resolve the dangling handle **outputTexture** with **pingPongHandle** and not with **targetTexture**, because the result of the blending process will end up in the writable texture of the ping-pong texture! For more information on dangling handles, see [Dangling Texture Handles](/features/featuresDeepDive/frameGraph/frameGraphClassFramework/frameGraphClassOverview#dangling-texture-handles).

#### Creating the render pass

We are now ready to create the pass that will be executed on each frame:

```typescript
let pingPongRenderTargetWrapper: BABYLON.FrameGraphRenderTarget | undefined;

const pass = this._frameGraph.addRenderPass(this.name);

pass.setRenderTarget(this.targetTexture);
pass.setRenderTargetDepth(this.depthTexture);
pass.setExecuteFunc((context) => {
    // Sets the objects/particle systems to render
    this._renderer.renderList = this.objectList.meshes;
    this._renderer.particleSystemList = this.objectList.particleSystems;

    // Render the scene into targetTexture (the texture passed to pass.setRenderTarget above)
    context.setDepthStates(this.depthTest && depthEnabled, this.depthWrite && depthEnabled);

    context.render(this._renderer, this._textureWidth, this._textureHeight);

    // Merges the scene with the (readable) ping/pong texture and renders the result into the (writable) ping/pong texture
    pingPongRenderTargetWrapper = pingPongRenderTargetWrapper || context.createRenderTarget(`${this.name} ping/pong`, pingPongHandle);

    context.bindRenderTarget(pingPongRenderTargetWrapper);

    context.applyFullScreenEffect(this._drawWrapper, () => {
        context.bindTextureHandle(this._drawWrapper.effect!, "textureSampler", targetTextures[0]);
        context.bindTextureHandle(this._drawWrapper.effect!, "lastFrame", pingPongHandle);
    });
});
```

Note that we set the **renderList** and **particleSystemList** properties of the renderer on each frame to ensure that they are always synchronized with the settings defined by the user at the class level (we could use the **objectList** setter to update them, but that would not let us handle changes made to the **objectList.meshes** and **objectList.particleSystems** arrays).

Next, we render the objects to the current render target (by calling `context.render()`), which is **targetTexture**, defined by the call `pass.setRenderTarget(this.targetTexture);`.

The next step is to merge this render with the previous ping-pong texture we rendered.

First, we need a render target for the ping-pong texture, which we can create via a call to `context.createRenderTarget()`. Note that this render target must be created after the textures are allocated, because `context.createRenderTarget()` must access the real textures. To simplify implementation, we make the call in the execute function of the pass, but we could also do it in a `FrameGraphTask.onTexturesAllocatedObservable` observer.

Now that we have the render target, we bind it to be the texture we will render to (`context.bindRenderTarget()`), then call the `context.applyFullScreenEffect()` method, which allows us to apply a full-screen effect to the texture. The second parameter of this function is a callback that we can use to set the uniform values used by the shader. Note that we set the ping-pong handle for the **lastFrame** uniform: since we are also rendering to the ping-pong texture, the system knows to bind the read texture and not the write texture.

The last step is to create the pass used when the task is disabled, which is a simple copy from the input texture to the destination texture:

```typescript
const passDisabled = this._frameGraph.addRenderPass(this.name + "_disabled", true);

passDisabled.setRenderTarget(this.outputTexture);
passDisabled.setRenderTargetDepth(this.depthTexture);
passDisabled.setExecuteFunc((context) => {
    context.copyTexture(targetTextures[0]);
});
```

## Putting it all together

This PG uses the class described on this page to create a frame graph that renders objects with onion-skin effect:

<Playground id="#61N9QT#7" image="/img/frameGraph/example_historytexture.webp" title="Onion-skin effect" description="Implementing onion-skin effect with frame graphs" isMain={false}/>



## Introduction

Transmissive materials are materials that allow you to see through them and use a refraction texture to display what is behind the mesh with that material.

This texture is created by rendering the non-transmissive meshes and is defined as a refraction texture for transmissive materials, with a specific coordinate mode so that we get the illusion of seeing through the mesh, when in reality we are simply rendering the mesh with a special refraction texture.

For example, in the scene below, we have a single transmissive material/mesh (the amber block):

![Scene with transmissive meshes](/img/frameGraph/example_transmission_finalscene.webp!500)

The amber mesh is rendered like this:

![Refraction texture](/img/frameGraph/example_transmission_refractiontexture.webp!400)

In each frame, the refraction texture is regenerated to account for changes in the scene (camera or mesh movements, etc.).

## Support in Babylon.js

Transmissive materials/meshes are currently supported via the glTF extension [KHR_materials_transmission](https://github.com/KhronosGroup/glTF/blob/main/extensions/2.0/Khronos/KHR_materials_transmission/README.md).

This means that you cannot directly define transmissive materials via code; you must load a .glb/.gltf file containing transmissive materials (the extension uses a `TransmissionHelper` class internally, but this is not accessible to the end user).

The implementation is as follows:
* The refraction texture is generated in a separate `RenderTargetTexture` by rendering all non-transmissive meshes.
  * This texture is defined as the refraction texture for all transmissive materials.
* The entire scene (non-transmissive + transmissive meshes) is rendered to the screen.

The `TransmissionHelper` class is responsible for rendering the refraction texture and assigning it to transmissive materials. Two separate renders are required to produce a frame:

![Transmission helper](/img/frameGraph/example_transmission_transmissionhelper.webp!700)

By using a frame graph (actually a node render graph), we are free to create transmissive materials without resorting to external .glb/.gltf files.

You may also have noticed in the description above that non-transmissive meshes are rendered twice: once to generate the refraction texture, and again when the entire scene is rendered.

Thanks to the flexibility of the node render graph, we can do better and render non-transmissive meshes only once!

## Flow of operations with the node render graph

Here are the details of the operations we will perform in the node render graph:

![Node render graph operations](/img/frameGraph/example_transmission_framegraph-operations.webp!600)

As you can see, two additional operations are required compared to using `TransmissionHelper`: a texture copy and image post-processing.

However, in all but the simplest scenes, these operations will be faster than rendering the non-transmissive meshes twice (which in practice means rendering the scene twice, since there are usually only a few transmissive meshes in a scene).

Note that we need to generate all renders in linear space (hence the darker tones in the image above) to avoid unnecessary gamma \<-\> linear space conversions: we only apply a conversion from linear space to gamma space once at the end, using an image processing post-process.

You may be wondering why we need to copy the current texture (let's call it **T**) to use it as a refraction texture for transmissive materials, rather than just using **T**. This is because it is impossible to read from and write to the same texture during a render pass. Since we render to **T** when rendering transmissive meshes, we cannot use it as a refraction texture. A texture copy is not too bad for performance, and you may even decide to use a smaller texture when copying, as you probably don't need the full final resolution for the refraction texture.

## Node render graph implementation

Here is the node render graph corresponding to the description in the previous section:

![Node render graph implementation](/img/frameGraph/example_transmission_framegraph.webp!600)

<NRGE id="#3MVLQ7#12" title="Implementation of the node render graph" description="Rendering of transmissive materials with a node render graph" isMain={false} category="NodeRenderGraph"/>

It closely follows the operations described above:
* `RenderNonTransmissiveObjects` renders the objects from the *NonTransmissiveObjectsList* list in the **Color Texture** texture
* `Copy texture` copies **Color Texture** to **Refraction Texture**
* `RenderTransmissiveObjects` renders the objects from the *TransmissiveObjectsList* list in the **Color Texture** texture
* `Image Processing` applies a linear to gamma space conversion to **Color Texture** and generates the result in the color backbuffer

An additional task that has not yet been described is the `Gen refraction texture mipmaps` block. This block simply generates the mipmaps for the **Refraction texture**, which are necessary to simulate the glossiness of the refracted part of the scene.

Key points to highlight from this graph:
* Both the `RenderNonTransmissiveObjects` and `RenderTransmissiveObjects` rendering tasks have the **Disable image processing** option checked to render in linear space:
![Rendered in linear space](/img/frameGraph/example_transmission_prop_linearspace_render.webp)
* The same applies to the clear color of the `Clear` block:
![Rendered in linear space](/img/frameGraph/example_transmission_prop_linearspace_clearcolor.webp)
* The **Create mipmaps** option is checked in the `Refraction Texture` block so that the texture is created with mipmaps. Note that this does not mean that mipmaps are *generated*, but only that additional GPU memory will be allocated for mipmaps! Mipmaps are generated using the `GenerateMipmaps` block. We have also defined specific dimensions for this texture (1024x1024), as we do not need the full final screen resolution. Also, we don't need MSAA for this texture, so **Samples** is set to 1:
![Refraction texture properties](/img/frameGraph/example_transmission_prop_refractiontexture.webp)
* The output of the `Gen refraction texture mipmaps` block is connected to the **dependencies** input of the `RenderTransmissiveObjects` block: this ensures that the texture is copied and the mipmaps are generated before this block is processed, as we will need the refraction texture during rendering.

## Playground implementation

Here is a playground that uses the node render graph described above to render a scene with transmissive materials:

<Playground id="#7FZ6P6#1" image="/img/playgroundsAndNMEs/pg-JWKDME-70.webp" title="Node render graph for rendering transmissive materials" description="Rendering transmissive materials with a node render graph" isMain={false}/>

We have created a separate class `RenderWithTransmission`, which takes care of loading and configuring the graph for you. This should make it easier to reuse the code in your own projects, but feel free to use it as a starting point for your own experiments!

Note that we disable the use/creation of the `TransmissionHelper` class by setting the **dontUseTransmissionHelper** option to *true*, as we do not need it when using frame graphs.

Here is the same scene using the unmodified asset:

<Playground id="#SYQW69#1301" title="TransmissionHelper for rendering transmissive materials" description="Rendering transmissive materials with transmission helper" isMain={false}/>

If you open both playgrounds in two different tabs and switch between them, you will see that the renders are identical. However, if you check a frame with [Spector](https://spector.babylonjs.com/), you will see that we are performing fewer render passes in the node render graph version.



Here you will find several examples of how frame graphs can be used in your own projects or as inspiration when creating your own frame graphs.


Frame Graph Examples

Coming next

Generating geometry textures for VAT

Use a frame graph to render geometry texture(s) for VAT

Rendering transmissive materials with frame graphs

Use a frame graph to render transmissive materials / meshes

Create a custom post-process

How to use the FrameGraphCustomPostProcessTask class to easily implement a post-process task

Use an history texture to create an onion-skin renderer

How to implement onion-skin rendering using a history texture

Implementing volumetric lighting with frame graphs

Use a frame graph to implement volumetric lighting