
## 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 only render once. If set to 1, it will render every frame, 2 every two frames, etc.

**Uniforms** are the values that will be passed from the javascript code to the shader code. By setting them that way, you can allow the custom texture user to modify this value 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 contained in your main function will be called once for each pixel to create on the texture. In this main function, you only know the coordinates of the current pixel in the final texture.

Here is a simple code which is setting 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 object you want the pixel to be.
Here is a more complex example using 2 samplers and mixing their color 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 difference is only that you specify a new parameter which is 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 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 DOM Element shader for custom procedural textures : the config.json file is not needed anymore and you can just use setFloat or setVector3 (and so on), and setTexture on the CustomProceduralTexture will give values and Sampler2D 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.jpg"/>



BABYLON.DepthRenderer is a tool used to generate depth texture (a texture that contains depth buffer and which 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 for you the renderer with depth values. All active meshes (Meshes which are visible from the current camera 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 textures by using `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, generated texture uses float components thanks to _WebGL OES_texture_float extension_. If this extension is not supported, Babylon.js reverts back to byte component which means less precision for depth values.**



## Materials and Vertices

BabylonJS allows you to create many meshes and apply material to them quite simply and in a range of ways.

Sometimes it may be useful to know more on how this is achieved. Any attempt to answer the question of how colors and textures are applied to a mesh must start with looking at the construction of a mesh.

Below is a simple wireframe cube which has 8 vertices:

![Wireframe](/img/how_to/Materials/box1.jpg)

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.jpg)

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.jpg)

## 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 texture around the mesh will mean each vertex being assigned 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 should different colors or textures need to be applied to different faces
since adjoining faces use the same vertex index.

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 was to be wrapped around faces `3, 2, 6, 7` and `1, 2, 6, 5` and `0, 1, 5, 4` and `0, 3, 7, 4` it is not 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 edges with a face. For example taking the shared edge 3, 7 and replacing with a face gives:

![Extra Face](/img/how_to/Materials/box2.jpg)

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 and 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 fill or messed up images but by setting vertices 8 and 3 to have the same position and also 9 and 7 to have the same position the face `3, 7, 9, 8` disappears, the box appears to only have six faces and the adjoining faces have the color or image wanted.

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.jpg)

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 big numbers. 
In short, the depth values are proportional to the reciprocal of Z. This gives good precision near the camera, but a little off 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 *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 formats of textures which are optimized for access by graphics processors. They differ from formats whose primary mission is to hold / transmit image data for use on a CPU. Examples of image formats are .JPG & .PNG. Formats catering to GPUs 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 of compressed textures is passed to the graphics hardware in its compressed form. A .JPG can be very small on disk, but gets expanded by the CPU on its way to the GPU. Retaining its compressed form is what gives these formats their advantages. They are:

- They have a smaller RAM footprint. This is most helpful for mobile devices which share memory between CPU and graphics cores. Since textures are multi-dimensional, space requirements can escalate very fast 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, and not look blurry when very close.
- More compressed image "blocks" can fit into the cache of the processor at any one time. Caching / data access patterns are very important for high performance computing (HPC), which graphics is a form of.
- Finally, they could lower battery usage, especially during loading. Image formats need to be unpacked. Back when .JPG was being designed, battery computers were mostly just luggables. The problems being addressed were network speed & disk space. Who cared then how much CPU was required for re-constituting 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 the low level implementation for them in hardware, support for a given format cannot be added like a software driver update. Support is manufactured right into the circuitry. This is less of a problem when building an iOS, Android, or DirectX targeted application. For a BJS scene which should ideally be able to 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 of doing that involves having different files for each of the variants obviously, but the naming structure must be formalized in order to programmatically substitute for the image format file described in a .babylon file. The image format file of each texture still needs to be on the server as well, in cases when 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 due to the fact that this data is not directly used by CPU's and GPU's 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 load code for each separately would be tedious and require support.

Enter compressed texture container files, which can handle multiple or even all texture types. There are also a few container file formats as well (.DDS, .PVR, & .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 forces all the arcane code to handle any format OpenGL supports onto the file encoder / generator, even future formats without us doing anything other than adding extension detection, like ASTC.

Here is a chart of all the current formats 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 that PVRTexToolCLI.exe, 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 thing to do.

#### 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 is an indicator to use an alpha capable sub-type. ETC1 does not support alpha, so the .PNG will be used as a fall back, if ETC1 ends up being chosen.

There is a single argument which indicates the quality of the texture. Specify D for developer level, Q for production quality. Tip: unless you are testing if this fixes hanging issues on mobile devices, you could just delay enabling this till all your textures get 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 Q setting. The ASTC type will use 100% of all your cores, so your system can be pretty unusable. Good to kick it off at the end of day. Also, due to running time, it will skip any files already existing. To re-do 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, ASTC textures from png and jpg files. It can run on node. Also it can 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 allows you to create a texture from raw data! This type of thing 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 of it working. 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.jpg"/>

In this case, random noise is being generated, converted into a Uint8Array and that is then used to create a Raw RGB Texture.

Here is a video explanation, diving a little futher 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 the effect layers or with the depth renderer) but it can also be used by the user, to improve performances for eg.

## Generalities
Each time a mesh has to be rendered (a submesh to be more precise, as in Babylon.js the 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 to a render pass id, but it is used for debugging purpose 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 (like the `effect`) used for the rendering is associated to 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 purpose only
[...]
engine.releaseRenderPassId(renderPassId);
```

The main interest for managing render pass ids yourself is to improve performances when a mesh must be rendered with different materials depending on the rendering path.

### Changing materials when rendering to the final framebuffer
For eg, 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 some visible impact (delay) on the 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 sets the `camera.renderPassId` property to the right one when clicking on the buttons, you will notice there's no delay anymore (except the first time when you click on **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/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 eg, 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 to the final framebuffer (for eg, 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."/>

Same thing for 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 amount 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 will be that each texture will be scaled to a set size and might cause some desegregation, there are also WebGL limits to take into consideration as well. The packer will create a set of "frames" for each unique material and its required texture channels. The result produces one image for each channel that is used by the materials that are being packed. The process then modifies a target UV# from the meshes passed into the constructor, making them match the frame of the texture sets. The system assumes textures are 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 refection/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.jpg"/>

-   <Playground id="#TQ408M" title="Texture Packer Example 1" description="Simple example of using a texture packer in your scene." image="/img/playgroundsAndNMEs/divingDeeperCreateTexturePackage2.jpg"/>

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 will define 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 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 full blank cell 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 lock your thread you will have to start the compilation process with

```javascript
pack.processAsync().then(success).catch(error);
```

Having all interactions with your pack happening in the success callback on the returned promise. See the below playgrounds 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.jpg"/>

Downloading the pack is simple! When initializing the package through both a JSON load or naturally like in the above mentioned constructor, a Promise Object is created.
In order to assure that the textures are all packed and ready to go we call 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 downloaded to change between jpeg and png image types depending on if you need an alpha channel. Due to the fact that 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.jpg"/>

## Loading From JSON

To load from a downloaded package is easy! First create a blank Texture Package.

```javascript
let pack = new BABYLON.TexturePacker("", [], {}, scene);
```

Then simply call the loadFromJSON method, with JSON file as a string and then the same success/error promise callback structure as the 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.jpg"/>
-   <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.jpg"/>



## How Materials Work

Materials are an encapsulation on top 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 will be 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 a process that will be done synchronously on the main thread and thus could cause a bit of lag in the rendering.

As the process is a bit expensive, once compiled an effect will remain in memory until you dispose the engine. 

Everytime you will 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 running your rendering in order to get the smoother 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 in order to get everything ready before the first frame.

## Non blocking textures
You also have the opportunity 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 decide to still 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 customise materials this sections takes a more detailed in depth look at how materials work with 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 that will contain 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.jpg"/>

## 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 asychronously. 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 setup 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 postprocesses. 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.jpg"/>

![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 gets 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 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.gif)

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 was another option to create the initial particle. You could have called the CreateFromSnippetAsync with a "\_\_BLANK" id:

```javascript
BABYLON.ParticleHelper.CreateFromSnippetAsync("_BLANK", scene, false).then((system) => {
  system.emitter = sphere;
});
```

And then from there you could have used the Inspector to edit it (The inspector can replace the \_\_BLANK with the right id later on)
