
## Using a Files-Based Custom Procedural Texture

To use a files-based custom procedural texture, you need to create a folder containing at least 2 files:

- config.json
- custom.fragment.fx

The config file is a JavaScript Simple Object Notation file containing 4 elements. Here is an example:

```javascript
    {
     "animate": false,
     "refreshrate": 0,
     "uniforms": [
      {
          "type": "float",
          "name": "dirtAmplifier",
          "value": "6.0"
      }
  ],
     "sampler2Ds": [
      {
          "sample2Dname": "dirt",
          "textureRelativeUrl": "textures/dirt.jpg"
      },
      {
          "sample2Dname": "grass",
          "textureRelativeUrl": "textures/grass.png"
      }
     ]
    }
```

The **animate** property indicates if a time value should be created and increased each time the fragment shader code is executed.

The **refreshrate** property is set to 0 if you want the texture to render only once. If set to 1, it will render every frame; if set to 2, every two frames; and so on.

**Uniforms** are the values that will be passed from the JavaScript code to the shader code. By setting them this way, you can allow the custom texture user to modify these values at runtime to customize the texture.

Uniforms can be of type:

- **float** (parameters : value)
- **Vector2** (parameters: x, y)
- **Vector3** (parameters: x, y, z)
- **Color3** (parameters: r, g, b)
- **Color4** (parameters: r, g, b, a)

**Textures2D** are 2D image files that are passed to the shader code as **sampler2D** variables. They can be read by the shader code and be used to create the final pixel color. You only need to provide a name and the relative path inside the folder.

The **custom.fragment.fx** file contains the [GLSL](https://www.khronos.org/opengl/wiki/OpenGL_Shading_Language) code. The purpose of this wiki article is not to teach you how to create a fragment shader or how it works. You simply need to know that the code in your main function will be called once for each pixel to be created in the texture. In this main function, you only know the coordinates of the current pixel in the final texture.

Here is a simple example that sets all pixels to a specific gray.

```javascript
    #ifdef GL_ES
    precision highp float;
    #endif

    void main(void) {
     vec3 color = vec3(0.9, 0.9, 0.9);
     gl_FragColor = vec4(color, 1.0);
    }
```

Gl_FragColor is the variable in which you put the color you want the pixel to have.
Here is a more complex example that uses 2 samplers and mixes their colors equally.

```javascript
    #ifdef GL_ES
    precision highp float;
    #endif

    varying vec2 vPosition;
    varying vec2 vUV;

    uniform sampler2D grass;
    uniform sampler2D dirt;

    void main(void) {
     vec3 color = mix(texture2D(dirt, vUV).xyz, texture2D(grass, vUV).xyz, 0.5);
     gl_FragColor = vec4(color, 1.0);
    }
```

To use this custom texture, you need to make your folder available to your Babylon.js HTML/JavaScript files and use a **CustomProceduralTexture** class instead of a standard one. The only difference is that you specify a new parameter: the relative path to the folder containing the custom texture. Babylon.js will automatically read the config.json and custom.fragment.fx files and load everything for you.

```javascript
const texture = new BABYLON.CustomProceduralTexture("texture", "./pathtotexture", 1024, scene);
```

## Using a ShaderStore for Shader Storage

You can also use the ShaderStore to write a shader inline and use it in a CustomProceduralTexture.
This can be done easily using the **BABYLON.Effect.ShaderStore** array:

```javascript
BABYLON.Effect.ShadersStore["LinesPixelShader"] = "#ifdef GL_ES\n" + "precision highp float;\n" + "#endif\n\n" + "varying vec2 vUV; \n" + "void main(void) {\n" + " gl_FragColor = vec4(vUV.x,vUV.y,-vUV.x, 1.0);\n" + "}\n" + "";
```

Note that your shader name should be suffixed with **PixelShader**, as the Procedural Texture shader is always a pixel shader. Babylon.js will automatically understand that it is a pixel shader.

To use this shader, you just have to create a CustomProceduralTexture and put the name of your shader in the store instead of the path to the files.

```javascript
const customProcText = new BABYLON.CustomProceduralTexture("customtext", "Lines", 1024, scene);
```

## Using a DOM Element for Shader Storage

Finally, you can also use **DOM Elements** to store your shader. You just have to create a script tag in your HTML file like this:

```html
<script type="application/pixelShader" id="LinesPixelShader">
  #ifdef GL_ES
  precision highp float;
  #endif
  varying vec2 vUV;
  void main(void) {
       gl_FragColor = vec4(vUV.x,vUV.y,-vUV.x, 1.0);
  }
</script>
```

To use it, you just have to create a simple object containing one property which is named **fragmentElement** and contains the id identifying the script DOM element.

```javascript
const linesShader = { fragmentElement: "LinesPixelShader" };
const customProcText = new BABYLON.CustomProceduralTexture("customtext", linesShader, 1024, scene);
```

## Using Node Material to generate procedural texture

You can use NodeMaterial to generate the shaders for your procedural texture.
The code to generate it is very simple:

```javascript
BABYLON.NodeMaterial.ParseFromSnippetAsync("#A7A3UB#1", scene).then((nodeMaterial) => {
  const proceduralTexture = nodeMaterial.createProceduralTexture(256);
});
```

Example: <Playground id="#8S19ZC#1" title="Node Material Procedural Texture Example 1" description="Simple example of creating a procedural texture using the node material editor."/>

More here: [Creating Procedural Textures](/features/featuresDeepDive/materials/node_material/nodeMaterial#creating-procedural-textures)

<Youtube id="qqMuuSM7GvI"/>

**Note:** When using ShaderStore or a DOM element shader for custom procedural textures, the config.json file is no longer needed. You can simply use setFloat or setVector3 (and so on), and setTexture on the CustomProceduralTexture will provide values and Sampler2D variables to the shader code.

Feel free to play with this scene here: <Playground id="#24C4KC#51" title="Node Material Procedural Texture Example 2" description="Simple example of creating a procedural texture using the node material editor." image="/img/playgroundsAndNMEs/divingDeeperCreateProceduralTexture2.webp"/>



BABYLON.DepthRenderer is a tool used to generate a depth texture (a texture that contains the depth buffer and can be used to read scene depth values).

Using it is pretty straightforward:

```javascript
const renderer = scene.enableDepthRenderer();
```

Starting from there, the scene will fill the renderer with depth values for you. All active meshes (meshes that are visible from the current camera's point of view) are drawn by the DepthRenderer.

**Warning: Transparent meshes are not drawn because they are not written to the depth buffer**

You can then use the texture associated with the renderer like any other texture by using the `getDepthMap()` function:

```javascript
const mat = new BABYLON.StandardMaterial("mat01", scene);
mat.emissiveTexture = renderer.getDepthMap();
```

If you want to disable the renderer, just call the following code:

```javascript
scene.disableDepthRender();
```

As you can see, you can use the depth map associated with the DepthRenderer with any materials or post-processes.

**Note: By default, the generated texture uses float components thanks to the _WebGL OES_texture_float_ extension. If this extension is not supported, Babylon.js reverts to byte components, which means less precision for depth values.**



## Materials and Vertices

BabylonJS allows you to create many meshes and apply materials to them quite simply and in a range of ways.

Sometimes it may be useful to know more about how this is achieved. Any attempt to answer the question of how colors and textures are applied to a mesh must start by looking at the construction of the mesh.

Below is a simple wireframe cube which has 8 vertices:

![Wireframe](/img/how_to/Materials/box1.webp)

The cube is constructed from 12 facets or triangles, each face having 2 facets.

The color or texture for each facet is determined from those assigned to its vertices.

## Colors at Vertices

Assigning red to each of the vertices of the facet 3, 2, 6 results in a red facet:

![Red Facet](/img/how_to/Materials/redVert.webp)

Assigning red to vertex 3, green to vertex 2 and blue to vertex 6 results in a graduated color image:

![Graduated Facet](/img/how_to/Materials/gradVert.webp)

## Textures at Vertices

Applying an image as a texture to the face 3, 2, 6, 7 means assigning image
coordinates to each of the vertices; (0, 1) to vertex 3, (1, 1) to vertex 2, (1, 0) to vertex 6 and (0, 0) to vertex 7.

These are then used to map the image across the facets.

Of course, with a mesh consisting of many vertices, wrapping an image as a texture around the mesh means assigning each vertex a point on the image using fractional values, as described in [custom meshes](/features/featuresDeepDive/mesh/creation/custom/custom#calculating-uvs).

## Issues with Adjoining Faces

The construction method given above will lead to problems if different colors or textures need to be applied to different faces,
since adjoining faces use the same vertex indices.

For example if face `3, 2, 6, 7` should be red and face `0, 3, 7, 4` should be green, it is not possible to assign both red and green to vertices 3 and 7.

Sharing vertex indices will also cause problems when wrapping an image around a mesh.

For example, if the image above were wrapped around faces `3, 2, 6, 7`, `1, 2, 6, 5`, `0, 1, 5, 4`, and `0, 3, 7, 4`, it would not be possible for vertex 3 to be assigned (1, 0) and (1, 1), nor for vertex 7 to be assigned (0, 0) and (1, 0).

## Solutions for Adjoining Faces

There are two solutions, both of which require additional facets:

1. **Inbetweens**

Replace a shared edge with a face. For example, taking the shared edge 3, 7 and replacing it with a face gives:

![Extra Face](/img/how_to/Materials/box2.webp)

Now vertices 8 and 9 can be assigned green or (1, 1) and (1, 0), and so face `3, 2, 6, 7` can be red or have the start of the image, while face `0, 8, 9, 4` can be green or have the end of the image with no conflict.

Of course, facets `8, 9, 7` and `3, 7, 8` will have graduated fills or distorted images, but by setting vertices 8 and 3 to the same position, and vertices 9 and 7 to the same position, the face `3, 7, 9, 8` disappears. The box then appears to have only six faces, and the adjoining faces have the desired color or image.

Spheres, cylinders, and other self-joining meshes use this method.

2. **Separated Faces**

In this case each face has its own set of indices for its vertices, so each face can have a different material applied:

![Individual Faces](/img/how_to/Materials/box3.webp)

Again correct coincident positioning of vertices leads to a solid looking mesh. Think of the mesh as being made of individual faces that are brought together to form a whole.

Some meshes created with the MeshBuilder method use this approach, allowing the faceColors and faceUV options.



Pretty much every 3D programmer runs into depth buffer issues sooner or later. 
This is especially true when creating outer-space scenes where object distances can be in light years.

In such cases, the linear depth buffer (the default) can generate glitches when distances start reaching large numbers.
In short, the depth values are proportional to the reciprocal of Z. This gives good precision near the camera, but less precision in the distance.

You can read an interesting analysis by Brano Kemen on this blog: http://www.gamasutra.com/blogs/BranoKemen/20090812/85207/Logarithmic_Depth_Buffer.php

To help with this issue, you may want to use a better Z-value distribution: the logarithmic depth buffer, where Z = log(C*z + 1) / log(C*Far + 1) * w

StandardMaterials can enable the logarithmic depth buffer if the browser supports the *GL_EXT_frag_depth* extension.

To enable it, just use this code:
```
material.useLogarithmicDepth = true;
```

If the extension is not supported, Babylon.js will revert to linear depth buffering.



## Compressed Textures for GPU

There are special texture formats optimized for use by graphics processors. They differ from formats whose primary purpose is to hold / transmit image data for use on a CPU. Examples of image formats are .JPG and .PNG. GPU-targeted formats may not be ones you are likely to have heard of. The file extensions for some of them are also not well established.

## Advantages of Compressed Textures

Unlike image file formats, the data in compressed textures is passed to the graphics hardware in its compressed form. A .JPG can be very small on disk, but it gets expanded by the CPU on its way to the GPU. Retaining the compressed form is what gives these formats their advantages. They are:

- They have a smaller RAM footprint. This is most helpful for mobile devices that share memory between CPU and graphics cores. Since textures are multi-dimensional, space requirements can escalate very quickly for scenes with many large textures. Higher-end mobile devices have been able to support up to 4k x 4k textures for some time. These allow for scenes where the camera can approach things, like a highly detailed object without a repeating pattern, without looking blurry when very close.
- More compressed image "blocks" can fit into the processor cache at any one time. Caching / data access patterns are very important for high-performance computing (HPC), and graphics is a form of it.
- Finally, they can lower battery usage, especially during loading. Image formats need to be unpacked. Back when .JPG was designed, battery-powered computers were mostly just luggables. The problems being addressed were network speed and disk space. Who cared then how much CPU was required for reconstituting an image, as long as it was much faster than the network? Further, mipmaps (ever smaller versions for each power of 2 less in dimensions) need to be generated for image types. Mipmaps can be built into compressed texture formats.

## The Catch

There is more than one format for compressed textures. Due to their low-level hardware implementation, support for a given format cannot be added like a software driver update. Support is built right into the circuitry. This is less of a problem when building an iOS-, Android-, or DirectX-targeted application. For a BJS scene that should ideally run on any device / browser, this is a big problem. Having separate HTML pages for different devices is not really an acceptable solution.

## The Solution

Starting with Babylon.js v3.0, the compressed texture formats supported by a browser / device can be [detected](http://renderingpipeline.com/webgl-extension-viewer/). This is done when `const engine = new BABYLON.Engine(...);` is encountered. So now your engine instance knows which compressed formats could be used here. That does not solve that different devices will report different results though.

You can also use this playground: <Playground id="#1SCH7H#5" title="Compressed Textures Example" description="Simple example of multi-platform compressed textures."/> to test which format is supported on your devices.

There is no getting around the fact that you need to provide multiple versions of each texture in different formats (more on that later). The only way to do that is to have different files for each variant, obviously, but the naming structure must be formalized so the image format file described in a .babylon file can be substituted programmatically. The image format file for each texture still needs to be on the server as well, in cases where it needs to be used.

### Khronos Texture Container Format, [.KTX](https://www.khronos.org/opengles/sdk/tools/KTX/) files

Now would be a good time to add the aside that, because this data is not directly used by CPUs and GPUs do not actually "read" files, there may or may not be an actual native file format for a given compression format. Even for those that do have an associated file format, writing separate load code for each would be tedious and would require support.

Enter compressed texture container files, which can handle multiple or even all texture types. There are a few container file formats as well (.DDS, .PVR, and .KTX). Container files can also have all the mipmaps of a texture inside them. BJS implements this feature using KTX container files. KTX is specifically designed for OpenGL and pushes all the arcane code needed to handle any format OpenGL supports onto the file encoder / generator, even for future formats, without us doing anything other than adding extension detection, like ASTC.

Here is a chart of all the formats currently possible for WebGL, listed in the order chosen when hardware supports multiple formats (tie breakers):

| Format | Extension    | Description                                                                                                                         | Alpha Capable |
| ------ | ------------ | ----------------------------------------------------------------------------------------------------------------------------------- | ------------- |
| ASTC   | \*-astc.ktx  | Newly approved for WebGL, most powerful, cross-platform. Implemented in many newer processors, but not exposed by any browsers yet. | Always        |
| DXT    | \*-dxt.ktx   | Direct X, available primarily on Desktop Operating Systems.                                                                         | Yes           |
| PVRTC  | \*-pvrtc.ktx | Proprietary. Power VR chips (includes all Apple iOS processors). Must be square.                                                    | Yes           |
| ETC2   | \*-etc2.ktx  | ETC1 + alpha capable. Required by WebGL 2 (or at least OpenGL ES 3, on which WebGL 2 is based).                                     | Yes           |
| ATC    | \*-atc.ktx   | Format originating at AMD. No encoder which supports .KTX found at this time.                                                       | Yes           |
| ETC1   | \*etc1.ktx   | Wide support among older mobile devices. Need to fall back to images for .PNG files.                                                | No            |

Once your engine instance is established, you need to indicate the compressed formats that you have put on the server from which it can pick from. This should probably be done very early, as follows:

```javascript
// order & case do not matter
const available = ["-astc.ktx", "-dxt.ktx", "-pvrtc.ktx", "-etc2.ktx", "-etc1.ktx"];
const formatUsed = engine.setTextureFormatToUse(available);
```

## Generation using [PVRTexTool](https://developer.imaginationtech.com/pvrtextool/)

There are multiple encoder programs for .KTX files (see .KTX link above). Most also provide for batch processing, since many formats are very CPU intense. PVRTexTool has been narrowed down for providing additional support. It has a lot going for it, including both a GUI & command line interface for Windows, OSX, and Linux. It is also the only encoder which does PVRTC format, which is needed on iOS.

If you are going to do the encoding on your own in the PVRTexTool GUI tool, there are a few things to keep in mind:

- The texture must be encoded with the Y-axis flipped. ('Vertical Flipped' checkbox at bottom of Encode window)
- PVRTC textures must be square for iOS. ('Make Square' button in the Toolbox window using Resize tool)
- ASTC support is dropped in from an [external program](https://github.com/ARM-software/astc-encoder) from ARM that you put on the path. (See PVRTexTool [manual](http://cdn.imgtec.com/sdk-documentation/PVRTexTool.User+Manual.pdf), section 1.2.1)
- DXT support is done with 'BCx' names. (Better UI design for WebGL has been [requested](https://community.imgtec.com/forums/topic/could-webgl-be-added-as-an-encoding-groupapi/).)
- Indicating to generate mipmaps should really be done as well. (checkbox to the left of 'Vertical Flipped')
- Always use a Linear-RGB encoding type.
- Not sure a power of 2 size is absolutely required, but scripts below size up to the next power of 2 size.

### DOS batch scripts for PVRTexTool

There are 2 batch scripts in the [BJS repo](https://github.com/BabylonJS/Babylon.js/tree/master/Tools/CompressedTextured). They both require PVRTexToolCLI.exe to be put on the execution path, just as the ASTC drop-in was. Doing both at the same time, and locating these 2 .BAT files in the same place, seems like a good idea.

#### make-ktx-batch.bat

This script goes through the current directory and writes a `ktx-batch.bat` file there. When you then call `ktx-batch.bat`, it will make an ASTC, DXT, PVRTC, ETC2, and ETC1 file for each .JPG and .PNG in the directory. Note that a .PNG extension indicates that an alpha-capable subtype should be used. ETC1 does not support alpha, so the .PNG will be used as a fallback if ETC1 ends up being chosen.

There is a single argument that indicates the quality of the texture. Specify D for developer-level quality, Q for production quality. Tip: unless you are testing whether this fixes hanging issues on mobile devices, you could delay enabling this until all your textures are finalized. Also, do not rely on the results you get from using D on a desktop. DXT does not really have variable quality.

#### ktx-files.bat

This script will create the 5 variations of an image file. It can run for a very long time for the Q setting. The ASTC type will use 100% of all your cores, so your system can become pretty unusable. It's a good idea to kick it off at the end of the day. Also, due to the running time, it will skip any files that already exist. To redo files, delete the existing versions first.

To recap (in a command shell):

```dos
cd my-directory-with-images
make-ktx-batch Q
ktx-batch
```

### Node.js script for PVRTexTool

This is a script that generates PVRTC, ETC1, ETC2, and ASTC textures from PNG and JPG files. It can run on Node.js. It can also be configured to generate all texture types or specific ones. More information about how to install and configure the script can be found [here](https://www.npmjs.com/package/babylonjs-texture-generator).

### Basis file format

Another way to store compressed image textures is through the .basis file format.

See: https://github.com/BinomialLLC/basis_universal

Basis Universal is a "supercompressed" GPU texture and texture video compression system that outputs a highly compressed intermediate file format (.basis) that can be quickly transcoded to a wide variety of GPU texture compression formats: PVRTC1 4bpp RGB, BC7 mode 6 RGB, BC1-5, ETC1, and ETC2. We will be adding ASTC RGB or RGBA, BC7 mode 4/5 RGBA, and PVRTC1 4bpp RGBA next. Basis files support non-uniform texture arrays, so cubemaps, volume textures, texture arrays, mipmap levels, video sequences, or arbitrary texture "tiles" can be stored in a single file. The compressor is able to exploit color and pattern correlations across the entire file, so multiple images with mipmaps can be stored very efficiently in a single file.

Basic example: <Playground id="#4RN0VF" title="Basic Example of Basis Textures" description="Simple example of using .basis compressed textures in your scene."/>
Basis vs png example scene: <Playground id="#e4vddw#27" title="Basis Texture vs. png Texture" description="Simple example of .png vs basis compressed textures."/>



The Raw Texture feature is incredibly simple, but unbelievably powerful! It lets you create a texture from raw data. This is perfect for creating procedural textures on the fly. Let's take a look at how to create a simple RGB texture from scratch.

Creating a Raw RGB Texture can be done using the following construction method:

```javascript
new BABYLON.RawTexture.CreateRGBTexture(data, width, height, scene);
```

The parameters are:

* data: This is the raw data that you'll use for the RGB values of each pixel of your texture. The data needs to be an 8-bit array, specifically a javascript `Uint8Array`.

* width: The desired width of the texture you'd like to create.

* height: The desired height of the texture you'd like to create.

* scene: Your Babylon scene.

Here's a small demo showing it in action. Check out line 29 in this playground: <Playground id="#3TM0BZ" title="Raw Texture Noise Terrain Example" description="Simple example of using noise data to generate an rgb texture, used as a height map to displace a mesh for a terrain effect." image="/img/playgroundsAndNMEs/divingDeeperRawTexture1.webp"/>

In this case, random noise is generated, converted into a Uint8Array, and then used to create a Raw RGB Texture.

Here is a video explanation that dives a little further into how this demo uses the raw texture.

<Youtube id="YKqXcrWliww"/>

## Diving Deeper

Of course, creating an RGB texture on the fly is only the tip of the iceberg. There's a lot more you can do with Raw Texture, such as creating RGBA, Luminance, Alpha, and Luminance Alpha textures.

For more detail, be sure to check out the full API documentation on Raw Texture [here](/typedoc/classes/babylon.rawtexture).



Render pass ids are a new concept starting with Babylon.js 5.0.

It is used internally to enable new features (like using custom materials in effect layers or with the depth renderer), but it can also be used by the user to improve performance, for example.

## Generalities
Each time a mesh has to be rendered (a submesh, to be more precise, as in Babylon.js rendering is done at the submesh level), it is done in the context of a render pass, and a render pass is identified by a simple id (number): hence the name `render pass id`. There's also a name associated with a render pass id, but it is used for debugging purposes only (you can get all the render pass names by doing `engine.getRenderPassNames()` - the render pass id is the index in this array).

A number of data items (like the `effect`) used for rendering are associated with this render pass. Technically, these data are stored in `SubMesh._drawWrappers`: this is an array of `DrawWrapper`, and the index in this array is the render pass id.

The engine class keeps track of the current render pass id (`Engine.currentRenderPassId`) and this value is modified by the subsystems of Babylon.js:
* each `RenderTargetTexture` sets `engine.currentRenderPassId` to its own render pass id (`RenderTargetTexture.renderPassId`) before rendering the meshes (from its `renderList`)
* each camera has its own `renderPassId` which is used to render the meshes to the final texture/framebuffer

## Using render pass ids
As a user, you can create (and release) render pass ids very easily:
```javascript
const renderPassId = engine.createRenderPassId("My pass"); // the label is optional, as it is used for debugging purposes only
[...]
engine.releaseRenderPassId(renderPassId);
```

The main reason to manage render pass ids yourself is to improve performance when a mesh must be rendered with different materials depending on the rendering path.

### Changing materials when rendering to the final framebuffer
For example, if during the course of the program you must switch between Material A and Material B several times, you could simply loop over the meshes and change their `material` property. However, this is taxing on performance because each time you update the `material` property, some caches must be recreated, and it can have a visible impact (delay) on rendering.

Take this PG as an example:

<Playground id="#6XIT28#1158" title="Update lots of materials" description="Simple example of changing the materials used to display a lot of meshes."/>

When you click on the **material 1** and **material 2** buttons there's a visible delay before the display is updated.

Now, if you are using two render pass ids, one for each case, and set the `camera.renderPassId` property to the right one when clicking the buttons, you will notice there's no delay anymore (except the first time you click **material 2**, because the effects must be created):

<Playground id="#6XIT28#1160" title="Update lots of materials (render pass id)" description="Simple example of changing the materials used to display a lot of meshes with custom render pass ids."/>

You must use the `AbstractMesh.setMaterialForRenderPass(material, id)` method to associate a material for a mesh with a render pass id.

### Using a different material when rendering into a RenderTargetTexture
Before 5.0, it was not easy or performant to use a different material when rendering a mesh into a custom `RenderTargetTexture` and when rendering it into the final framebuffer. Thanks to the new render pass ids, you can now simply call `RenderTargetTexture.setMaterialForRenderPass(meshOrMeshes, material)` to render a mesh in the render target texture with a specific material without any performance penalty!

See an example [here](/features/featuresDeepDive/postProcesses/renderTargetTextureMultiPass#making-multiple-passes-and-composing-them)

### Using a different material when rendering with the depth renderer or into a glow/highlight layer 
In the exact same way as for the `RenderTargetTexture` class, you can use a specific material to render a mesh with the depth renderer by using the `DepthRenderer.setMaterialForRenderPass(meshOrMeshes, material)` method: internally it is simply calling `RenderTargetTexture.setMaterialForRenderPass(meshOrMeshes, material)`.

For example, you will need a custom material to render a mesh with the depth renderer if you are using a non-standard material to display the mesh in the final framebuffer (for example, if you update the vertex positions in the vertex shader):

<Playground id="#6GFJNR#161" title="Using a custom material with the depth renderer" description="Simple example of using a custom material to render a mesh with the depth renderer."/>

The same applies to the glow/highlight layers: use the `EffectLayer.setMaterialForRenderPass(meshOrMeshes, material)` method to set a specific material to be used for this layer.



Some complex scenes will require a large number of textures. A single material will often use three or more! To simplify the loading process, it can be convenient to package the textures from multiple materials into a series of images. The trade-off is that each texture will be scaled to a set size, which might cause some degradation, and there are also WebGL limits to take into consideration. The packer creates a set of "frames" for each unique material and its required texture channels. The result is one image for each channel used by the materials being packed. The process then modifies a target UV# from the meshes passed into the constructor so they match the frame of the texture sets. The system assumes textures have a 1:1 ratio (square).

Create a TexturePacker series by calling:

```javascript
let pack = new BABYLON.TexturePacker(name, targetMeshes, options, scene);
```

There are some limitations that you should consider. These include texture size limits, transparencies, and reflection/refraction materials. You can find more information here: <Playground id="#TQ408M" title="Creating A Texture Package" description="Simple example of creating a texture package." image="/img/playgroundsAndNMEs/divingDeeperCreateTexturePackage1.webp"/>

-   <Playground id="#TQ408M" title="Texture Packer Example 1" description="Simple example of using a texture packer in your scene." image="/img/playgroundsAndNMEs/divingDeeperCreateTexturePackage2.webp"/>

Create a TexturePacker by calling:

```javascript
let pack = new BABYLON.TexturePacker(name, targetMeshes, options, scene);
pack.processAsync().then(success).catch(error);
```

-   name:string, Name of the Texture Pack.
-   targetMeshes:`Array<AbstractMesh>`, Array of meshes to use as material sources.
-   options:any, Basic object with argument parameters.
-   scene:Scene, The scene that everything is scoped to.

The options argument has a few parameters you can use to tweak the result of the texture packing.

-   map:`Array<string>`, An array that contains the names of the channels to pack on the materials if they exist. `Default = [ 'ambientTexture', 'bumpTexture', 'diffuseTexture', 'emissiveTexture', 'lightmapTexture', 'opacityTexture', 'specularTexture' ]`
-   uvsIn:number, The target UV channel to use when creating the frames. `Default = BABYLON.VertexBuffer.UVKind`
-   uvsOut:number, The target UV channel to modify on the targetMeshes. `Default = BABYLON.VertexBuffer.UVKind`
-   layout:number, Defines the layout of the packer (LAYOUT_STRIP, LAYOUT_POWER2, LAYOUT_COLNUM). `Default = TexturePacker.LAYOUT_STRIP;`
-   colnum:number, If using LAYOUT_COLNUM, defines the number of columns to use. `Default = 8;`
-   frameSize:number, The base size of the frames before padding is added. `Default = 256;`
-   paddingMode:number, Defines the padding style of the packer (SUBUV_WRAP, SUBUV_EXTEND, SUBUV_COLOR). `Default = TexturePacker.SUBUV_WRAP;`
-   paddingColor:Color3|Color4, Custom color of the padding if paddingMode is SUBUV_COLOR. `Default = new Color4(0, 0, 0, 1.0);`
-   paddingRatio:number, Ratio of the amount of padding to add to the frames. `Default = 0.0115;`
-   fillBlanks:boolean, Toggle to fill blank cells when a material does not use that channel. `Default = true;`
-   customFillColor:string, css color string for what color to fill the blank frames. `Default = 'black';`
-   updateInputMeshes:boolean, Toggle to have the packer automatically update the input meshes to the new packer frames and channels. `Default = true;`
-   disposeSources:boolean, Toggle to dispose the source textures after they are packed. `Default = true;`

For PBR materials you will need to change the map to reflect the channels you want to target. The Environment map should be handled separately.

In order to ensure that the packing process does not block your thread, you will have to start the compilation process with

```javascript
pack.processAsync().then(success).catch(error);
```

All interactions with your pack should happen in the success callback of the returned promise. See the playgrounds below for examples.

-   <Playground id="#TQ408M#6" title="Texture Packer Example 2" description="Simple example of using a texture packer in your scene." image="/img/playgroundsAndNMEs/divingDeeperCreateTexturePackage2.webp"/>

Downloading the pack is simple! When initializing the package either through a JSON load or naturally through the above-mentioned constructor, a Promise object is created.
To ensure that the textures are all packed and ready to go, put any interactions with the texture pack inside the success callback of the `then` method.

```javascript

pack.processAsync().then(
    //Success
    ()=>{
        pack.download( type, ?quality);
    }
)
```

You can tell the downloader to switch between JPEG and PNG image types depending on whether you need an alpha channel. Because the images are stored as base64, you should avoid using PNG unless absolutely necessary. You can always download both types and then manually mix and match inside the JSON file.

-   <Playground id="#TQ408M#25" title="Texture Packer Download Example" description="Simple example of changing between jpeg and png depending on alpha channel." image="/img/playgroundsAndNMEs/divingDeeperCreateTexturePackage2.webp"/>

## Loading From JSON

Loading a downloaded package is easy! First, create a blank Texture Package.

```javascript
let pack = new BABYLON.TexturePacker("", [], {}, scene);
```

Then simply call the loadFromJSON method, passing the JSON file as a string and using the same success/error promise callback structure as `processAsync`.

```javascript
pack.updateFromJSON(jsonString).then(success).catch(error);
```

-   <Playground id="#TQ408M#9" title="Texture Packer Load Example" description="Simple example of using the texture packer loader in your scene." image="/img/playgroundsAndNMEs/divingDeeperCreateTexturePackage3.webp"/>
-   <Playground id="#96CDLA" title="PBR Texture Packer Load Example" description="Simple example of loading a PBR packed texture into your scene." image="/img/playgroundsAndNMEs/divingDeeperCreateTexturePackage4.webp"/>



## How Materials Work

Materials are an encapsulation of shaders. They provide a simple way to configure and share shaders.

## Cache and compilation
The first time a material is created, an internal object named effect is created. The effect is the host for the vertex and pixel (fragment) shaders.
These shaders have to be compiled by the GPU from plain text to GPU machine code.

The compilation step is done synchronously on the main thread and could therefore cause a bit of lag in rendering.

As the process is a bit expensive, once compiled, an effect will remain in memory until you dispose of the engine.

Every time you change a property of a material (like adding a texture or enabling an option), a new effect will be compiled unless an equivalent can be found in the cache.

## Rendering optimization

Since v5.0, meshes are sorted according to the `uniqueId` property of their material, in ascending order, and are rendered in this sorted order. This is to optimize state changes and reduce the number of times these states need to be changed. You can change this order by changing the `uniqueId` value, or by using the [setRenderingOrder](/typedoc/classes/babylon.scene#setrenderingorder) method of the scene.

## Precompilation
By default, materials are compiled only when required. But you may want to precompile everything before rendering to get the smoothest experience possible.

To do so, you can just prepare your material with: 

```
material.forceCompilation(mesh, function() {
    // Do something when material is compiled
});
```

For instance, you could go through all your meshes and force compilation of all materials to get everything ready before the first frame.

## Non blocking textures
You also have the option to flag textures as non-blocking. By default, a material will not be able to render a mesh until its effect is compiled and all textures are loaded.

You can choose to render your mesh even if textures are not loaded (the missing textures will be replaced by a 1x1 black texture). To do so, just call:

```
texture.isBlocking = false;
```



## Advanced Materials

To help you customize materials, this section takes a more detailed, in-depth look at how materials work in Babylon.js.


## How To Use the Node Material with Particles

The Node Material Editor (aka NME) is a powerful tool that can be used to design shaders, [particles](/features/featuresDeepDive/materials/node_material/nodeMaterial#creating-particle-shaders), and [post processes](/features/featuresDeepDive/materials/node_material/nodeMaterial#creating-post-processes).

This article will help you set up a simple scene with only a few lines of code, because all of the work will be done using our editors.

You can see the final result here:

<Playground id="#RA18GJ" title="Node Material With Particles" description="Simple example of using the node material to create a particle fragment shader." image="/img/playgroundsAndNMEs/divingDeeperNodeMaterialParticle1.webp"/>

## Setting up the scene

Setting up this scene is actually quite simple. We only need a scene, a camera, and a sphere to act as the particle emitter:

```javascript
const scene = new BABYLON.Scene(engine);

const camera = new BABYLON.ArcRotateCamera("Camera", 0, 0.8, 10, BABYLON.Vector3.Zero(), scene);
camera.attachControl(canvas, true);

// Create a random emitter
const sphere = BABYLON.MeshBuilder.CreateSphere("sphere", { diameter: 0.01, segments: 4 }, scene);
```

## Invoking the inspector to create our particle system

If you are executing this code in the [Playground](https://playground.babylonjs.com), you can simply click on the Inspector button inside the header bar.

If you are running the code on your own, you can call `scene.debugLayer.show()`.

Once there, you can right-click on the "Particle Systems" node to create a new particle system:

![Create new system](/img/how_to/Particles/create_new_system.jpg)

The inspector will then let you play with all the parameters to define the system the way you want.

When you're done setting up your system, you can go to the Snippet zone and click "Save to Snippet Server":

![Save a snippet](/img/how_to/Particles/save_snippet.jpg)

This will give you a snippet ID that we will use later to load the particle system from our code.

You can see my setup in this playground:

<Playground id="#KST50Y" title="Particles Created In the Inspector" description="Simple example showing particles saved and loaded from the snippet server."/>

## Working with the snippet server

The beauty of the snippet server is that it gives you a central place to store and update your particle system without having to modify your code.

We can use the [async/await pattern](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function) in our example to load a snippet asynchronously. We can flag our function as `async` and then `await` a link to our particle system using the snippet ID:

```javascript
const createScene = async function () {
  const scene = new BABYLON.Scene(engine);

  const camera = new BABYLON.ArcRotateCamera("Camera", 0, 0.8, 10, BABYLON.Vector3.Zero(), scene);
  camera.attachControl(canvas, true);

  // Create a random emitter
  const sphere = BABYLON.MeshBuilder.CreateSphere("sphere", { diameter: 0.01, segments: 4 }, scene);

  // Load the previously setup particle system (it was setup with the inspector)
  let system = await BABYLON.ParticleHelper.CreateFromSnippetAsync("T54JV7#13", scene, false);
  system.emitter = sphere;

  return scene;
};
```

As you can see, you can simply call `BABYLON.ParticleHelper.CreateFromSnippetAsync` to download your particle system from the snippet server.

If you do not want to (or cannot) use async / await, you can get the same outcome using Promises:

```javascript
BABYLON.ParticleHelper.CreateFromSnippetAsync("T54JV7#13", scene, false).then((system) => {
  system.emitter = sphere;
});
```

## Creating the node material for our particle system

We are going to use the same approach for the node material.

To set up our material, let's open the NME at [https://nme.babylonjs.com/](https://nme.babylonjs.com/)

The NME can be used for materials, particles, and post processes. We'll switch to particles mode:

![Particle mode in NME](/img/how_to/Particles/nme_particle.jpg)

For this demo, I created a material where the particles are displayed with one texture when above ground (y = 0) and with another one below ground, with a smooth transition between the two. Here is the shader I ended up with: <NME id="#345ATT#4" title="Node Material Particle Shader Example" description="Simple example of using the node material to create a particle fragment shader." image="/img/playgroundsAndNMEs/divingDeeperNodeMaterialParticle2.webp"/>

![Demo shader](/img/how_to/Particles/demo_shader.jpg)

In a nutshell, I'm checking the particle position in world space and using a [smoothstep](https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/smoothstep.xhtml) to output a value between 0 and 1, which is then used with a gradient between black and white. This color is then used to mix (lerp) between two textures.

Just like the particle system, you can save your creation to the snippet server and get a snippet ID.

## Applying the material

The final step is to get that shader from the snippet server and use it with our particle system.

To do so, we will use the exact same approach as before:

```javascript
// Load our node material
let nodeMaterial = await BABYLON.NodeMaterial.ParseFromSnippetAsync("#345ATT#4", scene);

// Apply it to the particle system
nodeMaterial.createEffectForParticles(system);
```

As you can see, the NodeMaterial class has a handy function to apply it to a particle system.

And voila!
The final code is extremely simple (thanks to async/await in particular):

```javascript
const createScene = async function () {
  const scene = new BABYLON.Scene(engine);

  const camera = new BABYLON.ArcRotateCamera("Camera", 0, 0.8, 10, BABYLON.Vector3.Zero(), scene);
  camera.attachControl(canvas, true);

  // Create a random emitter
  const sphere = BABYLON.MeshBuilder.CreateSphere("sphere", { diameter: 0.01, segments: 4 }, scene);

  // Load the previously setup particle system (it was setup with the inspector)
  let system = await BABYLON.ParticleHelper.CreateFromSnippetAsync("T54JV7#13", scene, false);
  system.emitter = sphere;

  // Load our node material
  let nodeMaterial = await BABYLON.NodeMaterial.ParseFromSnippetAsync("#345ATT#4", scene);

  // Apply it to the particle system
  nodeMaterial.createEffectForParticles(system);

  return scene;
};
```

## Automatic updates

The best part is that our Playground can evolve automagically. If you open the main Playground (referenced at the beginning of this article), you can keep editing the particle system or the material, and your code will automatically update. This happens every time you open the Inspector and use one of the editors. When you click "Save to Snippet Server", the system will be smart enough to work with the Playground and update the link for you:

![Automatic update](/img/how_to/Particles/auto-pg.webp)

You can see in the GIF that the Snippet ID for the particle system is updated to version #14 when I hit the save button.

Now that we know about that automatic update, there is another option for creating the initial particle system. You could have called `CreateFromSnippetAsync` with a "\_\_BLANK" ID:

```javascript
BABYLON.ParticleHelper.CreateFromSnippetAsync("_BLANK", scene, false).then((system) => {
  system.emitter = sphere;
});
```

From there, you could use the Inspector to edit it (the Inspector can replace the \_\_BLANK with the right ID later on).


Advanced Materials

Advanced Materials

Coming next

Materials and Vertices

Learn about the relationship between materials and vertices.

How Babylon.js Materials Work

Learn about how materials in Babylon.js work under the hood.

Creating Procedural Textures

Learn how to create your own procedural textures in Babylon.js.

Creating A Texture Package

Learn how to create your own texture package in Babylon.js.

Multi-Platform Compressed Textures

Learn all about multi-platform compressed textures in Babylon.js.

Render pass ids

Learn all about render pass id in Babylon.js.

Transparent Rendering

Learn all about how transparency is handled in Babylon.js.

Creating Raw RGB Textures

Learn how to create raw rgb textures in Babylon.js.

Depth Renderer

Learn all about the depth renderer in Babylon.js.

Logarithmic Depth Buffer

Learn how to use the logarithmic depth buffer in Babylon.js.