
Here are some miscellaneous tips for optimizing WebGPU for speed.

## Avoid creating too many resources each frame
If you call `engine.enableEffect()`, make sure to pass a `DrawWrapper` to it, not an `Effect`. Otherwise, some WebGPU resources will be created each frame.

To check that you are not creating unnecessary resources, once your application is running and has stabilized, meaning you did not create new objects in the last frame, check `engine.countersLastFrame` and make sure `numEnableEffects` is 0. `numEnableEffects` is greater than 0 when you call `engine.enableEffect()` with an `Effect` instead of a `DrawWrapper`. Only `numEnableDrawWrapper` should be nonzero.

## Optimize post processes
If you set the `textureSampler` property manually in an `onApply` observer, set `externalTextureSamplerBinding = true` on the post-process to improve performance.

If possible, do not set the `reusable` parameter of the `PostProcess` constructor to `true`. Otherwise, there will be continuous swapping between the two textures used as the render target of the post-process, which is especially bad in non-compatibility mode because the cached render bundle will be recreated each frame.



WebGPU can run in a **non compatibility mode** (NCM, also called **fast path**) that can provide better performance, depending on your scene.

The `WebGPUEngine.compatibilityMode` property is a switch that is `true` by default. In this mode, the WebGPU engine runs in full **compatibility mode** (CM) with WebGL, meaning all scenes that can be rendered with WebGL can also be rendered by WebGPU without any changes on your side.

Setting this property to `false` switches to **non compatibility mode** (NCM), allowing the engine to use another code path that may improve performance at the cost of some possible reorganization of your code.

## Description
What this mode does is build an object called a **bundle**, which holds the commands needed to draw a mesh, more precisely a submesh, in a given context, and then reuses this bundle each time the mesh must be drawn in that context. Building this bundle has a cost, so the bundle must live long enough to make up for that cost. If the bundle is recreated every frame, using NCM will actually hurt performance.

A bundle must be recreated when a number of things happen: you change the material, you change some global context directly on the engine, you update some vertex data, and so on. You can see how many bundles were recreated and how many were reused during the last frame by looking at the `engine.countersLastFrame` property:
```javascript
> engine.countersLastFrame
> {numEnableEffects: 0, numEnableDrawWrapper: 2, numBundleCreationNonCompatMode: 0, numBundleReuseNonCompatMode: 2}
```
What you are interested in are the two `numBundleXXX` counters:
* `numBundleReuseNonCompatMode` is the number of bundles that have been reused in the last frame
* `numBundleCreationNonCompatMode` is the number of bundles that have been created in the last frame

The lower `numBundleCreationNonCompatMode` is, the better. The best case is when this counter is 0. Of course, depending on what you are doing, it may not be possible to keep this counter at 0 all the time, but you should try to keep it as low as possible.

**Note**: if both counters are 0 it means you are not in NCM, you should do `engine.compatibilityMode = false` to switch to NCM.

See the last section of this page for things to watch for that can lead to bundle creation or recreation, and for ways to modify your code to avoid it.

## Caveats
When in NCM mode, it is theoretically possible that some things may not work as expected, for example that changing a material would not work. In that case, calling `scene.resetDrawCache()` would fix the problem, or `mesh.resetDrawCache()` if the problem affects only a single mesh.

In practice, however, this should happen only very infrequently, as explained in the next section. If it does happen, please report it on the forum so we can analyze the case and see whether it can be made to work automatically without calling `resetDrawCache`.

Also, even if you are able to achieve low, or even zero, bundle recreations each frame, you may not see a performance improvement over **compatibility mode**. It depends on your scene, so you should benchmark to see whether NCM improves things for you.

## Do/Don't in non compatibility mode (NCM)
* If two or more cameras are rendering into the same RTT using the `Camera.outputRenderTarget` property, set `rtt.renderPassId = undefined` so that `camera.renderPassId` is used for each camera instead of `rtt.renderPassId` for both cameras. Otherwise, this leads to bundle recreation.
* If you are using skeletons, make sure a material is not linked to several different skeletons. That means a material should not be used by several meshes unless they all use the same skeleton. In that case, clone the material as many times as necessary. The same applies to morph targets.
* `Material.needDepthPrePass` works in NCM, but it always creates new bundles each frame.
* If you update one of these material properties after switching to NCM, you must reset the draw cache for the changes to take effect by calling either `mesh.resetDrawCache()` or `scene.resetDrawCache()`: `sideOrientation`, `disableDepthWrite`, `forceDepthWrite`, `depthFunction`, `disableColorWrite`, `zOffset`, `stencil`
* If you update the `samples` property of a post-process or RTT, you must call `scene.resetDrawCache()` afterward. Otherwise, rendering will use the new value together with the old bundles created with the old `samples` value, and you will get an error like `Attachment state of renderBundles[0] ([RenderBundle]) is not compatible with attachment state of [RenderPassEncoder].`.
* Not working in NCM, meaning do not switch to NCM if you want to use them, or your program will not work as expected:
  * Occlusion queries. They do not work because the order of draws and queries must be preserved. That is not possible in NCM because all draws are postponed to the end of the frame when calling `executeBundles()`, whereas queries are executed at the point where they are called.
  * `Material.separateCullingPass = true` does not work because of the way it is currently implemented.

## Case analysis
Below is a list of all the playgrounds from our validation test suite that recreated one or more bundles each frame when we first tested them in **non compatibility mode**. We explain why they were creating bundles and how we fixed them, when that was possible. You can see the fixed code by appending the PG number, given inside the parentheses after the PG name, to the Playground URL (https://playground.babylonjs.com/).

### WebGPU list (webgpu.json)

* **sphere with custom shader to display wireframe using glow layer** (#Y05E2C#6)
    * why: a property of a material is changed two times in a frame, to change the color depending on where the mesh is drawn (the glow layer or the regular rendering)
    * solution: use two materials, one for each case
* **particle system matrix like** (#WL44T7)
    * why: a new particle system is recreated to replace one that has reached its time to live
    * solution: none. New particle systems are recreated regularly as part of the normal operation of the PG, so it is expected that bundles are created regularly too

### Default list (config.json)

* **Nested BBG, Chibi Rex, Yeti, Bones, GLTF Serializer Morph Target Animation Group** (#ZG0C8B#5, #QATUCH#18, #QATUCH#19, #7EC27T#3, #T087A8#29)
    * why: use same material for different meshes that are using different skeletons
    * solution: use as many materials as the number of skeletons
* **Solid particle system** (#WCDZS#92)
    * why: SPS mesh is pickable. When the mesh is pickable, the vertex attributes (position, normal) are updated by calling `mesh.updateVerticesData` which dirtifies the material and ends-up recreating the bundle used by the fast path code
    * solution: sets the mesh as not pickable
* **Ribbon morphing** (#ACKC2#1)
    * why: updating the position attribute each frame
    * solution: none at the time, the `CreateTube` (and all functions of `MeshBuilder`) are using `getVerticesData` / `updateVerticesData` to update an existing instance, the latter method triggering a `markAsAttributeDirty` call on the material. We would need to update the GPU buffer directly without using `updateVerticesData`, but by doing so we would lose the baking CPU array which is necessary for the mesh builder methods to work (the `Buffer.updateDirectly` method is clearing the `_data` property but `getVerticesData` works only if this property is not `null`)
* **Custom render target** (#TQCEBF#3)
    * why: changing the material used by a `RenderTargetTexture` in `onBeforeRender` and resetting it in `onAfterRender`
    * solution: use `RenderTargetTexture.setMaterialForRendering` instead of `onBeforeRender` / `onAfterRender`
* **Advanced shadows, Advanced shadows (right handed), Reverse depth buffer and shadows** (#SLV8LW#3, #B48X7G#64, #WL4Q8J#20)
    * why: the same material is used for the eight floors. For **Reverse depth buffer and shadows**, the boxes, sphere, and knot reuse the same material. Each floor and box is lit by a specific light with its own shader generator. When a floor is drawn, the shadow sampler corresponding to that shadow generator is bound to the shader, and because all floors use the same material, setting a new shadow sampler resets the cache
    * solution: use a different (cloned) material for each floor
* **Motion Blur, Instances + GBR + motion blur** (#E5YGEL#20, #YB006J#403)
    * why: the number of spheres (of trees in **Instances + GBR + motion blur**) visible each frame is never the same because they are moving. The `LeftOver` uniform buffer that stores the motion blur parameters for each sphere has a number of GPU buffers internally, one per sphere. When the fast path bundle is created, one buffer is associated to the bundle (buffer #0 for first sphere displayed, #1 for second sphere and so on). However, the next frame, the GPU buffer that will be used for a given sphere may be different because the buffers are reused starting from the first one: the first buffer is used for the first sphere displayed, second buffer is used for the second sphere displayed, etc. So, if the spheres are not displayed in the same order, the bundle(s) will be recreated
    * solution: none at the time. For the PG, we simply set `alwaysSelectAsActiveMesh=true` so that the number of spheres handled by the system does not vary
* **Thin instances + motion blur + manual** (#HJGC2G#132)
    * why: `thinInstanceSetBuffer` was called each frame, which is (re)creating a vertex buffer, which in turn is flagging the material as "attribute dirty"
    * solution: use `thinInstanceBufferUpdated` instead
* **Multi cameras and output render target** (#BCYE7J#31)
    * why: `cameraRTT1` and `cameraRTT2` are rendering into the same RTT (using their `outputRenderTarget` property), but when rendering in an RTT the render pass id which is used is `RTT.renderPassId`, meaning the meshes are rendered two times (because two cameras) with the same `renderPassId`, leading to bundle recreations (because the scene ubo is not the same in both cases as it stores the camera view/projection)
    * solution: remove the `RTT.renderPassID` property (`RTT.renderPassID = undefined`) => in that case, the `camera.renderPassId` value will be used instead
* **Order independent transparency** (#1PLV5Z#104)
    * why: not using `useRenderPasses = true` on the depth peeling renderer
    * solution: set `scene.depthPeelingRenderer.useRenderPasses = true;`



**Snapshot rendering** is a new rendering mode available starting with Babylon.js v5.0. Only WebGPU supports it: activating this mode in WebGL has no effect.

## Description
The snapshot rendering (SR) feature improves performance in some specific scenarios described below.

It works by recording the draw calls during one frame and by replaying this recording for all subsequent frames. So, the scene should be mostly static for this mode to work as expected. Note that this mode can be enabled or disabled whenever you want. So, if at some point something must change in the scene that is not supported by SR, you can disable the mode, apply the changes and re-enable SR afterwards.

Note that the performance improvement is on the JavaScript side only: GPU performance will be more or less the same with or without SR enabled, though you could still see some small GPU performance improvements depending on the browser.

The performance improvements can be quite large, especially when using fast SR mode (see below for explanations of the SR modes). Here are some figures collected with the first PG listed in the **Examples** section:

| WebGL 2 version | SR - Standard mode | SR - Fast mode | 
|-------------|---------------|-----------|
| ![WebGL2 ](/img/resources/snapshot_rendering/webl2_comparison.webp) | ![Standard mode](/img/resources/snapshot_rendering/sr_standard.webp!241x247) | ![Fast mode](/img/resources/snapshot_rendering/sr_fast.webp!245x243) |

## Enabling snapshot rendering mode
The snapshot rendering mode is enabled by setting:
```javascript
engine.snapshotRendering = true;
```
When doing this, the next frame will be recorded (and of course also displayed as usual!) and the recorded snapshot will be replayed in all subsequent frames until you either disable the mode or use `engine.snapshotRenderingReset()`. If calling the latter, a new snapshot will be created the next frame that will replace the current snapshot.

Calling `engine.snapshotRenderingReset()` is how you apply changes that are not supported by the current SR mode (see the available modes in the next section): apply your changes and call this function. It destroys the current snapshot and instructs the system to create a new one by recording the draw calls of the next frame, which will contain your changes. In effect, it is the same as doing `engine.snapshotRendering = false; engine.snapshotRendering = true;`. The first assignment stops and destroys the current snapshot, and the second asks the system to record the draw calls when rendering the next frame. Of course, for this to work, your changes should be in effect by the next frame. If, for example, you import a new mesh, it will probably take more than a frame to be added to the scene. So, you should call `engine.snapshotRenderingReset()` once you know the next frame will render the scene with the new state.

## Standard and Fast modes
There are two different modes available when SR is enabled:
* Standard mode (`Constants.SNAPSHOTRENDERING_STANDARD`). In this mode, the uniform buffers are still updated, so some dynamic behavior is still supported: you can update some parameters of a material, for example, and it will work.
* Fast mode (`Constants.SNAPSHOTRENDERING_FAST`). In this mode, only the scene uniform buffer is updated automatically by the system (meaning moving the camera works as expected). You can still update the uniform buffers of meshes "by hand", so moving/rotating meshes are also supported (see examples below).

Whatever the mode, as the draw calls of a given frame are recorded and replayed for all subsequent frames, adding or removing meshes won't work. You will need to disable the SR mode if you want to add/remove meshes and re-enable it afterwards.

## Caveats

### Always set `alwaysSelectAsActiveMesh` to `true`
Given how SR works, you will probably always want to set `alwaysSelectAsActiveMesh = true` for all your meshes because if this property is `false` (the default value) and the mesh is not displayed when recording the snapshot, no draw calls will be recorded for it. This means that if you later move the camera in a way that should make the mesh visible, it still will not be visible.

### Statistics in the Inspector
In fast SR mode, most of the regular JavaScript code is skipped, so the statistics displayed by the Inspector in the **COUNT** section will not be accurate: all the **Active XXX** counters, as well as **Total vertices**, will stay at 0.

### When to use
It's hard to list everything that will work/won't work depending on the mode, so the easiest way to use this new feature is to enable it and see if everything works as expected once enabled (try first fast mode, then standard mode). As explained above, if you need to update something at some point in time and the current SR mode can't handle it, you can always disable SR, apply the changes and re-enable SR.

eCommerce sites may greatly benefit from this feature because the scene is normally quite small, with everything visible on screen. Also, there generally is not much dynamic behavior, and when something needs to be updated it is usually a "one-shot" update, so either calling `snapshotRenderingReset` or temporarily disabling the feature should work.

### Enable the snapshot rendering mode at the right time
Make sure everything in your scene is ready to be rendered on the next frame after you set `engine.snapshotRendering = true`! Once you set `snapshotRendering` to `true`, the next frame is recorded and replayed afterwards. If some textures, for example, are not ready at that time, the mesh will not be rendered in the recorded frame and therefore will never be visible. You should probably always set `engine.snapshotRendering = true` inside a `scene.executeWhenReady(...)` callback.

## Examples
Here's a PG that demonstrates using the snapshot rendering feature: <Playground image="/img/playgroundsAndNMEs/pg-SYQW69-1092.webp" id="#SYQW69#1354" engine="webgpu" title="Snapshot rendering" description="Demonstrate how to use the snapshot rendering modes"/>

You can choose to disable or enable standard / fast SR mode. Depending on the mode, you will see the JavaScript time it takes to render a frame (**Frame total**) and the virtual fps (the fps you would have if there were no GPU rendering / the fps were not capped by the browser - it is simply `1000/Frame total`).

In fast mode, animating light / updating the bias would not work for the reasons explained above. When you update:
* the **bias**, the PG calls `engine.snapshotRenderingReset()` so that the bias is taken into account for the next frame and the snapshot is recreated at that time too
* the **Animate light** checkbox, the PG switches to standard SR mode until you uncheck the box. Moving the light does work in standard SR mode: if it did not, we would have switched to SR disabled mode instead.

Note also that in fast SR mode you must handle updates to the sky position yourself because the uniform buffers are not updated by the system, except for the scene buffer. See [The SnapshotRenderingHelper class](#the-snapshotrenderinghelper-class) section for more details.

Here's another PG using the glow layer: <Playground id="#LRFB2D#182" engine="webgpu" title="Snapshot rendering with glow layer" description="Demonstrate how to use the snapshot rendering standard mode with glow layer"/>

This PG is using the standard SR mode because the fast mode does not work (try to set the fast mode and see for yourself - however, see next section for a way to make it work). Also, when a resize kicks in, we need to disable the SR mode and re-enable it only when the glow layer had time to recreate its internal texture with the new size. That's why we use a `setTimeout(..., 1)` to re-enable the SR mode.

## The SnapshotRenderingHelper class
Fast SR mode is the most interesting mode because your scene can be handled several orders of magnitude faster than with SR disabled, or even than when using standard SR mode.

To simplify the use of fast SR mode, we have created a [SnapshotRenderingHelper](https://doc.babylonjs.com/typedoc/classes/babylon.snapshotrenderinghelper) class to help you work with this mode. This class is available as of Babylon.js version 7.32.0.

To use it, create an instance of the class and call `enableSnapshotRendering()` after you have loaded or created your scene:
```typescript
const sr = new BABYLON.SnapshotRenderingHelper(scene);
...
// make sure your scene is loaded/created
...
sr.enableSnapshotRendering();
```

Call `updateMesh()` to update a mesh when its position/rotation/scaling property has changed.

If you create a layer (glow, highlight), call `updateMeshesForEffectLayer()` for that layer to make it compatible with fast SR mode.

If you create or add new meshes later on, call `fixMeshes()` to make sure they are compatible with fast SR mode:

* their `ignoreCameraMaxZ` property will be set to `false`, as this feature is not compatible with fast SR mode
* the maximum number of influencers of morph target managers will be set to a fixed value (that you can define through the `options` parameter of the `SnapshotRenderingHelper` constructor). This is needed to make sure morphs work in fast SR mode

<br/>Thanks to this class, we can handle a number of dynamic cases very simply:
* Updating position/rotation/scaling/visibility properties of meshes: <Playground id="#7YW416#11" engine="webgpu" title="Update mesh matrix in fast SR mode with snapshot helper class" description="Demonstrates how to update the position/rotation/scaling/visibility properties of a mesh in fast snapshot rendering mode with snapshot helper class" image="/img/playgroundsAndNMEs/pg-7YW416-3.webp"/>
* Using the glow layer: <Playground id="#LRFB2D#852" engine="webgpu" title="Use glow layer in fast SR mode with snapshot helper class" description="Demonstrates how to make the glow layer work in fast snapshot rendering mode with snapshot helper class" image="/img/playgroundsAndNMEs/pg-LRFB2D-218.webp"/>
* Animating bones: <Playground id="#WGZLGJ#10670" engine="webgpu" title="Use bones in fast SR mode with snapshot helper class" description="Demonstrates how to make bones work in fast snapshot rendering mode with snapshot helper class" image="/img/playgroundsAndNMEs/pg-WGZLGJ-4072.webp"/>
* Using a default skybox: <Playground id="#WGZLGJ#10671" engine="webgpu" title="Use default skybox in fast SR mode with snapshot helper class" description="Demonstrates how to make default skyboxes work in fast snapshot rendering mode with snapshot helper class" image="/img/playgroundsAndNMEs/pg-WGZLGJ-10606.webp"/>





This section shows how to use specific features to optimize your scenes when using the WebGPU engine.


Currently, most of the main shaders used by **Babylon.js** are written in [WGSL](https://gpuweb.github.io/gpuweb/wgsl/), the only shader language that WebGPU supports. That being said, we actively maintain compatibility with [GLSL](https://www.khronos.org/opengl/wiki/OpenGL_Shading_Language).

If you decide to write a shader with [GLSL](https://www.khronos.org/opengl/wiki/OpenGL_Shading_Language), **Babylon.js** will detect it and use internal tools to compile it to [WGSL](https://gpuweb.github.io/gpuweb/wgsl/). This takes some time and downloads a WASM library to do the conversion.

It is recommended to write your shaders directly in [WGSL](https://gpuweb.github.io/gpuweb/wgsl/) for faster startup time and smaller download sizes.

For some specific materials like `CustomMaterial` or `PBRCustomMaterial`, to protect backward compatibility, you will need to inject your custom shader code in [GLSL](https://www.khronos.org/opengl/wiki/OpenGL_Shading_Language).

## Using ShaderMaterial to write WGSL code
You can use the `ShaderMaterial` class to write WGSL code in much the same way you use it to write [GLSL](https://www.khronos.org/opengl/wiki/OpenGL_Shading_Language), but with a few small differences.

Note: if you use the "color" attribute in your shader code, don't add it to the **attributes** property passed to the `ShaderMaterial` constructor! This attribute will be automatically added if a vertex buffer named "color" is attached to the mesh. If you add "color" to the **attributes** array, you will get an error like "Attribute shader location (1) is used more than once".

### Setting the right shader language
You must set the `shaderLanguage` property to `BABYLON.ShaderLanguage.WGSL` in the `options` parameter you pass to the constructor.
For example:
```javascript
const mat = new BABYLON.ShaderMaterial("shader", scene, {
        vertex: "myShader",
        fragment: "myShader",
    },
    {
        attributes: ["position", "uv", "normal"],
        uniformBuffers: ["Scene", "Mesh"],
        shaderLanguage: BABYLON.ShaderLanguage.WGSL,
    }
);
```

### Using the WGSL shader store
If using the shader store, you must put your WGSL code in `BABYLON.ShaderStore.ShadersStoreWGSL` instead of `BABYLON.ShaderStore.ShadersStore`.

For example:
```javascript
BABYLON.ShaderStore.ShadersStoreWGSL["myShaderVertexShader"]=`   
    #include<sceneUboDeclaration>
    #include<meshUboDeclaration>
    ...
`;

BABYLON.ShaderStore.ShadersStoreWGSL["myShaderFragmentShader"]=`
    varying vPositionW : vec3<f32>;
    varying vUV : vec2<f32>;
    ...
`;
```

### Declaration of the entry points
You must also declare the entry point for the vertex and fragment shader in a special way.

Vertex:
```wgsl
@vertex
fn main(input : VertexInputs) -> FragmentInputs {
    ...
}

```
Fragment:
```wgsl
@fragment
fn main(input : FragmentInputs) -> FragmentOutputs {
    ...
}
```

<Alert severity="warning">Even though the entry point parameter is named `input`, do **not** access shader variables through `input.XXX`. Always use `vertexInputs.XXX` (vertex shader) or `fragmentInputs.XXX` (fragment shader) instead. The engine may apply transformations to certain input variables — for example, attributes stored as integers (such as `position` when using an integer vertex buffer) are automatically converted to their float equivalent, so accessing them via `input.XXX` would give the raw unconverted value and produce incorrect results.</Alert>

### Using pre-defined uniforms
To use the pre-defined uniforms of the scene (`view`, `viewProjection`, `projection`, `vEyePosition`) and mesh (`world`, `visibility`), you must include the appropriate file(s) in the shader code:
```wgsl
#include<sceneUboDeclaration>
#include<meshUboDeclaration>
```
and add the uniform buffer name(s) to the `uniformBuffers` option of the `ShaderMaterial` class constructor:
```javascript
const mat = new BABYLON.ShaderMaterial("shader", scene, {
        vertex: "myShader",
        fragment: "myShader",
    },
    {
        attributes: ["position", "uv", "normal"],
        uniformBuffers: ["Scene", "Mesh"],
        shaderLanguage: BABYLON.ShaderLanguage.WGSL,
    }
);
```

In the WGSL code, you access a uniform by prefixing its name by `scene.` or `mesh.` for the scene or mesh uniforms, respectively:
```wgsl
@vertex
fn main(input : VertexInputs) -> FragmentInputs {
    vertexOutputs.position = scene.viewProjection * mesh.world * vec4<f32>(vertexInputs.position, 1.0);
}    
```

## Special syntax used in WGSL code
Unlike compute shaders that use ordinary WGSL code, the shader code you write for `ShaderMaterial` must use special syntax to work with the existing workflow. To make it easier for developers, the declaration of variables is the same as that used in [GLSL](https://www.khronos.org/opengl/wiki/OpenGL_Shading_Language):
* declaring a varying variable:
```wgsl
varying varName : varType;
```
* declaring an attribute variable:
```wgsl
attribute varName : varType;
```
* declaring a uniform variable:
```wgsl
uniform varName : varType;
```

Contrary to [GLSL](https://www.khronos.org/opengl/wiki/OpenGL_Shading_Language), the inputs and outputs of the vertex/fragment shader are not declared internally as separate global variables, but are defined in structures managed by the engine for you. However, this means that you need a special syntax to access these variables. Here is the mapping between the [GLSL](https://www.khronos.org/opengl/wiki/OpenGL_Shading_Language) syntax and the WGSL syntax:
* In the vertex shader:
  * an attribute must be referenced by `vertexInputs.attributeName`
  * `gl_VertexID` => `vertexInputs.vertexIndex`
  * `gl_InstanceID` => `vertexInputs.instanceIndex`
  * a varying must be referenced by `vertexOutputs.varName`
  * `gl_Position` => `vertexOutputs.position`
* In the fragment shader:
  * a varying must be referenced by `fragmentInputs.varName`
  * `gl_FragCoord` => `fragmentInputs.position`
  * `gl_FrontFacing` => `fragmentInputs.frontFacing`
  * `gl_FragColor` => `fragmentOutputs.color`
  * `gl_FragDepth` => `fragmentOutputs.fragDepth`

Notes:
* When using the `uniform varName : varType` syntax, you access the variable through `uniforms.varName`, not simply `varName`. Variables declared this way can be set from the JavaScript code by using the regular methods of the `ShaderMaterial` class (`setFloat`, `setInt`, etc.), as with [GLSL](https://www.khronos.org/opengl/wiki/OpenGL_Shading_Language)
* `varType` must use WGSL syntax, not [GLSL](https://www.khronos.org/opengl/wiki/OpenGL_Shading_Language)! For example: `varying vUV : vec2<f32>;`
* You must **NOT** add the `@group(X) @binding(Y)` decoration! The system will add it automatically

## Using new objects available in WGSL
You can use the standard WGSL syntax to declare:
* custom uniform buffers:
```wgsl
struct MyUBO {
    scale: f32,
};

var<uniform> myUBO: MyUBO;
```
* storage textures:
```wgsl
var storageTexture : texture_storage_2d<rgba8unorm,write>;
```
* storage buffers:
```wgsl
struct Buffer {
    items: array<f32>,
};
var<storage,read_write> storageBuffer : Buffer;
```
* external textures:
```wgsl
var videoTexture : texture_external;
```

Again, you must **NOT** add the `@group(X) @binding(Y)` decoration! The system will add them automatically.

On the JavaScript side, you have the corresponding methods to set a value for these variables:
* uniform buffer: `setUniformBuffer(name, buffer)`
* storage texture: same method as for regular textures (`setTexture(name, texture)`)
* storage buffer: `setStorageBuffer(name, buffer)`
* external texture: `setExternalTexture(name, buffer)`

## Important difference from GLSL
The [normalized device coordinates](https://gpuweb.github.io/gpuweb/#coordinate-systems) (NDC) in WebGPU are slightly different from those in WebGL. In GLSL, NDC for the z-axis lies in the -1.0 ≤ z ≤ 1.0 range. In WGSL, NDC for the z-axis lies in the 0.0 ≤ z ≤ 1.0 range. If you are using NDC in your shader, please ensure you make the necessary adjustments for the z-axis. There are no differences for the xy axes.

## Examples
This playground is a basic example of using WGSL in a `ShaderMaterial`: <Playground id="#6GFJNR#345" image="/img/playgroundsAndNMEs/pg-6GFJNR-164.webp" engine="webgpu" title="Basic example of WGSL with ShaderMaterial" description="Demonstrate how to write WGSL code with the ShaderMaterial class"/>

As when using [GLSL](https://www.khronos.org/opengl/wiki/OpenGL_Shading_Language), `ShaderMaterial` supports morphs, bones and instancing in WGSL. You will need to add the appropriate includes in your code to support these features. See how it is done in this playground (this example also demonstrates how to use a storage texture and a storage buffer): <Playground id="#8RU8Q3#155" image="/img/playgroundsAndNMEs/pg-8RU8Q3-126.webp" engine="webgpu" title="Advanced usage of the ShaderMaterial class" description="Demonstrate how to write WGSL code with the ShaderMaterial class to support bones, morphs and instances"/>

You can also use the baked vertex animation feature introduced in 5.0, as well as clip planes. See: <Playground id="#8RU8Q3#156" image="/img/playgroundsAndNMEs/pg-8RU8Q3-106.webp" engine="webgpu" title="Using BVA and clip planes in WGSL" description="Demonstrate how to write WGSL code with the ShaderMaterial class to support baked vertex animations and clip planes"/>

WebGPU uses a special texture object for fast video playback, called an "external texture". Our [VideoTexture](/typedoc/classes/babylon.videotexture) class takes advantage of this, but if you want to do it yourself, this playground shows how to use the `ShaderMaterial` class to implement video playback with `texture_external`: <Playground id="#6GFJNR#179" image="/img/playgroundsAndNMEs/pg-6GFJNR-163.webp" engine="webgpu" title="Video playing with the ShaderMaterial class" description="Demonstrate how to play videos using external texture in WGSL"/>


WebGPU Optimizations

Coming next

WebGPU Snapshot Rendering

Learn how to use snapshot rendering for faster scene display

WebGPU Non Compatibility Mode

Learn how to use the non compatibility mode for faster scene display

WebGPU Miscellaneous Optimizations

Learn how to optimize WebGPU for speed