
# How To Reduce Memory Footprint

Babylon.js offers multiple options to reduce the memory usage of a scene:

## Turning off IndexedDB

By default, all assets are saved in the local IndexedDB to reduce network calls when loading the same files multiple times.
This feature uses memory so you can turn it off at engine level with:

```
 engine.enableOfflineSupport = false;
```

## Turning off support for context lost / context restore

Babylon.js will automatically recreate everything in a transparent way if the [WebGL context is lost](/features/featuresDeepDive/scene/optimize_your_scene#handling-webgl-context-lost).
While handy, this feature consumes a lot of memory, so you may want to turn it off when creating the engine with:

```
var engine = new BABYLON.Engine(canvas, true, {doNotHandleContextLost: true});
```

You can also turn it off after engine creation (but before creating any resources) with:

```
engine.doNotHandleContextLost = true;
```

## Removing cached vertex data

All vertex buffers keep a copy of their data in CPU memory to support collisions, picking, geometry editing, or physics.
If you don't need to use these features, you can call this function to free associated memory:

```
scene.clearCachedVertexData();
```

## Removing cached texture buffers

In order to be able to serialize or rebuild them, all textures keep an internal buffer of the original source (this could be a string if you used a URL, but it could also be a buffer if you used a blob).
If you don't need to use these features, you can call this function to free associated memory:

```
scene.cleanCachedTextureBuffer();
```


You can find a demo here: <Playground id="#AS54U8#1" title="Reducing Memory Footprint Example" description="Simple example showing how to reduce the memory footprint of a scene."/>



An offscreen canvas is a canvas that can be rendered offscreen and on a different thread than the main UI thread.

It could be really interesting to do so if your main thread is already heavily used for other tasks.

You can see a page demonstrating this use case here: https://www.babylonjs.com/Demos/Offscreen/

<Youtube id="zYrZNROQzKQ"/>

# Setting up the engine

Starting with Babylon.js v4.1, you can create an engine inside a worker by initializing it with an offscreen canvas.

First, you need to create an offscreen canvas out of your regular canvas:

```javascript
var canvas = document.getElementById("renderCanvas");
canvas.width = canvas.clientWidth;
canvas.height = canvas.clientHeight;
var offscreen = canvas.transferControlToOffscreen();
```

Then you need to spin off a new worker and send it the offscreen canvas.

```javascript
var worker = new Worker("worker.js");
worker.postMessage({ canvas: offscreen }, [offscreen]);
```

The worker code will then listen for your message, get the offscreen canvas, and start Babylon.js as usual:

```javascript
onmessage = function (evt) {
  canvas = evt.data.canvas;
  var engine = new BABYLON.Engine(canvas, true);

  // Your scene setup here
};
```

Then you can use your engine as usual.

# Caveats

The main caveat of using Babylon.js with an offscreen canvas in a worker thread is that you will need to do special work to communicate with the engine from the main thread. You will have to use the same messaging API we used before to communicate between threads.

Furthermore, Babylon.js will not be able to handle inputs for you, so APIs like `camera.attachControls()` will not work and you will have to message inputs to workers.

Here is an example of communication you will have to set up to support canvas resizing.

On main thread:

```javascript
window.addEventListener("resize", () => {
  worker.postMessage({ width: canvas.clientWidth, height: canvas.clientHeight });
});
```

On worker thread:

```javascript
var engine;
onmessage = function (evt) {
  if (evt.data.width) {
    canvas.width = evt.data.width;
    canvas.height = evt.data.height;
  }
};
```

# Compatibility

Note that this feature is new and not yet compatible with every device or browser.
You can check current support of offscreen canvas here: https://caniuse.com/#feat=offscreencanvas

If you want to test the compatibility, you can add this condition before using offscreen canvas:

```javascript
if ("OffscreenCanvas" in window && "transferControlToOffscreen" in canvas) {
  // Ok to use offscreen canvas
}
```

# Resources

- https://developer.mozilla.org/en-US/docs/Web/API/OffscreenCanvas
- https://developers.google.com/web/updates/2018/08/offscreen-canvas



# Large World Rendering / Floating Origin

## The Problem

When working with very large world coordinates, 32-bit floating point numbers lose precision. A float32 value can represent roughly 7 significant decimal digits, which means that at a world position of 1,000,000 units from the origin, the smallest representable step is about 0.06 units. This loss of precision causes visible **jittering** — meshes wobble, shadows flicker, and animations stutter — even though the objects themselves are not moving.

This is a well-known problem in flight simulators, space games, open-world titles, and any application where the camera can be very far from the world origin.

## The Solution: Floating Origin and HighPrecisionMatrices

Babylon.js provides a **floating origin** system that eliminates precision issues by keeping the active camera conceptually at the world origin and offsetting all geometry and shader uniforms by the camera's position. This means that no matter how far you travel from the original world origin, the values sent to the GPU are always small and precise.

The system has two complementary parts:

1. **`useLargeWorldRendering`** — an engine option that sets both `useHighPrecisionMatrices` on the engine and enables `floatingOriginMode` on all scenes.
    - `useHighPrecisionMatrices` forces **high precision (64-bit) matrix computations** on the CPU, so intermediate math remains accurate.
    - `floatingOriginMode` **offsets all matrix uniforms** (`world`, `view`, `viewProjection`, `worldViewProjection`, etc.) so the camera is treated as being at the world origin, and **offsets position-related values** (`eye position`, `clip planes`, etc.) by the camera's actual position. This is all performed at the last stage before passing the values to the shader.
2. **`useFloatingOrigin`** — a scene option that enables `floatingOriginMode` when not all scenes are large worlds. If only some scenes use `useFloatingOrigin`, you must also instantiate the engine with `useHighPrecisionMatrices` to get full large-world rendering capabilities.



From the perspective of your application code, nothing changes — meshes are still positioned at their world coordinates, the camera moves normally, and all existing APIs work as before. The offsetting happens at the rendering layer and is not detectable by the user.

## Examples

<Playground id="#5U0N0Q" title="Large World Rendering Demo" description="Side-by-side comparison of rendering with and without floating origin enabled. Move the camera to see jitter" image="/img/playgroundsAndNMEs/floatingOriginMain.webp" />
## Quick Start

The simplest way to enable floating origin is at the engine level:

```javascript
const engine = new BABYLON.Engine(canvas, true, {
    useLargeWorldRendering: true,
});

// All scenes created from this engine will automatically use floating origin
const scene = new BABYLON.Scene(engine);
```

Setting `useLargeWorldRendering: true` does two things:

1. Enables `useHighPrecisionMatrix` — all `Matrix` computations use 64-bit doubles internally.
2. Enables `floatingOriginMode` on every scene created by this engine.

### Per-Scene Control

If you only want floating origin on specific scenes (for example, your main world scene but not a UI scene), you can enable it per-scene instead. In this case, you must also enable high precision matrices on the engine:

```javascript
const engine = new BABYLON.Engine(canvas, true, {
    useHighPrecisionMatrix: true,
});

// Only this scene will use floating origin
const worldScene = new BABYLON.Scene(engine, { useFloatingOrigin: true });

// This scene will NOT use floating origin
const uiScene = new BABYLON.Scene(engine);
```

## API Reference

### Engine Options (`AbstractEngineOptions`)

| Option                   | Type      | Default | Description                                                                                                                              |
| ------------------------ | --------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
| `useLargeWorldRendering` | `boolean` | `false` | Enables both high precision matrices and floating origin mode on all scenes.                                                             |
| `useHighPrecisionMatrix` | `boolean` | `false` | Forces 64-bit matrix computations. Required for proper large world rendering. Automatically set when `useLargeWorldRendering` is `true`. |

### Scene Properties

| Property                     | Type                 | Description                                                                                                                             |
| ---------------------------- | -------------------- | --------------------------------------------------------------------------------------------------------------------------------------- |
| `scene.floatingOriginMode`   | `boolean` (readonly) | `true` if floating origin is active on this scene.                                                                                      |
| `scene.floatingOriginOffset` | `Vector3` (readonly) | The current offset applied to all rendering. Equal to the active camera's eye position when enabled, or `Vector3.Zero()` when disabled. |

### Scene Options (`ISceneOptions`)

| Option              | Type      | Default | Description                                      |
| ------------------- | --------- | ------- | ------------------------------------------------ |
| `useFloatingOrigin` | `boolean` | `false` | Enables floating origin for this specific scene. |

## How It Works

### Matrix Interception

When floating origin mode is active, Babylon.js monkey-patches `Effect.setMatrix` and `UniformBuffer._updateMatrixForUniform` to intercept every matrix being sent to shaders. Based on the uniform name, the system applies the appropriate offset:

- **`world`** — The world matrix translation is shifted by subtracting the camera position.
- **`view`** — The view matrix translation is zeroed out (since the camera is conceptually at the origin).
- **`worldView`** — Decomposed into world and view, each offset separately, then recomposed.
- **`viewProjection`** — The view is offset and remultiplied with the projection matrix.
- **`worldViewProjection`** — Fully decomposed, offset, and recomposed.

This also works with **Node Material** custom blocks, where uniform names are prefixed with `u_` (e.g., `u_World`, `u_ViewProjection`).

### Additional Offsets

Beyond matrices, the system also offsets:

- **Eye position** (`vEyePosition`) — Shifted so lighting and reflections compute correctly relative to the offset geometry.
- **Clip planes** — Adjusted using the formula `d' = d + normal · offset` so clipping works at the correct world-space boundaries.

### What Is Handled Automatically

The following Babylon.js subsystems are floating-origin-aware and require no additional work:

- Standard and PBR materials
- Node Materials
- Shadow generators (including cascaded shadow maps)
- Particles (GPU and CPU)
- Sprites
- Lights (point, spot, area, clustered)
- Bounding box and edge renderers
- Background and sky materials
- Water material
- Atmosphere addon
- Utility layers (gizmos, overlays, etc.)

### **A note about Custom shaders.** 
If you have custom shaders that use position-based uniforms, ensure they use standard uniform names (`world`, `view`, `viewProjection`, `worldViewProjection`) so the floating origin system can intercept and offset them automatically. For Node Materials, block uniforms prefixed with `u_` are handled automatically.

## Physics: Havok Multi-Region Support

### The Physics Precision Problem

The floating origin system keeps rendering precise by offsetting values before they reach the GPU. However, the **Havok physics engine** also uses 32-bit floats internally. If physics bodies are positioned at large world coordinates, the same precision loss occurs in the physics simulation — bodies jitter, collisions become unreliable, and constraints break down.

### Multi-Region Worlds

To solve this, the Havok plugin implements a **multi-region** architecture. Instead of simulating all bodies in a single physics world, bodies are distributed across multiple Havok world instances, each with its own **fixed floating origin**. Bodies within a region are simulated using coordinates relative to that region's origin, keeping all values small and precise.

This happens automatically when `floatingOriginMode` is enabled on the scene. You don't need to manually manage regions — the plugin handles creation, assignment, and cleanup.

### How It Works

1. **Region creation**: When a physics body is created, the plugin checks if an existing world region contains its world position (within the configured radius). If not, a new region is created centered at that position.

2. **Body simulation**: Each body stores its transform relative to its region's floating origin. From the body's perspective, it is always near the origin of its local physics world.

3. **Region migration**: During each physics step, bodies that have moved outside their current region's boundary (with a 20% hysteresis margin to prevent oscillation) are automatically migrated to the correct region. Linear and angular velocity are preserved across the transition.

4. **Velocity-based look-ahead**: When a body leaves its region, the plugin projects its position forward by one second of travel to find the best target region. This prevents creating unnecessary intermediate regions for fast-moving bodies heading toward existing regions.

5. **Garbage collection**: Empty non-default regions are automatically cleaned up when all their bodies have migrated elsewhere.

6. **Per-region gravity**: Each world region can have its own gravity vector, enabling scenarios like planetary bodies with different gravitational fields.

### Configuration

The Havok plugin accepts an optional `floatingOriginWorldRadius` parameter:

```javascript
const havokInstance = await HavokPhysics();
const havokPlugin = new BABYLON.HavokPlugin(true, havokInstance, {
    floatingOriginWorldRadius: 100000, // default: 100,000 units
});

scene.enablePhysics(new BABYLON.Vector3(0, -9.81, 0), havokPlugin);
```

| Parameter                   | Type     | Default  | Description                                                                                                                                                                                   |
| --------------------------- | -------- | -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `floatingOriginWorldRadius` | `number` | `100000` | The radius of each physics world region. Bodies within this distance of a region's origin are simulated in that region. Bodies outside all existing regions trigger creation of a new region. |

Choose a radius that balances precision with the number of regions:

- **Larger radius** = fewer regions, but bodies farther from region origins may still lose some precision.
- **Smaller radius** = more regions and better precision, but more overhead from region management and body migration.

For most applications, the default of 100,000 units provides a good balance.

### Per-Region Gravity

You can set gravity for a specific world region by passing a world position to `setGravity`:

```javascript
// Set gravity for the region containing this position
havokPlugin.setGravity(new BABYLON.Vector3(0, -1.62, 0), new BABYLON.Vector3(500000, 0, 0));

// Get gravity for a specific region
const gravity = havokPlugin.getGravity(new BABYLON.Vector3(500000, 0, 0));
```

When called without a position, `setGravity` and `getGravity` operate on all regions or return the default gravity.








## Physics Examples

<Playground id="#9NRVWK" title="Havok+FloatingOrigin Stacked Boxes" description="Side-by-side view of havok physics far from world origin, with floatingorigin mode enabled/disabled" image="/img/playgroundsAndNMEs/havokFloatingOriginStacked.webp"/>

<Playground id="#24ZAQP" title="Havok+FloatingOrigin BoomBox" description="Side by side of havok physics with floating origin enabled / disabled" image="/img/playgroundsAndNMEs/havokBoombox.webp" />

<Playground id="#7N17MT#26" title="Havok Multi-Region with Dynamic Re-Regioning" description="Demonstrates multi-region physics with dynamic re-regioning. Use 'Launch Ball' to test physics drift collision across regions, and 'Move Box' to test teleporting bodies between regions." image="/img/playgroundsAndNMEs/havokFloatingOrigin.webp" />