
## Transformations About the Local Origin

When a mesh is created, the position vector for each vertex is given from (0, 0, 0), the _created origin_ of the mesh, which is also its _local origin_ for [translation](/typedoc/classes/babylon.transformnode#translate), rotation, and scaling. In this section, the center of transformation of a mesh will always be its _local origin_. For changes to the center of transformation, visit [Parents and Pivots](/features/featuresDeepDive/mesh/transforms/parent_pivot). As well as simply assigning vector values to change the position, rotation, and scale of a mesh, it is also possible to use coordinate transformation to transform one mesh in terms of another mesh's frame of reference. You can also transform the mesh vertex coordinates and effectively change the _local origin_. This process of _baking transformations_ is described here, although it should only be necessary in exceptional circumstances.



## Why Handedness Matters

A 3D coordinate system needs three axes, but there are two consistent ways to choose the positive direction of the third axis. These are called **right-handed** and **left-handed** coordinate systems. Neither is more correct. Handedness is a convention, like choosing which direction on a map is north.

The distinction can be expressed with a cross product:

- Right-handed: `X cross Y = Z`
- Left-handed: `X cross Y = -Z`

If positive X points right and positive Y points up on the page, positive Z points toward you in a right-handed system and away from you in a left-handed system.

![Comparison of right-handed and left-handed coordinate systems](/img/features/mesh/coordinate-system-handedness.svg)

Changing handedness is a **reflection**, not a rotation. For example, when the X and Y axes keep the same meaning, reflecting Z converts a point between otherwise aligned systems:

```javascript
const leftHandedPoint = new BABYLON.Vector3(
  rightHandedPoint.x,
  rightHandedPoint.y,
  -rightHandedPoint.z,
);
```

That example is useful for understanding the math, but it is not a complete asset-pipeline conversion. A full conversion may also need to update rotations, animation keys, normals, tangents, cameras, and triangle winding. Use a format-aware exporter and importer whenever possible.

## Babylon.js and glTF Conventions

Babylon.js scenes are **left-handed by default**. Positive X is right, positive Y is up, and positive Z is forward. To use a right-handed Babylon.js scene, set the mode before creating or loading scene content. In that mode, positive X remains right and positive Y remains up, so forward becomes negative Z:

```javascript
const scene = new BABYLON.Scene(engine);
scene.useRightHandedSystem = true;
```

This setting changes how the scene interprets coordinates; it does not rewrite geometry or transforms that already exist. Choose the handedness before creating cameras, meshes, or imported content.

[glTF 2.0 uses a right-handed coordinate system](https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#coordinate-system-and-units), with positive Y up, positive Z forward, negative X right, and distances measured in meters. For triangle topology, glTF defines counterclockwise winding after a global transform with a positive determinant and clockwise winding after a transform with a negative determinant.

| Content | Handedness | Right | Up | Forward |
| --- | --- | --- | --- | --- |
| Default Babylon.js scene | Left-handed | +X | +Y | +Z |
| Right-handed Babylon.js scene | Right-handed | +X | +Y | -Z |
| glTF 2.0 | Right-handed | -X | +Y | +Z |

The same axis names do not mean that every numeric transform can be copied unchanged: changing handedness changes the relationship among the axes.

## Loading glTF in Babylon.js

The Babylon.js glTF loader handles the conversion automatically. Its default `AUTO` coordinate-system mode reads the scene setting:

- In a default left-handed scene, the loader adds a `__root__` node and applies the handedness conversion there.
- In a right-handed scene, glTF data already matches the scene handedness, so the `__root__` node does not need that conversion.

In a left-handed scene, the loader currently represents this root conversion as a 180-degree rotation around Y together with a Z scale of `-1`. Keep the generated root in the hierarchy unless you deliberately bake and verify the complete conversion.

Set `scene.useRightHandedSystem` **before** loading the asset. Do not also mirror the imported meshes or negate an axis in application code unless you intentionally need an additional reflection.

```javascript
const scene = new BABYLON.Scene(engine);

// Choose this before loading. Omit it to keep Babylon.js's default LH scene.
scene.useRightHandedSystem = true;

const result = await BABYLON.ImportMeshAsync("model.glb", scene);
const importedRoot = result.meshes[0]; // The glTF loader's __root__ node.
```

The conversion on `__root__` is part of the imported hierarchy. Code that reads local transforms, reparents imported nodes, drives bones, or creates physics bodies should account for that parent. Use world transforms such as `getAbsolutePosition()` when you need the final scene-space result.

## Faces, Normals, and Tangent Space

Reflecting geometry reverses its orientation. If you manually convert raw vertex data, remember all related data:

- Reverse triangle winding, or select the matching Babylon.js side orientation, so front-face culling remains correct. Remember that a negative-determinant node transform already changes the glTF winding convention.
- Transform normals as directions and normalize them. Do not treat normals as positions.
- Transform tangents consistently. The `w` component of a glTF tangent stores the sign used to reconstruct the bitangent, so a reflection can require that sign to change.
- Recheck normal maps after conversion because tangent-space orientation determines how their channels are interpreted.

The glTF loader performs these format-specific steps, including choosing the side orientation and normal-map inversion settings for the scene handedness. This checklist is for custom importers, procedural geometry, and pipelines that alter raw mesh buffers.

## A Reliable DCC-to-Babylon Workflow

Blender, Maya, Unity, and other tools expose their own world, camera, and object-axis conventions. Those conventions can also vary by exporter, project settings, or plugin version. Avoid relying on a remembered statement such as "tool X is always left-handed."

1. Mark the authored asset with temporary asymmetry: label its right side, add a forward-pointing marker, and place a small object on only one side.
2. Export with a glTF 2.0 exporter that documents support for your tool version. Let the exporter convert the tool's coordinates to glTF.
3. Test the GLB or glTF in the [Babylon.js Sandbox](https://sandbox.babylonjs.com/) before adding runtime corrections.
4. Load it into a Babylon.js scene with your intended handedness. Do not apply another axis flip merely because the source tool uses a different convention.
5. Verify front faces, normal maps, animation direction, camera orientation, and any code that depends on "forward."
6. Keep any unavoidable correction on one named parent node and document why it exists. Do not scatter sign changes through gameplay code.

For tool-specific export settings, see [Exporting to glTF](/preparingArtForBabylon/dccToGltf), [Blender to Babylon.js using glTF](/features/featuresDeepDive/Exporters/Blender_to_glTF), and [Exporting a Maya scene as glTF](/features/featuresDeepDive/Exporters/Maya_to_glTF). For Unity or another engine, use a glTF exporter whose documentation states how it maps that engine's axes to glTF, then treat the exported glTF conventions as the interchange contract.

### Tool-specific cautions

- **Blender:** Its supported glTF add-on converts Blender's scene axes to glTF. Keep the exporter's coordinate conversion enabled instead of adding a second Babylon-specific flip.
- **Maya:** The project up axis can be configured as Y or Z. Verify the active project and exporter settings rather than assuming a universal Maya default.
- **Unity:** Coordinate conversion depends on the selected glTF package and version. Follow that exporter's documentation and validate the emitted file; do not transfer conversion rules from an unrelated Unity package.

## Common Symptoms

| Symptom | Likely cause | What to check |
| --- | --- | --- |
| Model faces backward | An extra reflection or forward-axis assumption | Remove manual axis flips and inspect the imported `__root__` transform |
| Model looks inside-out | Winding was not reversed after a manual reflection | Index order, `sideOrientation`, and material back-face culling |
| Normal map looks dented instead of raised | Tangent basis or normal-map convention does not match | Exported tangents, tangent `w`, and material normal-map settings |
| Animation turns the wrong way | Rotation data was converted like a position | Let the exporter/importer convert animation transforms |
| Physics shape is offset or mirrored | Physics was built from local values below a converted root | Build from world transforms or follow the glTF physics guidance |

Handedness bugs are easiest to solve at one pipeline boundary. First verify the exported glTF, then verify the loader's root conversion, and only then add a deliberate application-level transform if the asset's authored orientation requires it.



## What is a lattice to begin with?

A lattice is like a flexible grid of points used to modify or reshape objects in 3D. Imagine a net wrapped around an object, where you can pull or push the points of the net to change the shape of the object inside.

Instead of adjusting each small part of the object directly, you just move the points of the lattice. The object inside will stretch, bend, or twist based on how you move the lattice, and the changes happen smoothly. This makes it much easier to apply complex transformations to an object without dealing with every little detail.

An example of a 10x10x10 lattice over a sphere mesh:
![10x10x10 Lattice](/img/features/lattice.webp)

## Creating a lattice

To create a lattice you simply need to instantiate it:

```
var lattice = new BABYLON.Lattice();
```

By default the lattice is created with the following properties:

- size: (1,1,1)
- position: (0,0,0)
- resolutionX: 3
- resolutionY: 3
- resolutionZ: 3

You can define each property at construction time:

```
var lattice = new BABYLON.Lattice({ size: new BABYLON.Vector3(2, 2, 2), position: BABYLON.Vector3.Zero()});
```

## Object space

The lattice works in object space, meaning that the size you define for a lattice has to be relative to the deformed mesh's object space.

In other words, the mesh world matrix is not taken into account, as the lattice works at the geometry level (so before the world transform is applied).

For instance, assuming you have a scene with a sphere created with a diameter of 2, you will have to set the size of the lattice to (2,2,2) in order to fully encompass the sphere, no matter what position, scaling or rotation are set on the sphere.

The same applies to `lattice.position`, which is also in object space.

Please note that you can call your lattice constructor with the option `autoAdaptToMesh` set to a mesh and the system will automatically compute the correct lattice size:

```
var lattice = new BABYLON.Lattice({
    autoAdaptToMesh: mesh
});

```

## Defining the lattice

By default a lattice will simply not change your mesh until you update its data:

```
   // Make it pointy
    for (x = 0; x < lattice.resolutionX; x++) {
        for (z = 0; z < lattice.resolutionZ; z++) {
            const control = lattice.data[x][lattice.resolutionY - 1][z];
            control.y += 1;
        }
    }
```

By accessing the data property, you will have access to the three-dimensional arrays containing each control point.
It is then up to you to update these points to apply the deformation you need.

## Applying the lattice

To apply the lattice you can either call `deform(vertexData)` or `deformMesh(mesh)`.

Here is an example with a vertex data:

```
var sphere = BABYLON.MeshBuilder.CreateSphere("sphere", {diameter: 2, segments: 32}, scene);
const positions = sphere.getVerticesData(BABYLON.VertexBuffer.PositionKind);
lattice.deform(positions);
sphere.setVerticesData(BABYLON.VertexBuffer.PositionKind, positions, true);
sphere.createNormals(true);
```

Please note that it is your responsibility to then update the mesh and rebuild the normals.

This is then equivalent to:

```
var sphere = BABYLON.MeshBuilder.CreateSphere("sphere", {diameter: 2, segments: 32}, scene);
lattice.deformMesh(sphere);
sphere.createNormals(true);
```

## Updating the lattice

A lattice can be moved by updating its position value (so the lattice will move in object space).
Here is a complete example of a moving lattice:

```
 var sphere = BABYLON.MeshBuilder.CreateSphere("sphere", {diameter: 2, segments: 32}, scene);
const positions = sphere.getVerticesData(BABYLON.VertexBuffer.PositionKind);
const updates = new Float32Array(positions.length);

// lattice
var lattice = new BABYLON.Lattice({ size: new BABYLON.Vector3(2, 2, 2), position: BABYLON.Vector3.Zero()});

// Make it pointy
for (x = 0; x < lattice.resolutionX; x++) {
    for (z = 0; z < lattice.resolutionZ; z++) {
        const control = lattice.data[x][lattice.resolutionY - 1][z];
        control.y += 1;
    }
}

// Shrink that belly!
for (x = 0; x < lattice.resolutionX; x++) {
    for (z = 0; z < lattice.resolutionZ; z++) {
        const control = lattice.data[x][1][z];
        control.x = 0;
        control.z = 0;
    }
}

let offset = -2;
scene.onBeforeRenderObservable.add(() => {
    lattice.position.x = offset;
    offset += 0.01;

    lattice.deform(positions, updates);
    sphere.setVerticesData(BABYLON.VertexBuffer.PositionKind, updates, true);
    sphere.createNormals(true);
});

```

One important point here is that we use the `deform` function with a second parameter in order to not alter the original mesh data.
<Playground id="#MDVD75#18" title="Moving lattice" description="Simple example of a moving lattice."/>

You can also update the lattice data:

```javascript
const loadedData = await BABYLON.ImportMeshAsync("scenes/skull.babylon", scene);
const skull = loadedData.meshes[0];
skull.position.set(0, 0, 0);

const positions = skull.getVerticesData(BABYLON.VertexBuffer.PositionKind);
const updatedPositions = new Float32Array(positions.length);

// lattice
var lattice = new BABYLON.Lattice({
  resolutionY: 10,
  autoAdaptToMesh: skull,
  position: BABYLON.Vector3.Zero(),
});

scene.onBeforeRenderObservable.add(() => {
  // Twist!!
  for (x = 0; x < lattice.resolutionX; x++) {
    for (y = 0; y < lattice.resolutionY; y++) {
      for (z = 0; z < lattice.resolutionZ; z++) {
        const angle = (y / lattice.resolutionY) * 0.02;
        const control = lattice.data[x][y][z];
        const cx = control.x;
        const cz = control.z;

        const cosAngle = Math.cos(angle);
        const sinAngle = Math.sin(angle);

        // Rotation
        control.x = cosAngle * cx - sinAngle * cz;
        control.z = sinAngle * cx + cosAngle * cz;
      }
    }
  }

  lattice.deform(positions, updatedPositions);
  skull.setVerticesData(BABYLON.VertexBuffer.PositionKind, updatedPositions);
  skull.createNormals(true);
});
```

<Playground id="#MDVD75#27" title="Updating lattice data" description="The twisting skull."/>



## Transformation, Pivots and Parents

If you want to rotate or scale a mesh, or another object, about a point other than its own _local origin_, you can do so by changing its center of transformation using either a parent or a pivot. Although in general conversation, and in some 3D applications, a center of transformation may be referred to as a pivot point, in Babylon.js the term _pivot_ is used when setting a center of transformation with a specific method. The effects of using a parent or a pivot are different. To obtain behavior similar to the pivot point behavior described in applications such as 3DS Max or Maya, set [`mesh.parent`](/typedoc/classes/babylon.node#parent) to act as the pivot point rather than using [`setPivotPoint`](/typedoc/classes/babylon.transformnode#setPivotPoint).

When the `parent` property is set on a mesh, transforming the parent applies the same transformations to the child. [Translations](/typedoc/classes/babylon.transformnode#translate), rotations, and scaling of the child take place relative to the _local origin_ of the child. Setting the position of the child is relative to the _local origin_ of the parent. In simpler terms, moving the child will not move the parent, and moving the parent will move the child.

Depending on the [method used to produce the parent-child relationship](/features/featuresDeepDive/mesh/transforms/parent_pivot/parent), some transformations made to the parent prior to the moment of forming the relationship may also be applied to the children at or after that moment. It usually makes sense not to rotate or move a child before assigning its parent.

When a pivot is set on a mesh, repositioning the mesh will reposition the pivot so that its placement relative to the mesh is not changed. Rotation and scaling of the mesh take place relative to the pivot. More simply, moving the mesh will move the pivot and moving the pivot will not move the mesh.

Using a pivot can be tricky, and a number of methods are available. Some of these methods, but not all, may actually change the _local origin_ of a mesh.



## Transformations
Transformations are the actions that change an object's position, rotation, and scale. Although this section largely covers transformations applied to meshes, some also apply to other Babylon.js objects.

Applying transformations can seem straightforward, and in many cases they are, such as when changing position. Other aspects may appear easy, but in practice can be difficult in concept, execution, or both. In 3D, something as simple as a rotation can prove tricky: once you have rotated a mesh about x and y, its z axis may not be where you expect because a mesh's local frame of reference rotates with it.

Frames of reference in 3D are formed by an origin and three mutually perpendicular axes through that origin. When created in Babylon.js, objects are placed using a frame of reference in **World Space**, where there are two horizontal axes, x and z, and a vertical y axis in a left-handed system. See [Coordinate Systems and Handedness](/features/featuresDeepDive/mesh/transforms/coordinateSystems) for Babylon.js's optional right-handed mode and practical glTF conversion guidance.

Each mesh also has its own **Local Space**. Meshes built within Babylon.js are created with their local space origin at the world space origin and with their local space axes x, y, and z aligned with the x, y, and z axes of world space. The local origin acts as the center of transformation unless pivots or parents are added to the mesh. Both cases are described below.

Meshes created in other packages and imported may use different frames of reference.



## Vertex Normals

Each triangular facet of a mesh comprises three vertices. Besides a position, each vertex has another important Vector3 called a normal. These vertex normals are used by the [shader code](/features/featuresDeepDive/materials/shaders/introToShaders) to calculate how the mesh is lit. Unlike a mathematical normal, they do not need to be set at right angles, and for curved shapes such as a sphere they may not be. In the case of a sphere, they are set as the mathematical normals of the sphere surface rather than of the flat facets of the mesh that create the sphere.

At first, the vertex normals are calculated as the mathematical normals for the facet. It then depends on whether you want to view the facets as flat surfaces or as part of a curve. For flat surfaces, the vertex normals remain as the mathematical normals. To enhance the curve when viewed under light, where triangular facets share vertices with the same positions, each shared vertex normal is recalculated to be the average of the mathematical normals of the shared facets.


These effects are explored below.

In the following two playgrounds see how the changing directions within the normals array affect how it is lit:

<Playground id="#VKBJN#18" title="Vertex Normals Varying In Unison" description="Simple example of vertex normals varying in unison."/>

<Playground id="#VKBJN#19" title="Showing Normals Varying" description="Simple example of showing vertex normal variation."/>

## Normals and Minimum Vertices

![Wireframe](/img/how_to/Mesh/box1.webp)

The box above has 8 vertices. If we want to keep the indices to the minimum they will be 0, 1, 2, 3, 4, 5, 6, 7.

Facets 0, 3, 7 and 3, 7, 6 and 0, 3, 2 all have vertex 3 in common and vertex 3 can only have one
entry in the normals array associated with it.

How does Babylon.js calculate the `normal` for vertex 3?

The diagram below shows that the average of the three mathematical normals at each vertex is used:

![Normals](/img/how_to/Mesh/box4.webp)

Besides minimising the number of vertices needed there are other advantages as will be seen when creating a sphere.

Keeping the indices to a minimum the normals at each corner are an average of the mathematical normals of the three faces that meet at that corner. So 8 corners and 8 unique vertex normals.

## Table of Unique Indices, Positions and Normals for Box with Minimum Vertices

| index | position         | normal                                                              |
| ----- | ---------------- | ------------------------------------------------------------------- |
| 0     | ( -1 , 1 , -1 )  | ( -0.5773502691896258 , 0.5773502691896258 , -0.5773502691896258 )  |
| 1     | ( 1 , 1 , -1 )   | ( 0.8164965809277261 , 0.4082482904638631 , -0.4082482904638631 )   |
| 2     | ( 1 , -1 , -1 )  | ( 0.4082482904638631 , -0.4082482904638631 , -0.8164965809277261 )  |
| 3     | ( -1 , -1 , -1 ) | ( -0.4082482904638631 , -0.8164965809277261 , -0.4082482904638631 ) |
| 4     | ( -1 , 1 , 1 )   | ( -0.4082482904638631 , 0.4082482904638631 , 0.8164965809277261 )   |
| 5     | ( 1 , 1 , 1 )    | ( 0.4082482904638631 , 0.8164965809277261 , 0.4082482904638631 )    |
| 6     | ( 1 , -1 , 1 )   | ( 0.5773502691896258 , -0.5773502691896258 , 0.5773502691896258 )   |
| 7     | ( -1 , -1 , 1 )  | ( -0.8164965809277261 , -0.4082482904638631 , 0.4082482904638631 )  |

## Normals and Flat Shaded Meshes.

There are times, such as needing each face of a box to be covered in a [different material](/features/featuresDeepDive/mesh/facetData),
when it is better to have the box constructed from separate faces, each of which is constructed from two facets, with no two faces
sharing vertex indices. They will, of course, share vertex positions.

![Seperate Faces](/img/how_to/Mesh/box3.webp)

In Babylon.js this can be achieved using the `convertToFlatShadedMesh` function. The results are shown below:

![Flat Shaded Normals](/img/how_to/Mesh/box5.webp)

For a flat-shaded mesh, each of the triangular facets making up a face of the box has mathematical normals as its vertex normals. For simplicity of illustration, we will consider only the six faces making up the box rather than the full range of triangular facets used in the mesh construction. Each face has 4 corners, and each corner has a unique normal at right angles to the face. There are 6 faces on a box, and so 24 unique corner normals.

## Table of Faces, Corners, Positions and Normals for Flat Shaded Box

| Face  | corner | position         | normal           |
| ----- | ------ | ---------------- | ---------------- |
| Front | 0      | ( -1 , 1 , -1 )  | ( 0 , 0 , -1 )   |
| Front | 1      | ( 1 , -1 , -1 )  | ( 0 , 0 , -1 )   |
| Front | 2      | ( 1 , 1 , -1 )   | ( 0 , 0 , -1 )   |
| Front | 3      | ( -1 , 1 , -1 )  | ( 0 , 0 , -1 )   |
| Back  | 4      | ( -1 , 1 , 1 )   | ( 0 , 0 , 1 )    |
| Back  | 5      | ( 1 , -1 , 1 )   | ( 0 , 0 , 1 )    |
| Back  | 6      | ( -1 , -1 , 1 )  | ( 0 , 0 , 1 )    |
| Back  | 7      | ( -1 , 1 , 1 )   | ( 0 , 0 , 1 )    |
| Right | 8      | ( 1 , 1 , -1 )   | ( 1 , -0 , 0 )   |
| Right | 9      | ( 1 , -1 , 1 )   | ( 1 , -0 , 0 )   |
| Right | 10     | ( 1 , 1 , 1 )    | ( 1 , -0 , 0 )   |
| Right | 11     | ( 1 , 1 , -1 )   | ( 1 , 0 , 0 )    |
| Left  | 12     | ( -1 , 1 , -1 )  | ( -1 , 0 , 0 )   |
| Left  | 13     | ( -1 , -1 , 1 )  | ( -1 , 0 , 0 )   |
| Left  | 14     | ( -1 , -1 , -1 ) | ( -1 , 0 , 0 )   |
| Left  | 15     | ( -1 , 1 , -1 )  | ( -1 , -0 , -0 ) |
| Top   | 16     | ( -1 , 1 , -1 )  | ( 0 , 1 , 0 )    |
| Top   | 17     | ( 1 , 1 , 1 )    | ( 0 , 1 , 0 )    |
| Top   | 18     | ( -1 , 1 , 1 )   | ( 0 , 1 , 0 )    |
| Top   | 19     | ( 1 , 1 , -1 )   | ( 0 , 1 , -0 )   |
| Base  | 20     | ( -1 , -1 , -1 ) | ( 0 , -1 , -0 )  |
| Base  | 21     | ( 1 , -1 , 1 )   | ( 0 , -1 , -0 )  |
| Base  | 22     | ( 1 , -1 , -1 )  | ( 0 , -1 , -0 )  |
| Base  | 23     | ( -1 , -1 , 1 )  | ( 0 , -1 , 0 )   |

## Playground Showing Box Normals

<Playground id="#1H7L5C#113" title="Box Normals" description="Simple example of box normals."/>

## Advantage of Shared Normals

Sharing normals means that the shader produces a rounder looking sphere since the vertex normals are the mathematical normals of the sphere surface.

Applying the function `converToFlatShadedMesh` shows the individual faces making up the sphere. For a flat shaded sphere the normals of each facet are the mathematical normals of the facet.

<Playground id="#1H7L5C#38" title="Comparing Shading of Spheres" description="Simple example comparing shading of spheres."/>


Mesh Transformations

Transformations

Coming next

Centered on Created Origin

Learn origins and pivots in Babylon.js.

Coordinate Systems and Handedness

Understand left-handed and right-handed coordinate systems and move assets safely between Babylon.js, glTF, and content creation tools.

Parents and Pivots

Learn all about parent relationships and pivots in Babylon.js.

Lattice

Learn all about deforming meshes with lattices in Babylon.js.