
## Introduction

Rendering at the display's full resolution is often the most expensive thing a scene does, and the cost grows with the square of the resolution. Halving the resolution in each axis quarters the number of pixels the GPU has to shade, but a naive upscale back to display size gives you a soft, blurry image — the detail is simply gone.

Super resolution is the idea of getting some of that detail back. AMD's [FidelityFX Super Resolution 1 (FSR 1)](https://gpuopen.com/fidelityfx-superresolution/) is a spatial upscaler: it looks only at the current frame, reconstructs edges from it, and then sharpens the result. Because it needs no motion vectors and no history, it is cheap, it cannot produce ghosting, and it drops into an existing pipeline without any change to how your scene is drawn.

Babylon.js implements FSR 1 as the `FSR1RenderingPipeline`, and it runs on **WebGPU, WebGL 2, and Babylon Native**.

## FSR 1 rendering pipeline

Attaching the pipeline is all that is required — it renders the scene at a reduced resolution and upscales the result to the canvas:

```javascript
const fsr = new BABYLON.FSR1RenderingPipeline("fsr", scene, [camera]);

fsr.scaleFactor = BABYLON.FSR1RenderingPipeline.SCALE_QUALITY;
fsr.sharpnessStops = 0.2;
```

<Playground id="#GB98SV#0" title="FSR 1 Rendering Pipeline Example" description="Compare FSR 1 against a naive upscale of the same reduced-resolution render." isMain={true} category="Post-processing"/>

### Judging the result

Compare FSR 1 against **a naive upscale of the same reduced-resolution render**, not against a full-resolution one. The pipeline's whole purpose is to render fewer pixels, so switching it off renders at full resolution and will always look sharper. That comparison measures the resolution you chose to give up, not the quality of the reconstruction.

The figure below is the same scene at `SCALE_PERFORMANCE`, with FSR 1 between its two reference points. The inset magnifies the marked region.

![A native-resolution render, FSR 1, and a naive bilinear upscale of the same half-resolution source](/img/how_to/fsr1RenderingPipeline/comparison.webp)

FSR 1 and the naive upscale cost the same to render. Look at the grout lines in the inset: FSR 1 holds them, the naive upscale lets them dissolve.


## Settings

### Scale factor

`scaleFactor` is how much smaller the scene is rendered in each axis, so a value of `2` renders a quarter as many pixels. AMD's recommended presets are available as constants:

| Constant | Value | Pixels rendered |
| --- | --- | --- |
| `FSR1RenderingPipeline.SCALE_ULTRA_QUALITY` | 1.3 | ~59% |
| `FSR1RenderingPipeline.SCALE_QUALITY` | 1.5 | ~44% |
| `FSR1RenderingPipeline.SCALE_BALANCED` | 1.7 | ~35% |
| `FSR1RenderingPipeline.SCALE_PERFORMANCE` | 2.0 | 25% |

The default is `SCALE_QUALITY`. Larger values save more but give the upscaler less to work with; FSR 1 is a spatial algorithm, so detail that was never rendered cannot be invented.

### Sharpness

```javascript
fsr.sharpnessStops = 0.2;
```

`sharpnessStops` is the number of stops — halvings — by which the sharpening pass is reduced, so **`0` is maximum sharpness** and larger values are progressively softer. The default is `0.2`.

### Anti-aliasing

```javascript
fsr.samples = 4;
```

`samples` sets the MSAA sample count used for the reduced-resolution render, defaulting to `4`.

Do not turn anti-aliasing off. The upscaling pass amplifies aliased edges, so a jagged edge in the source becomes a more obvious artifact in the output. Keep MSAA on through this setting, or run a post-process solution such as [FXAA](/features/featuresDeepDive/postProcesses/usePostProcesses) or [TAA](/features/featuresDeepDive/postProcesses/TAARenderingPipeline).

## Hardware support

```javascript
if (fsr.isSupported) {
    // ...
}
```

FSR 1 requires WebGPU or WebGL 2, and is therefore unsupported on WebGL 1. Babylon Native is supported.

## How it works

FSR 1 is two fragment passes, run in order.

**EASU** (Edge-Adaptive Spatial Upsampling) does the upscaling. For each output pixel it examines a neighbourhood of the reduced-resolution input, estimates the direction and strength of any edge running through it, and fits a filter that follows that edge rather than blurring across it. This is what separates it from bilinear filtering, which weights neighbours purely by distance and so softens every edge equally.

**RCAS** (Robust Contrast-Adaptive Sharpening) then sharpens the upscaled image. It adapts its strength to local contrast so that flat regions are left alone and detail is not over-sharpened into ringing. `sharpnessStops` scales this pass.

Both passes are fragment shaders rather than compute shaders, which is why the pipeline runs anywhere a standard post-process does — including backends with no compute support.

## Choosing between FSR 1 and other options

FSR 1 is spatial: it sees one frame and nothing else. That is its strength and its limit.

- It **cannot ghost**, because it has no history to smear, which makes it well suited to scenes with fast movement.
- It **cannot recover sub-pixel detail across frames**, so it will not match a temporal technique on a static image. If your goal is anti-aliasing rather than performance, [TAA](/features/featuresDeepDive/postProcesses/TAARenderingPipeline) accumulates detail over time and will produce a cleaner result.

The two solve different problems and can be used together: render smaller with FSR 1 for the performance, and anti-alias the source so the upscaler has clean edges to work from.



## Introduction

In real-time rendering, shadows are commonly rendered using [shadow maps](https://doc.babylonjs.com/features/featuresDeepDive/lights/shadows) but these are most practical for punctual lights (i.e. directional, point and spot lights). When it comes to image-based lighting (IBL), generating accurate shadows becomes much more difficult because light is coming from all directions.
The IBL Shadows pipeline does what the name implies; it renders shadows cast by image-based lighting (i.e. [HDR environment lights](https://doc.babylonjs.com/features/featuresDeepDive/materials/using/HDREnvironment)) and allows you to then apply the shadows to PBR and standard materials. It does this by generating a voxel grid for all objects that will cast shadows and then traces rays through the voxel grid to determine which pixels will be shadowed.

Here is a comparison of the rendering with and without the IBL Shadows pipeline enabled:

| With Shadows | Without Shadows |
| --- | --- |
| ![With Shadows](/img/how_to/iblShadowsRenderingPipeline/intro_with_shadows.webp!400) | ![Without Shadows](/img/how_to/iblShadowsRenderingPipeline/intro_without_shadows.webp!400) |

Here is the playground that generated the above images:

- <Playground id="#3DGAC3#31" title="IBL Shadows Pipeline Example" description="Boombox scene with IBL shadows" isMain={true} category="Post-processing"/>

## Important Usage Notes

In its current implementation, this technique is only practical for static shadow-casting scenes, i.e. scenes where shadow-casting objects are not animated. This is because moving shadow-casters requires updating the voxel grid, and this is too slow for real-time animation (improvements are planned for WebGPU). Moving shadow-receivers, moving the camera, and changing the IBL direction, intensity, etc. will work fine.

## Prerequisites

The IBL Shadows Pipeline requires either WebGL 2.0 or WebGPU and, currently, can only be applied to [PBR materials](https://doc.babylonjs.com/features/featuresDeepDive/materials/using/masterPBR) and [Standard materials](https://doc.babylonjs.com/features/featuresDeepDive/materials/using/materials_introduction).

The IBL shadow pipeline relies on the [Geometry Buffer Renderer](https://doc.babylonjs.com/typedoc/classes/babylon.geometrybufferrenderer) so this should be kept in mind if combined with other pipelines. For example, if using the [SSR pipeline](https://doc.babylonjs.com/features/featuresDeepDive/postProcesses/SSRRenderingPipeline), make sure you force it to also use the geometry buffer instead of the prepass renderer to save memory.

## Using the IBL shadows rendering pipeline

### Create the Pipeline

Start by creating an instance of `BABYLON.IblShadowsRenderPipeline`:

```javascript
const shadowPipeline = new BABYLON.IblShadowsRenderPipeline(
  "ibl shadows", // The name of the pipeline
  scene, // The scene to which the pipeline belongs
  options, // The options for the pipeline
  [scene.activeCamera], // The list of cameras to attach the pipeline to
);
```

`options` is of type `BABYLON.IblShadowsSettings` which contains many [properties](https://doc.babylonjs.com/features/featuresDeepDive/postProcesses/IBLShadowsRenderingPipeline#properties) to control the look of the shadows.

### Configure the Shadows

1. Add shadow-casters. You must explicitly add any mesh that you want to cast shadows to the pipeline with `shadowPipeline.addShadowCastingMesh(mesh | meshes[])`. This will cause it to render to the voxel grid when the grid is re-rendered. Having control over which meshes cast shadows can be important for several reasons:
   1. It allows you to filter out objects like skyboxes or ground planes that you may not want casting shadows on your scene.
   1. Since the voxel grid's resolution is limited, it allows you to constrain the size of the shadow-casting part of the world to only the most important objects.
   1. Rendering to the voxel grid can be expensive so it might be good to limit the shadow-casting objects. For example, if you have many blades of grass, you may choose to have them receive shadows but not cast them.
1. Add shadow-receivers. You must also explicitly add any material that you want receiving shadows with `shadowPipeline.addShadowReceivingMaterial(material | materials[])`. If you call this function without an argument, it will add all materials in the scene.
1. Update scene bounds. Once you've added all the shadow-casters to the pipeline, call `shadowPipeline.updateSceneBounds()` to recalculate the size of the portion of the scene that the voxel grid will cover.
1. Update the voxel grid. Call `shadowPipeline.updateVoxelization()` to cause the shadow-casters to be rendered into the voxel grid. Once this is done, the shadows should automatically appear in the scene.
1. The IBL used for shadows will be whatever is assigned to `scene.environmentTexture`. This can be either a cubemap or equirectangular environment texture. HDR textures work best.

You can easily enable/disable the shadows by calling the `toggleShadow(enabled: boolean)` method of the pipeline.

## How the IBL Shadows pipeline works

A basic understanding of the algorithm will help you understand how to configure the shadow pipeline for best results.

### When the IBL map changes

When a new IBL texture is assigned to `scene.environmentTexture`, various CDF (cumulative distribution function) maps are generated internally that will be used to importance-sample the IBL during shadow computation. In short, this allows the brightest (i.e. most relevant) areas of the IBL to be sampled more, resulting in more accurate shadows with fewer samples.

### When the scene changes

The voxel grid will need to be regenerated whenever the shadow-casting scene changes so that new or moved shadow-casters will be included in the shadows. The voxel grid is a low-resolution (256^3 or less), 3D texture, that contains all the shadow-casting geometry of the scene.

1. The scene is rendered to the voxel grid, layer by layer, as it's not possible to render to the entire 3D texture at once in WebGL. The voxelization uses the maximum number of draw buffers to render several layers in each render pass. The higher the voxel grid resolution, the more passes will be necessary and the slower the voxelization will be.
1. If `triPlanarVoxelization` is enabled (the default), the voxelization will be done three times, once along each axis. The purpose of this is to avoid missing triangles that are parallel to the camera's line-of-sight. Disabling `triPlanarVoxelization` will speed up voxelization time but can often result in missing geometry.
1. After the voxel grid is generated, the hierarchical mips need to be generated for it. These are successively smaller and smaller textures that are used by the voxel tracing algorithm to efficiently traverse the voxel grid and find ray-geometry intersections, something like an octree.

### Each Frame

Once the CDF maps and voxel grid are created, there are several fullscreen passes that happen every frame to render the shadows. These all happen before your scene is rendered with full materials and lighting.

1. The [Geometry Buffer Renderer](https://doc.babylonjs.com/typedoc/classes/babylon.geometrybufferrenderer) renders the entire scene into several render target textures needed by the shadow pipeline. These include world-space normals, screen-space depth, world-space positions and motion vectors. These targets may also be shared by other pipelines that need them.
1. A "Voxel-tracing" pass will use the CDF maps and voxel grid to produce a shadow value for every pixel.
   1. Several samples of the IBL can be taken (controlled using the `sampleDirections` property). For each sample:
      1. A light direction is generated using the CDF maps. The direction is randomly selected based on the intensity of the light in that direction. i.e. the probability that a particular direction will be chosen is relative to the brightness of the IBL in that direction.
      1. The voxel grid is traversed in this direction to see if it will intersect any geometry. The mips of the voxel grid are key to traversing the grid efficiently.
      1. A screen-space shadow sample (see [below](https://doc.babylonjs.com/features/featuresDeepDive/postProcesses/IBLShadowsRenderingPipeline#screen-space-shadows)) is also taken using this light direction and is combined with the voxel sample.
      1. Two shadow values are then generated. The first is the simple accumulation of the shadow amount from each sample. The second is scaled by a view-dependent factor to approximate shadowing of specular lighting from the sampled direction.  
   1. The total shadow contribution of both diffuse shadowing and specular shadowing is divided by the number of samples to get the amount of raw shadowing for this frame. Taking more samples per frame will decrease the noise in the image but is more expensive to compute.
1. A blur pass then blurs the shadows to help remove some of the noise.
1. An accumulation pass will then combine the new shadow frame with shadows generated in previous frames. This has the effect of building up a smooth image of the shadows over several frames. The speed at which this happens can be adjusted using the `shadowRemanence` property.
1. The accumulated shadows are then applied to a mesh's material using Babylon's [material plugin system](https://doc.babylonjs.com/features/featuresDeepDive/materials/using/materialPlugins). The diffuse shadows are applied directly to the diffuse component of the material, leaving emissive light unaffected. Specular shadows are applied to specular lighting, but this is a bit more complex because the view-dependence of specular lighting depends on the roughness of the surface. We blend between diffuse and specular shadow factors based on the roughness of the surface. Highly smooth surfaces get the specular shadows, and rough surfaces (which are essentially non-directional) get the diffuse shadows.

## Screen-space Shadows

Screen-space shadows complement voxel shadows very nicely as they are great for rendering tiny shadow detail, where shadow-casters and shadow-receivers are very close together. As the name suggests, this technique works in screen-space, using the render targets output by the geometry buffer renderer. For each pixel, we trace a ray back to the light, taking samples as we step along the ray. At each step, if the depth of the pixel is less than the depth of the ray, the original pixel is assumed to be shadowed.

| No SS Shadows | With SS Shadows |
| --- | --- |
| ![No SS Shadows](/img/how_to/iblShadowsRenderingPipeline/NoSSS.webp!400) | ![SS Shadows](/img/how_to/iblShadowsRenderingPipeline/SSS.webp!400) |

## Limitations

1. This technique is currently only practical for static shadow-casters. Voxelization is very slow and needs to be done whenever a shadow-casting object moves or is animated.
2. The resulting shadows are greyscale. That is, they don't account for the colour of light in the IBL.
3. The resolution of the voxel grid can currently only go up to 256x256x256 so the sharpness of shadows in large scenes is limited. This is why we combine screen-space shadows with the voxel-tracing as it handles small geometry details well.
4. Rather than actually blocking light, this technique approximates the percentage of light that will hit the surface and then modulates the light that's already applied, darkening the surface. This can result in over-darkening parts of a surface, particularly surfaces facing away from bright, compact lights (e.g. the Sun) when only 1 or 2 sample directions are used.

| 1 Sample | 4 Samples |
| --- | --- |
|![1-Sample](/img/how_to/iblShadowsRenderingPipeline/1-sample.webp!400) | ![4-Samples](/img/how_to/iblShadowsRenderingPipeline/4-samples.webp!400) |

Note that the over-bright side of the sphere, facing away from the sun is an artifact of Babylon's use of spherical harmonics for diffuse IBL lighting.

## Properties

The following properties can be set on the pipeline (or passed in the constructor on initialization)

### General Properties

| Property | Description |
| --- | --- |
| shadowOpacity | How dark the shadows are. 1.0 is full opacity, 0.0 is no shadows. |
| sampleDirections | The number of different directions to sample during the voxel-tracing pass. Higher values will result in better quality and more stable shadows but will also be more expensive to compute each frame. Since shadows are accumulated from frame to frame, increasing this value doesn't help much when the camera isn't moving. |
| shadowRemanence | A factor that controls how long the shadows remain in the scene. 0.0 is no persistence, 1.0 is full persistence. This value applies only while the camera is moving. Once stationary, the pipeline increases remanence automatically to help the shadows converge. |
| shadowRenderSizeFactor | A size multiplier for the internal shadow render targets (default 1.0). A value of 1.0 represents full resolution. Scaling this below 1.0 will result in blurry shadows and potentially more artifacts, but it could help increase performance on less powerful GPUs. |

### Voxel Properties

| Property | Description |
| --- | --- |
| resolutionExp | The exponent of the resolution of the voxel shadow grid. Higher resolutions will result in sharper shadows but are more expensive to compute and require more memory. The resolution is calculated as 2 to the power of this number. e.g. a value of 6 results in a voxel grid that is 64x64x64 |
| triPlanarVoxelization | Render the voxel grid from 3 different axis. This will result in better quality shadows with fewer bits of missing geometry. |

### Screen-space Shadow Properties

| Property | Description |
| --- | --- |
| ssShadowsEnabled | Include screen-space shadows in the IBL shadow pipeline. This complements the voxel shadows by adding shadows for small geometry detail close to a shadow-casting object. |
| ssShadowSampleCount | The number of samples used in the screen space shadow pass. |
| ssShadowStride | This controls the distance between samples in pixels. |
| ssShadowDistanceScale | A scale for the maximum distance a screen-space shadow can be cast in world space. The maximum distance that screen-space shadows cast is derived from the voxel size and this value, so it shouldn't need to change if you scale your scene. |
| ssShadowThicknessScale | This value controls the assumed thickness of on-screen surfaces in world space. It scales with the size of the shadow-casting region, so it shouldn't need to change if you scale your scene. |

## Functions

| Function | Description |
| --- | --- |
| toggleShadow | Turn the shadows on or off |
| updateSceneBounds | Trigger the scene bounds of shadow-casters to be calculated. This is the world size that the voxel grid will cover and will always be a cube. |
| updateVoxelization | Trigger the scene to be re-voxelized. This should be run when any shadow-casters have been added, removed or moved. |
| resetAccumulation | Reset the shadow accumulation. This has a similar effect to lowering the remanence for a single frame. This is useful when making a sudden change to the IBL. |
| addShadowCastingMesh | Add a mesh to be used for shadow-casting in the IBL shadow pipeline. These meshes will be written to the voxel grid. |
| removeShadowCastingMesh | Remove a mesh from the shadow-casting list. The mesh will no longer be written to the voxel grid and will not cast shadows. |
| addShadowReceivingMaterial | Apply the shadows to a material or array of materials. If no material is provided, all materials in the scene will be added. |
| removeShadowReceivingMaterial | Remove a material from the list of materials that receive shadows. If no material is provided, all materials in the scene will be removed. |

## Debugging Shadows

The IBL Shadows Pipeline has a few debug modes to help in diagnosing issues. To enable these, you must first set `allowDebugPasses` to `true`. Once that is enabled, you can toggle the other debug modes on/off. If multiple are enabled at the same time, they will all attempt to display in different parts of the screen.

```javascript
shadowPipeline.allowDebugPasses = true;
```

| Property | Description | Image |
| --- | --- | --- |
| gbufferDebugEnabled | This will display only the targets of the g-buffer that are used by the shadow pipeline. | ![G-Buffer](/img/how_to/iblShadowsRenderingPipeline/gbuffer_debug.webp) |
| cdfDebugEnabled | This displays the IBL and the CDF maps used for importance sampling. | ![G-Buffer](/img/how_to/iblShadowsRenderingPipeline/ibl_debug.webp) |
| voxelDebugEnabled | This displays the voxel grid in slices spread across the screen. It also displays what slices of geometry are stored in each layer of the voxel grid. Each stripe represents one layer of the grid and each full gradient (from bright red to black) represents the layers rendered in a single draw call. | ![G-Buffer](/img/how_to/iblShadowsRenderingPipeline/voxel_debug.webp) |
| voxelDebugAxis | When using tri-planar voxelization (the default), this value can be used to display only the voxelization result for that axis. `0` -> z-axis, `1` -> y-axis, `2` -> x-axis, `undefined` -> all axes combined | ![Y-axis Voxelization](/img/how_to/iblShadowsRenderingPipeline/voxel_y-axis_debug.webp) |
| voxelDebugDisplayMip | Displays a given mip of the voxel grid. `voxelDebugAxis` must be `undefined` in this case because we only generate mips for the combined voxel grid. | ![Voxel Grid Mip 3](/img/how_to/iblShadowsRenderingPipeline/voxel_mip3_debug.webp) |
| voxelTracingDebugEnabled | Displays just the shadow samples taken this frame. | ![Voxel Tracing](/img/how_to/iblShadowsRenderingPipeline/voxel_tracing_debug.webp) |
| spatialBlurPassDebugEnabled | Display the shadow samples taken this frame, spatially blurred.  | ![G-Buffer](/img/how_to/iblShadowsRenderingPipeline/spatial_blur_debug.webp) |
| accumulationPassDebugEnabled | Display the debug view for the shadows accumulated over time. | ![G-Buffer](/img/how_to/iblShadowsRenderingPipeline/accumulation_debug.webp) |

## Performance Notes

### Voxelization Performance

Voxelization performance depends on voxel resolution, shadow-caster complexity, and whether `triPlanarVoxelization` is enabled. WebGPU will generally be faster than WebGL.

### Per-frame Shadow Rendering

Each frame, the time taken to compute shadows is primarily affected by two things.

- `sampleDirections` - The number of sample directions determines the number of voxel traces and the number of screen-space traces done for shadows. These are the primary computations done each frame so lowering this number will help performance.

- `shadowRenderSizeFactor` - Since the shadow computations are done per fragment, lowering the resolution of the shadow buffers can have a significant impact on performance. Try setting `shadowRenderSizeFactor` below 1.0.




# How To Use the SSAO rendering pipeline

BABYLON.SSAORenderingPipeline is a rendering pipeline (chained post-processes) that computes the ambient occlusion of a given scene from screen space.
You can find an example in our playground:

<Playground id="#N96NXC#106" title="SSAO Rendering Pipeline Example" description="Simple example of using the SSAO rendering pipeline." isMain={true} category="Post-processing"/>

The post-processes chain is defined by:

- Original scene color post-process: saves the original scene color
- SSAO post-process
- Horizontal blur post-process
- Vertical blur post-process
- Combine post-process: blends the Vertical blur post-process output with the original scene color

Using it is pretty straightforward:

```javascript
const ssao = new BABYLON.SSAORenderingPipeline("ssaopipeline", scene, 0.75);
```

The third argument is the ratio used by the SSAO, Horizontal blur, and Vertical blur post-processes.
You can also set an array of cameras as the fourth argument. The constructor will then automatically attach the rendering pipeline to the given cameras:

```javascript
const ssao = new BABYLON.SSAORenderingPipeline('ssaopipeline', scene, 0.75, [camera1 etc.]);
```

If you want to attach the rendering pipeline manually, use the scene rendering pipeline manager:

```javascript
const ssao = new BABYLON.SSAORenderingPipeline("ssaopipeline", scene, 0.75);
scene.postProcessRenderPipelineManager.attachCamerasToRenderPipeline("ssaopipeline", cameras);
```

**Warning: To improve performance, you should compute the SSAO/blurH/blurV with a ratio lower than 1.0.**

If you want to detach and destroy the rendering pipeline, you can just call the `dispose()` method.

```javascript
ssao.dispose();
```

You can see the SSAO post-process output by detaching the combine post-process like this:

```javascript
scene.postProcessRenderPipelineManager.disableEffectInPipeline("ssaopipeline", ssao.SSAOCombineRenderEffect, cameras);
```

**Note: SSAO uses the depth map renderer and activates it by default. You can disable the depth map renderer by passing `true` as the argument to the `dispose()` method.**

For more customization, you can specify the SSAO and Combine post-process ratios like this:

```javascript
const ssao = new BABYLON.SSAORenderingPipeline('ssaopipeline', scene, { ssaoRatio: 0.5, combineRatio: 1.0 }, [camera1 etc.]);
```



## Introduction

Aliasing is one of the most annoying problems when working with computer-generated images. It can spoil your experience, even when using the latest 3D rendering techniques. Aliasing appears in the form of jagged lines (geometric aliasing) or bright spots (specular/shading aliasing) and gets worse with movement.

![Geometric aliasing](/img/how_to/taaRenderingPipeline/intro_geom_aliasing.webp)
<font size="2">Geometric aliasing (look at all the mostly horizontal lines)</font>

![Shading aliasing](/img/how_to/taaRenderingPipeline/intro_shading_aliasing.webp)
<font size="2">Shading aliasing (look at the bright spots around the buttons)</font>

Aliasing exists because of the discrete nature of the screen (composed of pixels) and because each pixel can only be one color. Each pixel is effectively a small window on a part of the scene and should be able to display all the colors visible from that window to accurately describe the scene, but as it can only be one color, we have to make a decision about which color to display. There are many algorithms that deal with this problem, and Temporal Anti-Aliasing (TAA) is one of them.

## TAA rendering pipeline

You can use TAA in your own programs thanks to the TAA rendering pipeline:
```javascript
const taaRenderPipeline = new BABYLON.TAARenderingPipeline("taa", scene, [camera]);

taaRenderPipeline.isEnabled = true;
taaRenderPipeline.samples = 8;
```
By default TAA will be disabled when moving the camera to reduce ghosting artifacts, but you’ll still get ghosting from moving objects in the scene. Read below if you want to understand why this happens or other options to get rid of ghosting.

This PG demonstrates it with the camera: <Playground id="#539X0P#52" title="TAA Rendering Pipeline Example" description="BoomBox scene with temporal anti-aliasing" isMain={true} category="Post-processing"/>

You can use two parameters with the rendering pipeline:
* `samples`: Number of accumulated samples. The larger the value, the better the anti-aliasing, but the longer it takes to converge.
* `factor`: The factor used to blend the history image with the current image.

See below for further explanations of `samples` and `factor` if you’d like to know more about our implementation.

## Temporal Anti-Aliasing general principles

The main idea is quite simple: render the scene several times, each time with a different (small) offset for the projection matrix so that the rendered scene is slightly offset within the one-pixel limit. By averaging all the renderings, you’ll obtain a pretty good anti-aliasing effect.

![Jittering camera](/img/how_to/taaRenderingPipeline/camera_jittering.webp)
<font size="2">Jittering the camera — from [Unigine documentation](https://developer.unigine.com/en/docs/latest/principles/render/antialiasing/taa?rlang=cpp)</font>

However, rendering the scene several times per frame would seriously affect performance. This is where the “temporal” part of TAA comes in: we render the scene once per frame (with a different offset each time), and average the result over several consecutive frames. In this way, the cost of calculation is spread over several frames. It will take some time to obtain a smoothed image (8 frames, for example, if we choose 8 different offsets), but if we work at 60 frames per second, it won’t be too noticeable. Let’s see how this works in practice.

## Jitter offset

The rendered geometry needs to be "jittered" slightly so that the scene is slightly different from one frame to the next, but still within the dimensions of one pixel.

What we need to do to jitter the geometry is apply a 2D offset `jitter` to the 4D vertex `position` (the 4th "dimension" being `w`):
```glsl
position.xy += jitter * position.w;
```

We multiply the `jitter` by `w`, but don’t forget that the GPU will perform a division by the `w` coordinate as part of the normal rendering pipeline, to convert clip space to NDC (Normalized Device Coordinate) space! By multiplying by `w`, we cancel out the division by `w` and we’ll get what we want, a `jitter` shift of the 2D coordinates.

Note that the coordinates to which `jitter` is applied are in NDC space, which is in the interval **[-1,1]** for `x`/`y`. So, if the jitter offsets are in the interval **[0,1]**, they must be multiplied by `(2/width, 2/height)`, where `width` and `height` are the dimensions of the output (usually the screen), if the offsets are not to exceed the one-pixel limit.

On the JavaScript side, it’s easy enough: just define the offsets in the uniform as follows:
```javascript
uniforms.setFloat2("jitter", dx * 2 / width, dy * 2 / height);
```

In the real code, we’ll apply a translation `(-0.5, -0.5)` to `(dx,dy)` because the 2D pixel coordinate is the pixel center coordinate.

## Generating the offsets

We could use random values for the offsets, but we can get better results by using a [low-discrepancy sequence](https://en.wikipedia.org/wiki/Low-discrepancy_sequence). I won’t go into the details; you’ll find plenty of documentation on the subject on the Internet if you’re interested. The generally accepted method for TAA is to use a [Halton sequence](https://en.wikipedia.org/wiki/Halton_sequence). The code to generate this sequence can also be easily found, and we implemented our [own version](https://doc.babylonjs.com/typedoc/classes/babylon.halton2dsequence), which you can use for your own purposes if you wish.

As an illustration, here are the locations of 8 points generated with a Halton sequence created from the starting numbers (2,3):

![Halton 8](/img/how_to/taaRenderingPipeline/halton8.webp)
<font size="2">From [High Quality Temporal Supersampling](https://de45xmedrsdbp.cloudfront.net/Resources/files/TemporalAA_small-59732822.pdf) by Brian Karis (Unreal Engine)</font>

Note that when we’ve used all the points from the Halton sequence for our projection offsets, we restart from the first point.

## Averaging the frames

What we could do is accumulate (“additive blending”) each frame into a render target, then divide by the number of frames to get the final average. To avoid division, we could apply a weight to the color before writing it to the output. For example, if we use a sequence of 8 Halton samples, we’d use a weight of 1/8 for each frame. However, this method is a bit cumbersome, we’d have to clear the render target before restarting the Halton sequence, and it’s not well suited to handling motion. In addition, blending is more demanding in terms of performance, as it requires the source target to be read during the process.

Instead, we perform a moving average using this formula (it can be shown that this formula converges to the mean of `x(t)` values when `α` is small — see slides 15 and 16 of [High Quality Temporal Supersampling](https://de45xmedrsdbp.cloudfront.net/Resources/files/TemporalAA_small-59732822.pdf)):

![Average formula](/img/how_to/taaRenderingPipeline/average_formula.webp)

`s(t-1)` is the current average of a given pixel, `x(t)` is the new color of the pixel in the current frame, and `s(t)` is the new average. `α` is a small number, to be chosen by the user. A larger number will make the formula converge faster, but towards a number that will deviate more from the true mean than if a smaller value is chosen, but in this case, it will converge more slowly… Generally, a value in the **[0.05, 0.1]** range will give good results.

We used a rendering pipeline to implement this averaging, and a ping-pong of two render targets: one render target is used as the source (`s(t-1)`) and the other stores the result of the calculation for the current frame (`s(t)`). The render targets are exchanged at the end of the calculation in order to swap their roles for the next frame.

## Anti-ghosting techniques

One of the shortcomings of TAA is an artifact known as "ghosting" which is caused by moving the camera or objects:

![Ghosting](/img/how_to/taaRenderingPipeline/ghosting.webp)

This is because in the formula :

![Average formula](/img/how_to/taaRenderingPipeline/average_formula.webp)

`s(t-1)` should not be the accumulation for the pixel we’re currently processing, but rather we should find out where this pixel was located in the previous image to obtain the accumulation for this pixel! And therein lies the complexity. Luckily, Babylon provides a few options to get rid of this artifact!

### Disable on camera move

```javascript
taaRenderingPipeline.disableOnCameraMove = true;
```

This is the default and cheapest solution. All this does is disable the TAA effect whenever the camera is moving.

This works well when the only movement in your scene is from your camera, but does not prevent ghosting when the objects themselves are moving. For example if there’s an animation it will experience the same ghosting regardless of this option:

![A blurry animation of the BrainStem model](/img/how_to/taaRenderingPipeline/animation_ghosting.webp)

Note that you’ll likely want to set this to `false` if you’re using any of the other techniques below. You can still leave this set to `true` if you wish to use the other techniques for moving objects while still disabling TAA for a moving camera.

### Reproject history

```javascript
taaRenderingPipeline.reprojectHistory = true;
```

Enabling this will attempt to reproject the accumulated history based on a per-pixel velocity. This helps reduce the ghosting for both moving cameras and objects by more accurately locating the pixel’s location in the previous frame.

For this to work the TAA implementation requires a texture containing the per-pixel velocity, which can be generated alongside the color output. However, this won’t work on hardware that doesn’t support multiple render targets, or for materials that don’t write to the velocity buffer.

Additionally, this still produces ghosting when a pixel goes from being covered by an object in one frame to uncovered in the next. This occurs because the pixel is not in the previous frame, but it still tries to find its location in the previous frame regardless:

![A blurry boombox where the front is slightly less blurry than the back](/img/how_to/taaRenderingPipeline/reproject_ghosting.webp)

Note how the front of the model is less blurry than the background behind the model.

For this reason, it is recommended to combine this with `clampHistory`, which brings us to the next option...

### Clamp history

```javascript
taaRenderingPipeline.clampHistory = true;
```

In theory, if a pixel is too different from its previous value, then the previous value is likely to be incorrect (or reprojected incorrectly). In this case, the previous value is tweaked to better match what it (again, in theory) "should" be based on a neighborhood of pixels. There are multiple ways to do this, but one of the common ones is color clamping, which is what this option does.

Color clamping starts by getting the `min` and `max` values from the neighborhood of pixels, which we define as the 3x3 square centered on the target location:

![A square showing the 3x3 neighborhood of pixels in an image](/img/how_to/taaRenderingPipeline/color_neighborhood.webp)
<font size="2">From [Temporal AA and the Quest for the Holy Trail](https://www.elopezr.com/temporal-aa-and-the-quest-for-the-holy-trail/?unapproved=4350&moderation-hash=6c2bafd345ec15df25dca9a491e4c2be#comment-4350) by Emilio López</font>

Color clamping then assumes that the pixel will never go outside the **[`min`, `max`]** range and anything outside that range is likely to be incorrect. These "incorrect" pixels are adjusted by clamping them to within this **[`min`, `max`]** range, hence where the name comes from.

Due to its aggressive nature, this technique almost entirely gets rid of ghosting artifacts at the cost of being slightly more expensive (each output pixel now requires querying 9 more input pixels). That being said, movement still produces artifacts with this technique, albeit a different kind that’s a lot more subtle:

![A zoom in of the boombox in motion, the text and edges are a bit broken and wobbly](/img/how_to/taaRenderingPipeline/clamp_artifacts.webp)

Note the slightly garbled text and edges. Sadly, an incorrect value is still an incorrect value, regardless of how much you try to "correct" it.

For the best results in motion it is recommended to enable both `reprojectHistory`, which will attempt to find the pixel in the previous frame, and `clampHistory`, which acts as a fallback if the reprojection does not work:
```javascript
const taaRenderPipeline = new BABYLON.TAARenderingPipeline("taa", scene, [camera]);

taaRenderPipeline.reprojectHistory = true;
taaRenderPipeline.clampHistory = true;
// Camera motion is handled by reprojection and clamping
taaRenderPipeline.disableOnCameraMove = false;
```



## Introduction

You can find a complete example of this pipeline in our playground:

<Playground id="#Y3C0HQ#146" title="Default Rendering Pipeline Example" description="Complete example of the default rendering pipeline." isMain={true} category="Post-processing"/>

![default rendering pipeline example](/img/how_to/defaultRenderingPipeline/defaultRenderingPipeline.webp)

The default rendering pipeline provides visual improvements to enhance the output of your scene:
* Antialiasing (MSAA and FXAA)
* Bloom
* Chromatic Aberration
* Depth of field
* Image processing including:
 * Color curves
 * Color grading
 * Contrast
 * Exposure
 * Tone mapping
 * Vignette effect
* Glow
* Grain
* Sharpening

## Creating the rendering pipeline

You just have to create an instance of `BABYLON.DefaultRenderingPipeline`:

```javascript
var pipeline = new BABYLON.DefaultRenderingPipeline(
    "defaultPipeline", // The name of the pipeline
    true, // Do you want the pipeline to use HDR texture?
    scene, // The scene instance
    [camera] // The list of cameras to be attached to
);
```

This will actually create a fullscreen post-process texture.

Notes:

1. The HDR value should be `true` whenever possible, unless you're targeting a cheap fallback for low-end devices. This value allows either a half-float or float texture type, depending on the GPU. Also, some effects (like bloom) will be more accurate.

2. When enabling a pipeline, you may notice that your scene clearColor will not match the color you have set. This can be fixed using `.toLinearSpace()`, as in this <Playground id="#08A2BS#15" title="Clear Color Fix" description="Simple example of fixing the clear color in the default rendering pipeline to match what you have set."/>

## Customizing

## Antialiasing

The MSAA antialiasing effect (supported only in WebGL 2.0 browsers) is off by default (set to 1) but can be increased using:

```javascript
pipeline.samples = 4;
```

Your value will be clamped by the maximum values allowed by the hardware (queried from the WebGL context).

The FXAA antialiasing effect can be set using:

```javascript
pipeline.fxaaEnabled = true;
```

Note: without using the pipeline, your scene already uses MSAA antialiasing, which is native to WebGL. As mentioned above, the pipeline runs on a post-process texture: unfortunately, WebGL 1.0 devices will not be able to apply MSAA outside of render buffers. Still, FXAA is available, though it is not as powerful as MSAA.

## Sharpening

Sharpening can be enabled with:

```javascript
pipeline.sharpenEnabled = true;
```
To increase the intensity of the effect modify:

```javascript
pipeline.sharpen.edgeAmount = 0.9;
```

The amount of the original image in the output can be set with (setting this to 0 will produce edge detection output):

```javascript
pipeline.sharpen.colorAmount = 0.0;
```

## Depth of field

You can turn the depth of field effect on and off with:

```javascript
pipeline.depthOfFieldEnabled = true;
```

Set the strength of blur with (higher may affect performance):

```javascript
pipeline.depthOfFieldBlurLevel = BABYLON.DepthOfFieldEffectBlurLevel.Low;
```

Furthermore, you can control the settings of the effect with the following parameters:

```javascript
pipeline.depthOfField.focusDistance  = 2000; // distance of the current focus point from the camera in millimeters considering 1 scene unit is 1 meter
pipeline.depthOfField.focalLength  = 50; // focal length of the camera in millimeters
pipeline.depthOfField.fStop  = 1.4; // aka F number of the camera defined in stops as it would be on a physical device
```

<Playground id="#8F5HYV#9" title="Depth Of Field Example" description="Simple example of depth of field in the default rendering pipeline."/>

## Bloom

You can turn the bloom effect on and off with:

```javascript
pipeline.bloomEnabled = true;
```

The bloom luminance threshold, impact of the bloom, kernel size and scale can be controlled with the following:

```javascript
pipeline.bloomThreshold = 0.8;
pipeline.bloomWeight = 0.3;
pipeline.bloomKernel = 64;
pipeline.bloomScale = 0.5;
```

## Image processing effect

You can turn the image processing effect on and off with:

```javascript
pipeline.imageProcessingEnabled = true;
```

You can also control individual image processing subeffects. To get more info about the ImageProcessing postprocess, please read the following [tutorial](/features/featuresDeepDive/postProcesses/usePostProcesses#imageprocessing).

## Chromatic Aberration

You can turn the effect on and off with:

```javascript
pipeline.chromaticAberrationEnabled = true;
```

Furthermore, you can control the distance of color channel separation with:

```javascript
pipeline.chromaticAberration.aberrationAmount = 300;
```

To modify the strength of the effect based on the distance from the center of the screen:

```javascript
pipeline.chromaticAberration.radialIntensity = 3;
```

To modify the direction of the aberration, set the direction as follows:

```javascript
var rotation = Math.PI;
pipeline.chromaticAberration.direction.x = Math.sin(rotation)
pipeline.chromaticAberration.direction.y = Math.cos(rotation)
```

Note: If both these values are set to 0 the direction will be towards the center of the screen.

## Grain

You can turn the effect on and off with:

```javascript
pipeline.grainEnabled = true;
```

Furthermore, you can control the intensity of the grain with:

```javascript
pipeline.grain.intensity = 10;
```

To animate the grain on every frame, set:

```javascript
pipeline.grain.animated = value;
```

## Example

You may be interested in this code example using default values, ready to be copy-pasted into your application:

```javascript
    // https://doc.babylonjs.com/api/classes/babylon.defaultrenderingpipeline
    var defaultPipeline = new BABYLON.DefaultRenderingPipeline(
        "DefaultRenderingPipeline",
        true, // is HDR?
        scene,
        scene.cameras
    );
    if (defaultPipeline.isSupported) {
        /* MSAA */
        defaultPipeline.samples = 1; // 1 by default
        /* imageProcessing */
        defaultPipeline.imageProcessingEnabled = true; //true by default
        if (defaultPipeline.imageProcessingEnabled) {
            defaultPipeline.imageProcessing.contrast = 1; // 1 by default
            defaultPipeline.imageProcessing.exposure = 1; // 1 by default
            /* color grading */
            defaultPipeline.imageProcessing.colorGradingEnabled = false; // false by default
            if (defaultPipeline.imageProcessing.colorGradingEnabled) {
                // using .3dl (best) :
                defaultPipeline.imageProcessing.colorGradingTexture = new BABYLON.ColorGradingTexture("textures/LateSunset.3dl", scene);
                // using .png :
                /*
                var colorGradingTexture = new BABYLON.Texture("textures/colorGrade-highContrast.png", scene, true, false);
                colorGradingTexture.wrapU = BABYLON.Texture.CLAMP_ADDRESSMODE;
                colorGradingTexture.wrapV = BABYLON.Texture.CLAMP_ADDRESSMODE;                
                defaultPipeline.imageProcessing.colorGradingTexture = colorGradingTexture;
                defaultPipeline.imageProcessing.colorGradingWithGreenDepth = false;
                */
            }
            /* color curves */
            defaultPipeline.imageProcessing.colorCurvesEnabled = false; // false by default
            if (defaultPipeline.imageProcessing.colorCurvesEnabled) {
                var curve = new BABYLON.ColorCurves();
                curve.globalDensity = 0; // 0 by default
                curve.globalExposure = 0; // 0 by default
                curve.globalHue = 30; // 30 by default
                curve.globalSaturation = 0; // 0 by default
                curve.highlightsDensity = 0; // 0 by default
                curve.highlightsExposure = 0; // 0 by default
                curve.highlightsHue = 30; // 30 by default
                curve.highlightsSaturation = 0; // 0 by default
                curve.midtonesDensity = 0; // 0 by default
                curve.midtonesExposure = 0; // 0 by default
                curve.midtonesHue = 30; // 30 by default
                curve.midtonesSaturation = 0; // 0 by default
                curve.shadowsDensity = 0; // 0 by default
                curve.shadowsExposure = 0; // 0 by default
                curve.shadowsHue = 30; // 30 by default
                curve.shadowsDensity = 80;
                curve.shadowsSaturation = 0; // 0 by default;
                defaultPipeline.imageProcessing.colorCurves = curve;
            }
        }
        /* bloom */
        defaultPipeline.bloomEnabled = false; // false by default
        if (defaultPipeline.bloomEnabled) {
            defaultPipeline.bloomKernel = 64; // 64 by default
            defaultPipeline.bloomScale = 0.5; // 0.5 by default
            defaultPipeline.bloomThreshold = 0.9; // 0.9 by default
            defaultPipeline.bloomWeight = 0.15; // 0.15 by default
        }
        /* chromatic abberation */
        defaultPipeline.chromaticAberrationEnabled = false; // false by default
        if (defaultPipeline.chromaticAberrationEnabled) {
            defaultPipeline.chromaticAberration.aberrationAmount = 30; // 30 by default
            defaultPipeline.chromaticAberration.adaptScaleToCurrentViewport = false; // false by default
            defaultPipeline.chromaticAberration.alphaMode = 0; // 0 by default
            defaultPipeline.chromaticAberration.alwaysForcePOT = false; // false by default
            defaultPipeline.chromaticAberration.enablePixelPerfectMode = false; // false by default
            defaultPipeline.chromaticAberration.forceFullscreenViewport = true; // true by default
        }
        /* DOF */
        defaultPipeline.depthOfFieldEnabled = false; // false by default
        if (defaultPipeline.depthOfFieldEnabled && defaultPipeline.depthOfField.isSupported) {
            defaultPipeline.depthOfFieldBlurLevel = 0; // 0 by default
            defaultPipeline.depthOfField.fStop = 1.4; // 1.4 by default
            defaultPipeline.depthOfField.focalLength = 50; // 50 by default, mm
            defaultPipeline.depthOfField.focusDistance = 2000; // 2000 by default, mm
            defaultPipeline.depthOfField.lensSize = 50; // 50 by default
        }
        /* FXAA */
        defaultPipeline.fxaaEnabled = false; // false by default
        if (defaultPipeline.fxaaEnabled) {
            defaultPipeline.fxaa.samples = 1; // 1 by default
            defaultPipeline.fxaa.adaptScaleToCurrentViewport = false; // false by default
        }
        /* glowLayer */
        defaultPipeline.glowLayerEnabled = false;
        if (defaultPipeline.glowLayerEnabled) {
            defaultPipeline.glowLayer.blurKernelSize = 16; // 16 by default
            defaultPipeline.glowLayer.intensity = 1; // 1 by default
        }
        /* grain */
        defaultPipeline.grainEnabled = false;
        if (defaultPipeline.grainEnabled) {
            defaultPipeline.grain.adaptScaleToCurrentViewport = false; // false by default
            defaultPipeline.grain.animated = false; // false by default
            defaultPipeline.grain.intensity = 30; // 30 by default
        }
        /* sharpen */
        defaultPipeline.sharpenEnabled = false;
        if (defaultPipeline.sharpenEnabled) {
            defaultPipeline.sharpen.adaptScaleToCurrentViewport = false; // false by default
            defaultPipeline.sharpen.edgeAmount = 0.3; // 0.3 by default
            defaultPipeline.sharpen.colorAmount = 1; // 1 by default
        }
    }
```

As usual, a playground is available to check out: <Playground id="#ECI2Q0#5" title="Default Rendering Pipeline Template Code" description="Simple playground with cut and paste code for the default rendering pipeline."/>



# How To Use Depth-of-field and other Lens Effects

`BABYLON.LensRenderingPipeline` is a predefined chain of postprocesses that helps achieve photographic realism.

![DoF example](/img/how_to/depth-of-field/example01.webp)  
_An example of what can be achieved with this postprocess pipeline._

You can see a live example of it here:

<Playground id="#DX6AV#4" title="Depth of Field Example" description="Simple example showcasing depth of field."/>

Three post-processes are used in the pipeline:

- First, a _'chromatic aberration'_ post-process, which very slightly shifts the red, green, and blue channels on screen. This effect is stronger on the edges. 
- Second, a _'highlights enhancing'_ post-process, which keeps only highlights in the scene, to be used in the depth-of-field blur
- Third, a _'depth-of-field'_ post-process, which actually does a bit more than that: 
  - blur on the edge of the lens 
  - lens distortion 
  - depth-of-field blur based on actual optics equation (the simulated lens has an inverse focal length of 0.1) 
  - depth-of-field 'bokeh' effect (shapes appearing in blurred areas) 
  - grain effect (noise or custom texture) 
  - darken out-of-focus objects 

# Usage ##

To use it, you must first define a set of parameters that will impact the actual post-processing performed. This is done by defining an object and setting the desired properties:
```javascript
var parameters = {
  edge_blur: 1.0,
  chromatic_aberration: 1.0,
  distortion: 1.0,
  // etc.
};
```

And then simply create the object with the parameters you've defined earlier, like so:
```javascript
var lensEffect = new BABYLON.LensRenderingPipeline('lensEffects', parameters, scene, 1.0, camera);
```
Note that in the above example, the pipeline is immediately attached to the camera, but this is not mandatory. You can also use it like this:
```javascript
var lensEffect = new BABYLON.LensRenderingPipeline('lensEffects', parameters, scene, 1.0);
// ...
scene.postProcessRenderPipelineManager.attachCamerasToRenderPipeline('lensEffects', camera);
```

Here is a list of properties you may set on your parameters object:

| Property | Type | Description |
|--------|--------|--------|
|`chromatic_aberration`|number|0 means effect is disabled, 1 is for realism. Defines the spread of the RGB channels in the chromatic aberration shader.|
|`edge_blur`|number|0 means effect is disabled, 1 is for realism. Defines the amount of blur that will appear on the corners of the screen.|
|`distortion`|number|0 means effect is disabled, 1 is for realism. Defines the amount of lens-like distortion. Note that this will affect pointer position precision.|
|`grain_amount`|number|Varies from 0 to 1. Amount of grain to blend on screen.|
|`grain_texture`|BABYLON.Texture|Texture to use for grain effect; if unset, a random B&W noise is used instead.|
|`dof_focus_distance`|number|The distance at which focus is set. Everything out of focus will be blurred. Note that a focus distance above a few hundred units gives you infinity focus.|
|`dof_aperture`|number|Default: 1. How quickly things outside of focus will become blurred. Set high to give a 'miniature' effect (a.k.a. _tilt shift_).|
|`dof_darken`|number|Default: 0. How much should out-of-focus objects be darkened. This effect should be used lightly! Set to 0 to disable.|
|`dof_pentagon`|boolean|Default: true. Makes a pentagon-like "bokeh" effect. "Bokeh" is a term for artifacts appearing when objects are very blurred: bright spots will often produce sharp geometric shapes, depending on the type of the lens.|
|`dof_gain`|number|Default: 1. How much highlights on blurred objects should be enhanced. Set to 0 to disable highlights enhancing.|
|`dof_threshold`|number|Default: 1. How wide should highlights be on blurred objects.|
|`blur_noise`|boolean|Default: true. Adds a very slight noise on the blur effect for out-of-focus objects.|

The `BABYLON.LensRenderingPipeline` object should be saved if you want to tweak the effects after creation. This can be done with the following self-explanatory methods:

| Methods |
|--------|
|`setEdgeBlur(amount: number)`|
|`disableEdgeBlur()`|
|`setGrainAmount(amount: number)`|
|`disableGrain()`|
|`setChromaticAberration(amount: number)`|
|`disableChromaticAberration()`|
|`setEdgeDistortion(amount: number)`|
|`disableEdgeDistortion()`|
|`setHighlightsGain(amount: number)`|
|`setHighlightsThreshold(amount: number)`|
|`setFocusDepth(amount: number)`|
|`disableDepthOfField()`|
|`setAperture(amount: number)`|
|`setDarkenOutOfFocus(amount: number)`|
|`enablePentagonBokeh()`|
|`disablePentagonBokeh()`|
|`setAperture(amount: number)`|
|`enableNoiseBlur()`|
|`disableNoiseBlur()`|


# A Word Of Advice ##

These effects are based on general approximations of real-world optical phenomena. As such, some situations may end up looking a bit off or even completely wrong. Tweaking the parameters (including on-the-fly adjustments) will allow you to mitigate these problems, for example by lowering the aperture in situations where you know that blurred objects will not render correctly.

Keep in mind that the approximation used does not give good results when an object inside focus is rendered on top of a strongly blurred one, or the other way around. Bleeding around one object or the other will probably occur in this case.

Finally, these effects can be pretty intensive on the GPU. A lower blur effect (i.e. a smaller blur radius) will be less demanding, so you can try lowering the aperture instead of disabling it altogether. Highlight enhancing is also quite intensive, so be sure that this effect contributes to the quality of your render if you have it active.



## Introduction
You can find an example of the motion blur post-process in our playground: <Playground id="#E5YGEL#2" title="Motion Blur Post Process Example" description="Simple example of the motion blur post process."/>

## Creating the motion blur post-process

You only need to create an instance of `BABYLON.MotionBlurPostProcess`.
```javascript
var motionblur = new BABYLON.MotionBlurPostProcess(
    "mb", // The name of the effect.
    scene, // The scene containing the objects to blur according to their velocity.
    1.0, // The required width/height ratio to downsize to before computing the render pass.
    camera // The camera to apply the render pass to.
);
```

The blur is based on object velocities. The faster an object's transformation changes, the stronger the blur on that object. Velocity is affected by each object's position, rotation, and scale:
- Rotation: <Playground id="#9LRA3T#4" title="Rotational Motion Blur" description="Simple example showing rotational motion blur."/>
- Scale: <Playground id="#9LRA3T#6" title="Scaling Motion Blur" description="Simple example of motion blur based on scale."/>
- Position: <Playground id="#9LRA3T#8" title="Positional Motion Blur" description="Simple example of motion blur based on position."/>

## Customizing
By default, the post-process will blur the scene using a coefficient named `motionStrength`. Its default value is equal to `1` and can be customized:
```javascript
motionblur.motionStrength = 2; // double the blur effect
```
Example: <Playground id="#9LRA3T#10" title="Customizing Motion Blur" description="Simple example of customizing the motion blur post process."/>

For performance/quality reasons, you can also customize the blur quality. To blur an image, the effect takes some samples around the current pixel. The more samples you take, the higher the blur quality. You can customize the number of samples using the `motionBlurSamples` property. Its default value is `32`:
```javascript
motionblur.motionBlurSamples = 16; // divide quality by 2
```

## Optimizing your application
By default, the post-process will blur all objects that generate a velocity (position, rotation, and scale). This also includes skinned meshes animated by their bones.
Sometimes, complex skinned meshes can have too many bones and can cause a drop in frame rate. You can choose to exclude a skinned mesh from bone computation while rendering the velocity map and apply blur only to its position/rotation/scale variation. The `MotionBlurPostProcess` provides a helper to add and remove skinned meshes:
```javascript
// Now, the mesh "mySkinnedMesh" will not compute bones velocities and will save performances.
motionblur.excludeSkinnedMesh(mySkinnedMesh);
```

```javascript
// Previously excluded, the mesh "mySkinnedMesh" will now compute bones velocities for a better render.
motionblur.removeExcludedSkinnedMesh(mySkinnedMesh);
```

## Limitations
To improve performance, the motion blur velocity map is rendered at the same time as the depth and normal buffers using the geometry render buffer.
The clear color of the render buffer collides with the needed clear color of the velocity map and can generate glitches like this: <Playground id="#E5YGEL#3" title="Limitations In The Motion Blur Post Process" description="Simple example showcasing colliding visual artifacts between the clear color of the render buffer and the velocity map."/>. As a limitation, your scene must occur in a closed environment OR have at least a skybox to hide the empty space that causes these glitches.

# Notes
The Motion Blur post-process requires at least WebGL 2 support, or WebGL 1 support with multiple render targets. If neither is available, the post-process will work as a passthrough.

## Disabling Object-Based Motion Blur
By default, the motion blur post-process uses object-based velocity to calculate blur. In large scenes, calculating the velocity of every visible object can be costly. Object-based velocity can be disabled to fall back to screen-based mode. Screen-based mode avoids calculating object velocities by basing the velocity only on the camera's movement.

To enable screen-based mode, simply disable object-based mode on the post-process:
```javascript
// Disable object-based mode in order to enable screen-based mode.
motionblur.isObjectBased = false;
```

Example: <Playground id="#E5YGEL#7" title="Screen-Based Motion Blur" description="Simple example of customizing the motion blur post process to disable object-based mode."/>



# How to use PostProcessRenderPipeline
Post process render pipelines allow you to create a chain of post processes and attach it to a camera.
A render pipeline can be managed by enabling and disabling some effects and displaying a specific pass for debugging.


## Base Render Pipeline

![](/img/PPArchitecture.webp)

Render pipelines are composed of several classes.

| Class | Description |
|--------|--------|
|**`BABYLON.PostProcessRenderPipelineManager`**|Manages all pipelines and allows you to enable or disable an effect, or display a post-process pass for debugging.|
|**`BABYLON.PostProcessRenderPipeline`**|Set of effects that can be ordered.|
|**`BABYLON.PostProcessRenderEffect`**|A render effect contains one or more post processes.|
|**`BABYLON.PostProcess`**|A render pass that applies a shader.|

## Let's Work with a Render Pipeline

### Simple Pipeline
Create a pipeline:
```javascript
var standardPipeline = new BABYLON.PostProcessRenderPipeline(engine, "standardPipeline");
```

Create post processes. Note: the camera parameter is set to `null` when using a pipeline, and the post process will be enabled when the pipeline is added to the camera.
```javascript
var blackAndWhite = new BABYLON.BlackAndWhitePostProcess("bw", 1.0, null, null, engine, false);
var horizontalBlur = new BABYLON.BlurPostProcess("hb", new BABYLON.Vector2(1.0, 0), 20, 1.0, null, null, engine, false);
```

Create an effect with multiple post processes:
```javascript
var blackAndWhiteThenBlur = new BABYLON.PostProcessRenderEffect(engine, "blackAndWhiteThenBlur", function() { return [blackAndWhite, horizontalBlur] });
standardPipeline.addEffect(blackAndWhiteThenBlur);
```

Add the pipeline to the scene's manager and attach it to the camera:
```javascript
scene.postProcessRenderPipelineManager.addPipeline(standardPipeline);
scene.postProcessRenderPipelineManager.attachCamerasToRenderPipeline("standardPipeline", camera);
```

<Playground id="#QCGFI6" title="Post Process Render Pipeline Example" description="Simple example of using a post process render pipeline."/>


## How to use RenderTargetTexture and run multiple passes

Sometimes it is useful to render a scene multiple times and compose the generated passes into the final image. There are multiple uses for this: you can generate a texture in real time to make, for example, a car rearview mirror, or you can perform complex effects with multiple independent renders that are combined together. 

The PostProcess API doesn't let you render a scene twice. That's where RenderTargetTexture (RTT) comes into play. Several [games use multiple passes for their graphics](http://www.adriancourreges.com/blog/2016/09/09/doom-2016-graphics-study/).

## Creating a RenderTargetTexture

You need to create a RenderTargetTexture and attach it to the scene. It's pretty straightforward:

```    
var renderTarget = new BABYLON.RenderTargetTexture(
    'render to texture', // name 
    512, // texture size
    scene // the scene
);
scene.customRenderTargets.push(renderTarget); // add RTT to the scene
```

You also need to pick which objects will be rendered to that texture. This enables you to select only a few objects for a particular effect, or use simpler meshes for faster rendering.

```
let sphere = BABYLON.MeshBuilder.CreateSphere("sphere", {diameter: 2, segments: 32}, scene); // create your mesh
renderTarget.renderList.push(sphere); // add it to the RTT
```

## Using the RTT in your scene as a regular texture

You can use the rendered image as the texture of an object in your main render. Just set it as the texture of a material:

```
var mat = new BABYLON.StandardMaterial("RTT mat", scene);
mat.diffuseTexture = renderTarget;
```

In this example, we only add half of the spheres to the RTT, showing how you can selectively choose which objects are rendered there.

Playground example: <Playground id="#69DRZ1" title="Render Target Texture" description="Simple example of using the render target texture."/>

In this example we add two meshes, pool and ground, to the RTT and distort the UVs of the texture applied to the water plane using a node material to simulate refraction of the mesh behind the water plane.

Playground example: <Playground id="#7ILX7T" title="Water Refraction with RTT" description="Render Target Texture used to simulate water refraction." image="/img/playgroundsAndNMEs/NMEwaterRefractionRTT.webp" />

## Making multiple passes and composing them

Another possibility, as mentioned, is to make multiple render passes from the main camera and compose them. Let's do that by adding a simple effect to all meshes and composing it with the original material. One interesting effect to simulate with this technique is water caustics. We can render the scene with a material that simulates caustics using a wave generator and mix it with the base texture.

Since v5.0 it's very easy to use a different material than the regular material (`mesh.material`) when a mesh is rendered into a render target texture: simply use `RenderTargetTexture.setMaterialForRendering(meshOrMeshes, material)`.

```javascript
const causticMaterial = new BABYLON.ShaderMaterial(
    'caustic shader material', // human name
    scene,
    'caustic', // shader path
    {
        attributes: ['position', 'normal', 'uv'],
        uniforms: ['world', 'worldView', 'worldViewProjection', 'view', 'projection', 'time', 'direction']
    }
);

// the render texture. We'll render the scene with caustic shader to this texture.
const renderTarget = new BABYLON.RenderTargetTexture('caustic texture', 512, scene);
scene.customRenderTargets.push(renderTarget);

renderTarget.setMaterialForRendering(ground, causticMaterial);
```

For the final pass, we'll create a shader to merge the base render (which will be provided in the [GLSL](https://www.khronos.org/opengl/wiki/OpenGL_Shading_Language) as `textureSampler`) and the caustic texture, which we declare here as `causticTexture`. 

```javascript
// create the final pass composer
var finalPass = new BABYLON.PostProcess(
    'Final compose shader', 
    'final', // shader name
    null, // attributes
    [ 'causticTexture' ], // textures
    1.0,  // options
    camera,
    BABYLON.Texture.BILINEAR_SAMPLINGMODE, // sampling
    engine // engine
);
finalPass.onApply = (effect) => {
    effect.setTexture('causticTexture', renderTarget); // pass the renderTarget as our second texture
};
```

Playground example: <Playground id="#TG2B18#60" title="Multiple Passes Example" description="Simple example showing how to run multiple passes with the render target texture." isMain={true} category="Post-processing"/>. On the left you'll see the base render, in the middle the caustic render, and on the right both combined together.

## Performance and tips

Remember that you'll be rendering your scene multiple times, one for each pass. This can significantly slow things down if you are not careful. There are a number of strategies to improve performance:

- reduce the RTT size.
- render as few objects as you can on the RTT.
- use a simple shader on the RTT pass.
- prefer simpler meshes.
- use instances. If you have a large amount of copies of the same object, instances are a good optimization. You only change the material of the base mesh.

Replacing materials is an expensive operation in Babylon, as it requires a resync from the CPU. If your meshes use materials such as `ShaderMaterial` or `PBRMaterial`, this might significantly impact the frame rate. The example above is simple to follow and helps explain the concept, but there is a way to achieve much better performance by freezing materials. Here's how to do it.

Note that since v5.0, you don't need to add complicated code in the `RTT.onBeforeRender` / `RTT.onAfterRender` observers to save or replace the effects manually. You just have to freeze the materials that you know won't change, and you're good to go!

First, create objects that will be in the RTT with clones of the RTT shader material.

```javascript
// helper function to create clones of the caustic material
// we need that because we'll have different transforms on the shaders
let rttMaterials = [];
const getCausticMaterial = () => {
    let c = rttMaterial.clone();
    c.freeze(); // freeze because we'll only update uniforms
    rttMaterials.push(c);
    return c;
};

// some material for the ground.
var grass0 = new BABYLON.StandardMaterial("grass0", scene);
grass0.diffuseTexture = new BABYLON.Texture("textures/grass.png", scene);
grass0.freeze();

// Our built-in 'ground' shape.
var ground = BABYLON.MeshBuilder.CreateGround("ground", {width: 6, height: 6}, scene);
ground.material = grass0;
// add caustics
renderTarget.setMaterialForRendering(ground, getCausticMaterial());
renderTarget.renderList.push(ground);
```

Apply any uniforms on all material clones:

```javascript
scene.onBeforeRenderObservable.add(() => {
    // ... 
    rttMaterials.forEach((c) => c.setFloat('time', timeDiff));
});
```

The example has the complete code, including animated objects and instances. You could freeze some meshes with `scene.freezeActiveMeshes()` to improve the performance even further.

Playground example: <Playground id="#S1W87B#42" title="Performance Example" description="Example of managing performance when running multiple passes."/>


### Notes about your shader

Note that since you replace the material with a shader from scratch for mesh instances, you need to handle effects such as animation or instance transformations, and this will affect your vertex shader (and possibly your fragment shader as well). There are [several includes in Babylon](https://github.com/BabylonJS/Babylon.js/tree/master/packages/dev/core/src/Shaders/ShadersInclude) that help with that. Here's a sample vertex shader with support for bone animations and instances:

```glsl
precision highp float;

attribute vec3 position;
attribute vec2 uv;

uniform mat4 view;
uniform mat4 projection;
uniform mat4 worldViewProjection;

varying vec2 vUV;

#include<bonesDeclaration>
#include<instancesDeclaration>

void main() {
    vec3 positionUpdated = position;

    #include<instancesVertex>
    #include<bonesVertex>

    vec4 worldPos = finalWorld * vec4(positionUpdated, 1.0);

    vUV = uv;

    gl_Position = projection * view * worldPos;
}
```

### Debugging multiple passes

Your final composer might become a complicated shader, and each pass might be complicated in itself. You certainly will need to debug shaders along the way. One way to easily debug individual passes is to show only that pass to the screen, commenting the rest of the code.

```
varying vec2 vUV;
uniform sampler2D somePassTexture;

void main() {
    // comment other code
    vec4 debugColor = texture2D(someTexture, vUV);
    gl_FragColor = debugColor;
}
```

Testing passes separately and then adding them one at a time to the composer will make it easier to debug any issues. You can also use the technique from the playgrounds above, splitting the screen into columns, each with a different pass.

Finally you can also check RT textures with the [Babylon inspector](/toolsAndResources/inspectorv2).



<span style={{"color": "red"}}>This post process is deprecated starting with v5.48.0! It is superseded by the [Screen Space Reflections Rendering Pipeline](/features/featuresDeepDive/postProcesses/SSRRenderingPipeline).</span>

## Introduction
Rendering reflections in real time can be done using several methods. Each method has its own pros and cons. For web technologies, two main methods exist:
* **Using a Mirror Texture**:
    * pros: renders perfect reflections on a plane.
    * cons: limited to one reflection direction and complexity grows according to the scene's geometries.
* **Using a SSR post-process**:
    * pros: renders all possible reflections in all directions and complexity only depends on the screen's resolution (as all post-processes).
    * cons: limited to what the camera sees.

As an example, with SSR enabled (look at the water-tank):
![with_ssr](/img/how_to/screenSpaceReflectionsPostProcess/with_ssr.webp)

With SSR disabled:
![with_ssr](/img/how_to/screenSpaceReflectionsPostProcess/without_ssr.webp)

You can find a simple example of the SSR post-process in our playground: 
- <Playground id="#PIZ1GK" title="SSR Post Process Example - Standard material" description="Simple example of the screen space reflection Post Process, with Standard material"/>
- <Playground id="#PIZ1GK#303" title="SSR Post Process Example - PBR material" description="Simple example of the screen space reflection Post Process, with PBR material"/>

## Prerequisite
To render reflections using the SSR post-process, the device must support WebGL 2 or at least the multiple render targets extension for WebGL 1. If not supported, the post-process will just work as a pass-through.

For any reflective geometry in your scene, the post-process must know its "reflectivity" properties. To provide this information, your reflective meshes must contain:
* a **Standard Material**: a specular texture. The specular texture will be used to know how much the object reflects for each pixel.
* a **PBR Material**: a reflectivity texture. The post-process still doesn't support the roughness/metallic properties, for instance, but this will be available in the future. That means the post-process takes the reflectivity texture as-is and doesn't compute any metallic/roughness workflow.

In other words, don't forget to assign a specular texture or a reflectivity texture to your material if you want reflections enabled on it.

```javascript
// For a BABYLON.StandardMaterial
myMaterial.specularTexture = new BABYLON.Texture("textures/specular.png", scene);
```

```javascript
// For a BABYLON.PBRMaterial
myMaterial.reflectivityTexture = new BABYLON.Texture("textures/reflectivity.png", scene);
```

**Note: the SSR post-process is a fairly demanding post-process. It is not intended to work smoothly on low-end devices and requires a powerful enough device.**

## Creating the SSR post-process
Just create an instance of BABYLON.ScreenSpaceReflectionPostProcess:
```javascript
var ssr = new BABYLON.ScreenSpaceReflectionPostProcess(
    "ssr", // The name of the post-process
    scene, // The scene where to add the post-process
    1.0, // The ratio of the post-process
    camera // To camera to attach the post-process
); 
```

## Customizing

## Strength
The strength is applied to the overall specular/reflectivity information in the scene and can be customized. The default value for the strength is 1.0 and should be changed only if you are looking for a particular result, because the result will not be realistic.

```javascript
// Double specular/reflectivity strength.
ssr.strength = 2;
```

Example playground: <Playground id="#PIZ1GK#3" title="SSR Reflective Strength Example" description="Simple example of the reflective strength of the screen space reflection post process."/>

## Falloff Exponent
The falloff exponent is used to linearly reduce the reflection's intensities. The default value is "3.0" and works for most cases.

```javascript
// Reduce more the reflection's intensities
ssr.reflectionSpecularFalloffExponent = 4;
```

Example playground with an almost equal to 0 exponent: <Playground id="#PIZ1GK#2" title="SSR Falloff Example" description="Simple example falloff in the screen space reflection post process."/>

## Quality
The reflection quality can be customized to save performance and should be adjusted for each scene type. 

The post-process is based on ray-tracing algorithms. That means the more samples the post-process takes, the better the result looks.

The quality is defined as:
* Low: 25 samples.
* Medium: 50 samples.
* High: 100 samples.

Depending on the scene, the difference between medium and high quality may not be noticeable, because the ray-tracing algorithm stops once it finds the reflection color. In other words, high quality will not always be needed.

- High quality playground: <Playground id="#PIZ1GK#7" title="High Quality SSR Example" description="Example of high quality screen space reflections."/>
- Medium quality playground: <Playground id="#PIZ1GK#5" title="Medium Quality SSR Example" description="Example of medium quality screen space reflections."/>
- Low quality playground: <Playground id="#PIZ1GK#6" title="Low Quality SSR Example" description="Example of low quality screen space reflections."/>


## The standard pipeline is no longer maintained.

[Default pipeline](/features/featuresDeepDive/postProcesses/defaultRenderingPipeline) should be used going forward, but the standard pipeline will be kept for backward compatibility.

## Introduction

This rendering pipeline simulates a chain of well-known post-process effects such as:

-   Lens imperfections (overexposed surfaces are highlighted)
-   Dirty lens effect
-   Depth of field
-   Motion Blur
-   Volumetric Lights

Simple playground: <Playground id="#FRUD8#2" title="Standard Rendering Pipeline Example" description="Simple example of the standard rendering pipeline."/>
Full playground: <Playground id="#X3XD2C#1" title="Standard Rendering Pipeline Example (full example)" description="Full example of the standard rendering pipeline."/>

## Creating the rendering pipeline

Just create an instance of BABYLON.StandardRenderingPipeline

```
var pipeline = new BABYLON.StandardRenderingPipeline(
    "standard", // The name of the pipeline
    scene, // The scene instance
    1.0, // The rendering pipeline ratio
    null, // The original post-process that the pipeline will be based on
    [camera] // The list of cameras to be attached to
);
```

## Customizing

## Bright threshold

Highlighted surfaces follow a configured numeric threshold.
Each pixel whose intensity is above the given threshold creates lens imperfections.
Just set the ".brightThreshold" property:

```
pipeline.brightThreshold = 0.8;
```

## Change exposure

To globally intensify the highlighted surfaces result before it is merged with the final scene color, you can change the `.exposure` property:

```
pipeline.exposure = 1.0; // which multiplies the final scene color with the highlighted surfaces result
```

## Blur width

The blur width (or kernel size) can be customized and is equal to 512 by default.

```
pipeline.exposure = 128; // Blur is less expansive and is less spreaded
```

## Setting up the dirty lens effect

To add a dirty lens effect, you can set the ".lensTexture" mask texture (background must be black) which will be applied on the screen following the highlighted surfaces:

```
// Just create a new BABYLON.Texture containing the dirty lens mask
pipeline.lensTexture = new BABYLON.Texture("lensdirt.jpg", scene);
```

A dirty lens mask should look like:

![DirtyLensTexture](/img/how_to/advanced/standardRenderingPipeline/lensdirt.webp)

## Setting up the pseudo lens flare

### Setting up textures

First, to activate the pseudo lens flare effect, just set the ".LensFlareEnabled" to true:

```
// Activating pseudo lens flare effect
pipeline.LensFlareEnabled = true;
```

Now, in order to work properly with the dirty lens effect (above), you can set your own dirt texture, which can be the same as the dirty lens effect. For example:

```
pipeline.lensTexture = pipeline.lensFlareDirtTexture = new Texture("lensdirt.jpg", scene);

// or

pipeline.lensFlareDirtTexture = new Texture("lens_flare_dirt.jpg", scene);
```

Now, you can add a "starbust" texture. This will disturb the final result and make it more realistic:

```
pipeline.lensStarTexture = new Texture("lensstar.jpg", scene);
```

![StarbustTexture](/img/how_to/advanced/standardRenderingPipeline/lensstar.webp)

which gives:

![StarbustTextureResult](/img/how_to/advanced/standardRenderingPipeline/lensstarresult.webp)

Finally, you can apply a palette of colors which will be used by the post-processes to disturb the lens flare colors:

```
pipeline.lensColorTexture = new Texture("lenscolor.png", scene);
```

A color texture should look like:

![LensColorTexture](/img/how_to/advanced/standardRenderingPipeline/lenscolor.webp)

### Setting up parameters

Once you added the textures, you can customize some parameters that will allow you to customize the final result:

The strength:

```
// The strength of the final result of the pseudo lens flare effect
pipeline.lensFlareStrength = 5; // By default 1.0
```

The halo width:

```
// Sets the width of the halo used to render the pseudo lens flare effect
pipeline.lensFlareHaloWidth = 1; // By default 0.4;
```

![HaloWidth](/img/how_to/advanced/standardRenderingPipeline/halo_width.webp)

The distortion strength:

```
// The strength related to the lens color texture
pipeline.lensFlareDistortionStrength = 35; // Default 4.0
```

## Setting up Luminance Adaptation

The standard rendering pipeline now allows you to compute luminance adaptation. This process simulates real-life behavior:
if you focus on a highly bright zone, the camera will adapt itself. In other words, this technique allows you to create
glare effects, and it is also linked to what we call "_HDR_".

### Customizing luminance adaptation

First, let's activate the luminance adaptation:

```
pipeline.HDREnabled = true;
```

That's all! Now, let's customize some properties:

```
// 1.0 is the default value. In dark zones, the camera will tend to adapt luminance
// and get the global image less dark. More the value is near 0.0, more the image will be bright
pipeline.hdrMinimumLuminance = 1.0;

// 0.5 is the default value. This simply sets the speed when the camera adapts the luminosity
// in bright zones
pipeline.hdrDecreaseRate = 0.5;

// 0.5 is the default value. This simply sets the speed when the camera adapts the luminosity
// in dark zones
pipeline.hdrIncreaseRate = 0.5;
```

## Setting up the depth of field

### Activating the depth of field

To activate the depth of field, simply set the property ".DepthOfFieldEnabled" to true:

```
// Active depth of field
pipeline.DepthOfFieldEnabled = true;
```

### Customizing depth of field distance

To manipulate depth of field, you can set the distance to blur by setting the ".depthOfFieldDistance" property. This property represents the distance to focus on:

```
// Focus on 20 units
pipeline.depthOfFieldDistance = 20;
```

Playground example: <Playground id="#LB63T#1" title="Custom Depth of Field Example" description="Simple example of custom depth of field distance."/>

**note: Activating the depth of field will activate the depth renderer of Babylon.js, which can have an impact on performances**

## Setting up the Motion Blur

As a demo, have a look at this video:

<Youtube id="14Ejsj1_ywM"/>

Motion Blur simply tries to blur the overall image when the camera moves fast.

## Customizing Motion Blur

```
// Enable motion blur in the pipeline
pipeline.MotionBlurEnabled = true;

// Default value is 1.0. More the motion strength is high, more the blur will be high
pipeline.motionStrength = 0.5;

// Default value is 64.0. This property represents the quality of the effect. More the value is high
// more the blur will be high quality. 64.0 is enough to have a beautiful result
pipeline.motionBlurSamples = 32.0;
```

**note: Activating the Motion Blur will activate the depth renderer of Babylon.js, which can have an impact on performances**

## Setting up volumetric lights

Volumetric Lights, as seen in the playground available in the introduction, can be computed with a post-process.

**note: Volumetric Lights require to have the multiple render targets support, basically WebGL 2 support**

<Youtube id="UKdWPj7VRu0"/>

## Customizing volumetric lights

```
// Enable Volumetric Lights computation in the pipeline
pipeline.VLSEnabled = true;

// First, give the source light to the pipeline which must be a spot light or a directional light
// The volumetric lights post-process needs a shadow map in order to work: it is used to test obstacles for the light rays
// Then, the source light mush have a shadows generator:
pipeline.sourceLight = <SpotLight> scene.getLightByName("spotLight");

// This represents the intensity of fog in the air. In other words, the light rays intensity in the shadow
pipeline.volumetricLightPower = 4;

// This represents the overall quality of the volumetric lights post-process in interval [0, 100].
// The default value is 50.0 and is enough for a good result
pipeline.volumetricLightStepsCount = 50;
```



## Base postprocess

Every postprocess is based upon `BABYLON.PostProcess` which uses this constructor:

```javascript
BABYLON.PostProcess = function (name, fragmentUrl, parameters, samplers, ratio, camera, samplingMode, engine, reusable)
```

We will get back to the _fragmentUrl_, _parameters_, and _samplers_ parameters.

The _ratio_ is used to define the size of the postprocess (0.5 means that your postprocess will have a width = canvas.width _ 0.5 and a height = canvas.height _ 0.5).

The _camera_ parameter specifies which camera to attach to. If you're creating a post process that will be managed by a render pipeline, this should be set to null. See [Post Process Pipeline](/features/featuresDeepDive/postProcesses/postProcessRenderPipeline)

The _samplingMode_ can be one of the following:

- BABYLON.Texture.NEAREST_SAMPLINGMODE
- BABYLON.Texture.BILINEAR_SAMPLINGMODE (**default**)
- BABYLON.Texture.TRILINEAR_SAMPLINGMODE

Please note that postprocesses with trilinear sampling will be forced to have a power-of-two size (256, 512, 1024, etc.)

The _engine_ parameter is the engine where you want to attach your postprocess.

The _reusable_ parameter indicates whether your postprocess can be reused multiple times on the same camera (default is false).

## Additional parameters

By default (and if you are not using trilinear sampling), postprocesses use the size of the screen scaled by the ratio you provide. But you can decide to force them to be rescaled to a power-of-two size to make them more efficient. To enable this, just call `mypostprocess.alwaysForcePOT = true`.

You can also control how the size is chosen by setting `mypostprocess.scaleMode` to one of these values:

- BABYLON.Engine.SCALEMODE_FLOOR: Will find the next lowest power of two.
- BABYLON.Engine.SCALEMODE_NEAREST: Will find the nearest power of two.
- BABYLON.Engine.SCALEMODE_CEILING: Will find the next highest power of two.

You can also control if the postprocess is cleared upon rendering with `mypostprocess.autoClear = true`. This is the default behavior.

If you turn off autoClear, you will be able to blend the render of the postprocess with its previous content by defining an alphaMode with `mypostprocess.alphaMode = BABYLON.Engine.ALPHA_COMBINE`.

This could be really useful when you have multiple postprocesses enabled together. You can even choose to share the output of several postprocesses with `mypostprocess.shareOutputWith(anotherPostprocess)`.

## Attach postprocess

Depending on how you have defined a postprocess, it can be attached one or more times to the same camera.
The same instance can also be attached to multiple cameras.

A camera has two methods:

### **attachPostProcess**

```javascript
NUMBER function(PostProcess postProcess [,NUMBER atIndice])
```

### **detachPostProcess**

```javascript
NUMBER function(PostProcess postProcess [,NUMBER[] atIndices])
```

## Builtin postprocesses

Babylon.js comes with a set of ready-to-use postprocesses.

## Pass

Does nothing. It is used to copy the framebuffer into a postprocess for further use.

```javascript
var postProcess = new BABYLON.PassPostProcess("Scene copy", 1.0, camera);
```

### Black and white

Apply a black and white effect:

```javascript
var postProcess = new BABYLON.BlackAndWhitePostProcess("bandw", 1.0, camera);
```

## Blur

Apply a directional blur using a kernel-based blur:

```javascript
var postProcess = new BABYLON.BlurPostProcess("Horizontal blur", new BABYLON.Vector2(1.0, 0), kernel, 0.25, camera);
```

The kernel value defines the ideal number of taps used by the postprocess. The postprocess will then adapt the kernel based on screen size and DPI resolution.

For instance here is an example with a kernel value of 32: <Playground id="#FBH4J7#3" title="Blur Post Process Example" description="Simple example of a blur post process."/>
Or 256: <Playground id="#FBH4J7#4" title="Blur Post Process With Kernel Value Of 256" description="Simple example of a blur post process with a kernel value of 256."/>

Obviously, as usual, try to stay reasonable with kernel size as it will impact the overall rendering speed.

### Convolution

Apply a kernel matrix to every pixel:

```javascript
var postProcess = new BABYLON.ConvolutionPostProcess("Sepia", BABYLON.ConvolutionPostProcess.EmbossKernel, 1.0, camera);
```

## FXAA

Apply a full screen antialiasing filter:

```javascript
var postProcess = new BABYLON.FxaaPostProcess("fxaa", 1.0, camera);
```

### Highlights

Apply a full screen highlight filter which will increment the luminosity of highlights in your scene:

```javascript
var postProcess = new BABYLON.HighlightsPostProcess("highlights", 1.0, camera);
```

### Tonemap

Apply a full screen tone mapping filter:

```javascript
var postProcess = new BABYLON.TonemapPostProcess("tonemap", BABYLON.TonemappingOperator.Hable, 1.0, camera);
```

The second parameter defines which operator will be used among the following ones:

- BABYLON.TonemappingOperator.Hable
- BABYLON.TonemappingOperator.Reinhard
- BABYLON.TonemappingOperator.HejiDawson
- BABYLON.TonemappingOperator.Photographic

The third parameter defines the exposure adjustment.

You can find a demo here: <Playground id="#J9H084#8" title="Tonemap Post Process" description="Simple Example of a tonemap post process."/>

### ImageProcessing

Apply a complete range of special image treatments (image processing):

```javascript
var postProcess = new BABYLON.ImageProcessingPostProcess("processing", 1.0, camera);
```

You have several options available:

- colorGradingTexture: Used to provide a color grading texture applied on your scene. You can use:
  - a [colorGradingTexture](/typedoc/classes/babylon.colorgradingtexture) using a [.3dl](https://en.wikipedia.org/wiki/3D_lookup_table) format. Demo: <Playground id="#17VHYI#15" title="ColorGrading Texture Post Process" description="Simple example of a colorgrading texture post process."/>
  - a standard texture (using .png for example) but with _invertY_ set to _true_, wrap mode as clamp and _imageProcessingConfiguration.colorGradingWithGreenDepth_ set to _false_. Demo: <Playground id="#17VHYI#9" title="ColorGrading Texture Post Process Green Depth" description="Simple example of a colorgrading texture post process."/>
- colorCurves: Used to provide several properties to change colors. More [details here](/features/featuresDeepDive/materials/using/masterPBR). Demo: <Playground id="#J9H084#12" title="ColorCurves Post Process" description="Simple example of a colorCurves post process."/>
- contrast: 1.0 by default. Used to change the contrast. Demo: <Playground id="#J9H084#615" title="colorCurves Post Process (Contrast)" description="Simple example of changing the contrast of a colorCurves Post Process."/>
- exposure: 1.0 by default. Used to change the exposure of the image. Demo: <Playground id="#J9H084#10" title="colorCurves Post Process (Exposure)" description="Simple example of changing the exposure of a colorCurves Post Process."/>

You can also use this postprocess to enable a vignette effect. The vignette is positioned thanks to the following parameters:

- vignetteStretch: 0 by default
- vignetteCentreX: X coordinate of the center (0,0 is the center of the screen)
- vignetteCentreY: Y coordinate of the center (0,0 is the center of the screen)
- vignetteWeight: 1.5 by default
- vignetteColor: Color4 value to define the overall color
- vignetteBlendMode: BABYLON.ImageProcessingPostProcess.VIGNETTEMODE_MULTIPLY or BABYLON.ImageProcessingPostProcess.VIGNETTEMODE_OPAQUE

You can find a demo of the vignette here: <Playground id="#J9H084#11" title="Vignette Post Process" description="Simple example of a Vignette Post Process."/>

All features can be turned on and off with the following booleans:

- colorCurvesEnabled
- vignetteEnabled
- cameraToneMappingEnabled
- colorGradingEnabled

#### Configuration

Image post-processing can be done with the ImageProcessingPostProcess, but you can also use the built-in image processing features in StandardMaterial and PBRMaterial. To simplify the overall configuration of your image processing setup, you can define the properties you want on `scene.imageProcessingConfiguration`.
This object hosts the same properties as the ImageProcessingPostProcess.

By default, ImageProcessingPostProcess, StandardMaterial and PBRMaterial share the same configuration object (The one from the scene). This means that if you change a value on `scene.imageProcessingConfiguration` or directly on ImageProcessingPostProcess, StandardMaterial or PBRMaterial, this will affect all entities sharing the same configuration.

Here is an example of a global configuration: <Playground id="#J9H084#13" title="Post Process Global Configuration" description="Simple example of a post process global configuration."/>

Furthermore, as they share the same configuration, you can simply dispose of a postprocess you were using, and the image processing will automatically be done at the material level. So here is an example of a configuration done at the scene level, but with no postprocess to use it: <Playground id="#J9H084#14" title="Configuration At The Scene Level" description="Simple example of a scene level configuration."/> (As you can see, the processing is then done by the material itself).

You can also decide to instantiate your own configuration and assign it to your material or your postprocess with `postProcess.imageProcessingConfiguration = new BABYLON.ImageProcessingConfiguration()`. In this case, you will be able to configure this object independently.

_Troubleshoot_
If you use post-processes with built-in image processing features, you might run into brighter color issues.  
Read [this](/features/featuresDeepDive/materials/shaders/image_processing#tonemapping) if you want to know how to fix it.

#### Default rendering pipeline

The image processing post process is also included in a rendering pipeline: the DefaultRenderingPipeline. This pipeline adds support for FXAA and bloom on top of the image processing. You can find a complete interactive demo here: <Playground id="#5XB8YT#1" title="Default Rendering Pipeline Featuring Bloom" description="Simple example of the default rendering pipeline with bloom."/>

You can turn pipeline features on and off with the following booleans:

- fxaaEnabled
- bloomEnabled
- imageProcessingEnabled

## Refraction

Apply a refraction texture:

```javascript
var postProcess = new BABYLON.RefractionPostProcess("Refraction", "refMap.jpg", new BABYLON.Color3(1.0, 1.0, 1.0), 0.5, 0.5, 1.0, camera);
```

The constructor of this postprocess is the following:

```javascript
BABYLON.RefractionPostProcess = function (name, refractionTextureUrl, color, depth, colorLevel, ratio, null, samplingMode, engine, reusable)
```

_refractionTextureUrl_ is the URL of the refraction map. The luminance of every pixel is used to define the refraction level (white = min, black = max)
_color_ is the base color of the refraction (used to tint the rendering)
_depth_ is the simulated refraction depth
_colorLevel_ is the coefficient of the base color (0 to remove base color tainting)

## Color Correction

Apply a color filter:

```javascript
var postProcess = new BABYLON.ColorCorrectionPostProcess("color_correction", "./table.png", 1.0, camera);
```

The second parameter of the constructor is the URL of the color look-up table (also known as _LUT_) that contains the filter to apply. This must be a texture 16 pixels high and 256 pixels wide containing a modified set of RGB colors (x=red value, y=green value, z=blue value). The post-processing will then map the RGB values of the rendered pixels to the new values contained in the look-up table.

Here is what the default (without filter) look-up table looks like:

![LUT](/img/how_to/post-processes/lut-default.webp)

Examples of filtered LUT to use for various filters:

![LUT](/img/how_to/post-processes/lut-inverted.webp)
 Inverted colors

![LUT](/img/how_to/post-processes/lut-highcontrast.webp)
 High contrast

![LUT](/img/how_to/post-processes/lut-posterized.webp)
 Posterize

You can easily create new filters by using image-editing software to alter the look-up table to fit your needs. Copy and paste the default look-up table onto a screenshot or picture before altering it to see in real time what the filtered image will look like.

## Custom postprocesses

You can also develop your own postprocess using the `BABYLON.PostProcess` object.

To do so, you need to create a .fragment.fx file, a shader-storing DOM node, or a ShaderStore entry where you will store the [GLSL](https://www.khronos.org/opengl/wiki/OpenGL_Shading_Language) shader code used for every pixel of the screen:

```javascript

precision highp float;

// Samplers
varying vec2 vUV;
uniform sampler2D textureSampler;

// Parameters
uniform vec2 screenSize;
uniform float highlightThreshold;

float highlights(vec3 color)
{
 return smoothstep(highlightThreshold, 1.0, dot(color, vec3(0.3, 0.59, 0.11)));
}

void main(void)
{
 vec2 texelSize = vec2(1.0 / screenSize.x, 1.0 / screenSize.y);
 vec4 baseColor = texture2D(textureSampler, vUV + vec2(-1.0, -1.0) * texelSize) * 0.25;
 baseColor += texture2D(textureSampler, vUV + vec2(1.0, -1.0) * texelSize) * 0.25;
 baseColor += texture2D(textureSampler, vUV + vec2(1.0, 1.0) * texelSize) * 0.25;
 baseColor += texture2D(textureSampler, vUV + vec2(-1.0, 1.0) * texelSize) * 0.25;
 
 baseColor.a = highlights(baseColor.rgb);

 gl_FragColor = baseColor;
}
```

Your shader must define the following values:

- Precision must be set to highp
- A varying vUV must be used to read texture coordinates
- The first sampler must be named textureSampler

Once you have created your shader, you can create a postprocess:

```javascript
var postProcess = new BABYLON.PostProcess("Down sample", "./Scenes/Customs/postprocesses/downsample", ["screenSize", "highlightThreshold"], null, 0.25, camera);
```

You have to specify:

- A name
- The URL of the shader code\*
- A list of your uniforms parameters
- A list of additional samplers
- The ratio
- The parent camera (deprecated)
- The sampling mode
- The engine
- Can be reusable

(\*Please see the link at the bottom of this document to learn more ways to store shader code.)

You can set things up before the postprocess is applied by specifying an `onApply` function:

```javascript
postProcess.onApply = function (effect) {
  effect.setFloat2("screenSize", postProcess1.width, postProcess1.height);
  effect.setFloat("highlightThreshold", 0.9);
};
```

You can find another example here: <Playground id="#DAC1WM" title="Custom Post Process Example" description="Simple example of a custom post process." isMain={true} category="Post-processing"/>

To use the output of a previous post process, you can use `setTextureFromPostProcess`.
Note: This will set sceneSampler to the output of the post process before postProcess0 NOT the output of postProcess0.

```javascript
effect.setTextureFromPostProcess("sceneSampler", postProcess0);
```

## Chaining postprocesses

You can chain postprocesses on a specific camera. They are processed in creation order. For instance, here is the code used to simulate a bloom effect:

```javascript
var blurWidth = 1.0;

var postProcess0 = new BABYLON.PassPostProcess("Scene copy", 1.0, camera);
var postProcess1 = new BABYLON.PostProcess("Down sample", "./Scenes/Customs/postprocesses/downsample", ["screenSize", "highlightThreshold"], null, 0.25, camera, BABYLON.Texture.BILINEAR_SAMPLINGMODE);
postProcess1.onApply = function (effect) {
  effect.setFloat2("screenSize", postProcess1.width, postProcess1.height);
  effect.setFloat("highlightThreshold", 0.9);
};
var postProcess2 = new BABYLON.BlurPostProcess("Horizontal blur", new BABYLON.Vector2(1.0, 0), blurWidth, 0.25, camera);
var postProcess3 = new BABYLON.BlurPostProcess("Vertical blur", new BABYLON.Vector2(0, 1.0), blurWidth, 0.25, camera);
var postProcess4 = new BABYLON.PostProcess("Final compose", "./Scenes/Customs/postprocesses/compose", ["sceneIntensity", "glowIntensity", "highlightIntensity"], ["sceneSampler"], 1, camera);
postProcess4.onApply = function (effect) {
  effect.setTextureFromPostProcess("sceneSampler", postProcess0);
  effect.setFloat("sceneIntensity", 0.5);
  effect.setFloat("glowIntensity", 0.4);
  effect.setFloat("highlightIntensity", 1.0);
};
```

You might want to [read more about shaders](https://web.archive.org/web/20190904224946/https://www.eternalcoding.com/what-do-you-mean-by-shaders-learn-how-to-create-shaders-with-babylon-js/) and try our [CYOS shader editor](https://cyos.babylonjs.com/).



# Post Processes

Post processes allow you to create 2D effects on top of your scene.
A post process is linked to a camera and can be part of a chain of post processes, where each post process uses the result of the previous one as input for its own processing.

# Using Havok and the Havok Plugin

## Havok and Babylon.js

The Havok integration in Babylon.js consists of two different modules that work together.
The first is the Havok engine itself, which is a WebAssembly module that is responsible for the actual physics calculations.
The second is the Babylon Havok plugin, which is responsible for the integration of the Havok physics engine into Babylon.js.

## The Havok physics engine

_To read about the Babylon plugin directly, [skip to the next section](#the-babylon-havok-plugin)._

Havok is now available for the web, using a WebAssembly version of the engine. It is available free to use under the MIT license.
The engine is available both as [the npm package](https://www.npmjs.com/package/@babylonjs/havok) `@babylonjs/havok` and on our CDN under the URLs `https://cdn.babylonjs.com/havok/HavokPhysics_umd.js` or `https://cdn.babylonjs.com/havok/HavokPhysics_es.js` when using the `module` script.
Please note that it requires WebAssembly SIMD, which is not supported on iOS < 16.4.

<Alert severity="warning" title="Warning" description="The CDN should not be used in production environments. The purpose of our CDN is to serve Babylon packages to users learning how to use the platform or running small experiments. Once you've built an application and are ready to share it with the world at large, you should serve all packages from your own CDN."/>

The NPM package contains the same two flavors as the CDN: an ES modules version and a UMD version for CommonJS and AMD projects. Your bundler will select the right file for you.

The engine requires initialization before it can be used in Babylon.js. This is done by calling the function returned by the package or the online version. This function initializes the wasm file and returns an object that can be used to initialize Babylon's Havok plugin.

### Using the npm package

To use the npm package, install the Havok package in your project:

```bash
npm install @babylonjs/havok
```

Then, import the package and call the function returned by the package:

```javascript
import HavokPhysics from "@babylonjs/havok";

async function getInitializedHavok() {
  return await HavokPhysics();
}
```

A different way to use the imported package would be to call the function returned by the package directly:

```javascript
import HavokPhysics from "@babylonjs/havok";
let initializedHavok;

HavokPhysics().then((havok) => {
  initializedHavok = havok;
});
```

### Using the CDN

The main difference between the CDN and the npm package is the way the HavokPhysics object becomes available in your browser.
Whereas using npm you need to import/require the package, using the CDN you get the object directly from the global scope.

<Alert severity="warning" title="Warning" description="The CDN should not be used in production environments. The purpose of our CDN is to serve Babylon packages to users learning how to use the platform or running small experiments. Once you've built an application and are ready to share it with the world at large, you should serve all packages from your own CDN."/>

```html
<script src="https://cdn.babylonjs.com/havok/HavokPhysics_umd.js"></script>
<script>
  // before initializing your babylon scene:
  let havokInstance;
  HavokPhysics().then((havok) => {
    // Havok is now available
    havokInstance = havok;
  });

  // later in code you can use havokInstance to initialize the plugin
</script>
```

A way to use the CDN without polluting the global scope is to use the `module` script:

```html
<script type="module">
  import HavokPhysics from "https://cdn.babylonjs.com/havok/HavokPhysics_es.js";
  let havokInstance;
  HavokPhysics().then((havok) => {
    // Havok is now available
    havokInstance = havok;
  });

  // later in code you can use havokInstance to initialize the plugin
</script>
```

## The Babylon Havok plugin

When the Havok instance is created and available, you can use it to initialize the Babylon Havok plugin.

An example of initializing the plugin:

```javascript
// Assuming HavokPhysics is available, whether by importing or by using the CDN

async function createScene() {
  // generate your scene, do your magic!

  // initialize the plugin using the HavokPlugin constructor
  const havokInstance = await HavokPhysics();
  const havokPlugin = new BABYLON.HavokPlugin(true, havokInstance);
}
```

You are now ready to use the Havok plugin in your Babylon.js scene.

### The HK global variable

To simplify the initialization process of the plugin, the Havok plugin will look in the `HK` global variable for an initialized Havok instance. If it is available, it will use it to initialize the plugin. If it is not available, it will use the Havok instance passed to the constructor.

This code will work (assuming the UMD version was loaded in the browser):

```javascript
globalThis.HK = await HavokPhysics();
```

This is the way we are using Havok in our playgrounds.
However, **the recommended way** for a project you fully control is not to pollute the global namespace and to **pass the Havok instance to the plugin**.

### Example using npm

A working example using NPM and ES modules can be found in the [Babylon.js template repository](https://github.com/RaananW/babylonjs-webpack-es6/blob/master/src/scenes/physicsWithHavok.ts).
Note that engine initialization happens in a different file (https://github.com/RaananW/babylonjs-webpack-es6/blob/master/src/externals/havok.ts), but it is nonetheless the same architecture.

### Full in-browser example using the UMD version

```html
<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

    <title>Babylon.js using Havok</title>

    
    <script src="https://cdn.babylonjs.com/havok/HavokPhysics_umd.js"></script>
    <script src="https://cdn.babylonjs.com/babylon.js"></script>
    <script src="https://cdn.babylonjs.com/gui/babylon.gui.min.js"></script>

    <style>
      html,
      body {
        overflow: hidden;
        width: 100%;
        height: 100%;
        margin: 0;
        padding: 0;
      }

      #renderCanvas {
        width: 100%;
        height: 100%;
        touch-action: none;
      }

      #canvasZone {
        width: 100%;
        height: 100%;
      }
    </style>
  </head>
  <body>
    <div id="canvasZone"><canvas id="renderCanvas"></canvas></div>
    <script>
      const canvas = document.getElementById("renderCanvas");
      const engine = new BABYLON.Engine(canvas, true, { preserveDrawingBuffer: true, stencil: true, disableWebGL2Support: false });
      const createScene = async function () {
        // This creates a basic Babylon Scene object (non-mesh)
        const scene = new BABYLON.Scene(engine);

        // This creates and positions a free camera (non-mesh)
        const camera = new BABYLON.FreeCamera("camera1", new BABYLON.Vector3(0, 5, -10), scene);

        // This targets the camera to scene origin
        camera.setTarget(BABYLON.Vector3.Zero());

        // This attaches the camera to the canvas
        camera.attachControl(canvas, true);

        // This creates a light, aiming 0,1,0 - to the sky (non-mesh)
        const light = new BABYLON.HemisphericLight("light", new BABYLON.Vector3(0, 1, 0), scene);

        // Default intensity is 1. Let's dim the light a small amount
        light.intensity = 0.7;

        // Our built-in 'sphere' shape.
        const sphere = BABYLON.MeshBuilder.CreateSphere("sphere", { diameter: 2, segments: 32 }, scene);

        // Move the sphere upward at 4 units
        sphere.position.y = 4;

        // Our built-in 'ground' shape.
        const ground = BABYLON.MeshBuilder.CreateGround("ground", { width: 10, height: 10 }, scene);

        // initialize plugin
        const havokInstance = await HavokPhysics();
        // pass the engine to the plugin
        const hk = new BABYLON.HavokPlugin(true, havokInstance);
        // enable physics in the scene with a gravity
        scene.enablePhysics(new BABYLON.Vector3(0, -9.8, 0), hk);

        // Create a sphere shape and the associated body. Size will be determined automatically.
        const sphereAggregate = new BABYLON.PhysicsAggregate(sphere, BABYLON.PhysicsShapeType.SPHERE, { mass: 1, restitution: 0.75 }, scene);

        // Create a static box shape.
        const groundAggregate = new BABYLON.PhysicsAggregate(ground, BABYLON.PhysicsShapeType.BOX, { mass: 0 }, scene);

        return scene;
      };

      createScene().then((scene) => {
        engine.runRenderLoop(function () {
          if (scene) {
            scene.render();
          }
        });
      });
      // Resize
      window.addEventListener("resize", function () {
        engine.resize();
      });
    </script>
  </body>
</html>
```

Post Processes

Coming next

How To Use A Post Process Render Pipeline

Learn how to use a post process render pipeline in Babylon.js.

How To Use Post Processes

Learn how to use post process effects in Babylon.js.

Using the SSAO Rendering Pipeline

Learn how to use the SSAO Rendering Pipeline in Babylon.js.

Using the Standard Rendering Pipeline (deprecated)

Learn about the standard rendering pipeline in Babylon.js.

Using the Default Rendering Pipeline

Learn about the default rendering pipeline in Babylon.js.

Depth of Field and Other Lens Effects

Learn how to use depth of field and other lens effects in Babylon.js.

Image-based Lighting Shadows Rendering Pipeline

Learn about the IBL shadows rendering pipeline in Babylon.js.

Motion Blur Post Process

Learn how to use the motion blur post process in Babylon.js.

Mesh Blending

Learn how to soften visible contacts between meshes with the Babylon.js screen-space mesh blending post-process.

Screen Space Reflections (SSR) Rendering Pipeline

Learn about the screen space reflection rendering pipeline in Babylon.js.

Screen Space Reflections (SSR) Post Process

Learn about the screen space reflection post process in Babylon.js.

Temporal Anti-Aliasing (TAA) Rendering Pipeline

Learn about the temporal anti-aliasing rendering pipeline in Babylon.js.

FidelityFX Super Resolution (FSR 1) Rendering Pipeline

Learn about the AMD FidelityFX Super Resolution 1 rendering pipeline in Babylon.js.

Render Target Texture With Multiple Passes

Learn about the render target texture and running multiple passes in Babylon.js.