
## Flow Graph Basic Concepts

Let's dive into the basic concepts of the Flow Graph system in Babylon.js.

The flow graph system is controlled by a flow graph coordinator, which in turn controls one or more graphs. A graph is a collection of blocks connected to each other by edges. Each block has a type, which determines its behavior and the types of edges it can have. The starting blocks are event blocks, which are triggered by events in the scene. Each graph can have one or more execution contexts, which are used to store data and state information for the blocks in the graph.

Here is a deeper dive into the basic concepts of the flow graph system. Some concepts might be referenced at first without explanation, but they are explained at a later point in the documentation.

Note that we might use "block" and "node" interchangeably. The official name for the component is "block", but "node" is more common in the programming world.

![Base concepts relations](/img/flowGraph/flowGraphBaseConcepts.webp)

### Flow Graph coordinator

The flow graph coordinator is the main entry point for the flow graph system. It is responsible for creating and managing graphs, as well as starting graph execution.
The coordinator is directly related to a scene, which is the main container for all of the objects on which the flow graph system operates. When a scene is disposed, the flow graph coordinator (and with it all graphs, blocks, contexts, and so on) is also disposed. A scene can have more than one coordinator if the use case requires it.

Think of a coordinator as the "global object" for all graphs within it. Using the coordinator, graphs can "communicate" with each other using a simple event-based system. A custom global event triggered by one graph can be listened to by another graph because the coordinator allows it.

To create a new coordinator, simply use its constructor:

```javascript
const coordinator = new FlowGraphCoordinator({ scene });
```

Afterwards, the coordinator can be used to create graphs, as described in the next section.

To start all graphs connected to a coordinator, use the `start` method:

```javascript
coordinator.start();
```

### Flow Graph

A flow graph is a collection of stateless blocks, each responsible for an action or a set of actions. The blocks are connected to each other using data or flow connections.
Think of it as a list of instructions without the list of objects those instructions run on. In a cookbook, the graph would be the list of instructions without the ingredients. The list of ingredients comes from the execution context, which we will discuss in the next section.

A graph belongs to a coordinator, and is created using the `createGraph` method of the coordinator:

```javascript
const graph = coordinator.createGraph();
```

Each FlowGraph object has its own SceneEventCoordinator, which is the "glue" between scene events and the graph itself. When an event block is added to the graph, it is automatically connected to the ScenEventCoordinator, which listens to the scene events and triggers the event block when the event occurs.

A flow graph will usually be started by its coordinator. However, it can be manually started using the `start` method:

```javascript
graph.start();
```

As the blocks are not aware of the graph they belong to, you will need to add any new event block you create yourself to the graph. A graph can have 1 or more event blocks, but it is not required to have any. If a graph has no event blocks, it will be idle and will not execute any blocks.
To add an event block to a graph, use the `addEventblock` method:

```javascript
const eventblock = new MyNewEventblock();
graph.addEventBlock(eventblock);
```

The different events that the flow graph currently supports are:

- SceneStart
- SceneDispose
- SceneBeforeRender
- SceneAfterRender
- MeshPick
- PointerDown
- PointerUp
- PointerMove
- PointerOver
- PointerOut

It is important to note that even if an event is supported by the graph, it will not be executed if there is no block to catch it. For example, if the graph itself can respond to a PointerMove event, but no PointerMove block is added to the graph, the event will not be executed.

When an event occurs, the SceneEventCoordinator will trigger the event block, which will then execute the block(s) connected to it. Each block's action will be executed with all available execution contexts. A graph can have one or more execution contexts. If none was created, a new one will be created when the graph starts.

### Execution Context

The execution context is, as derived from its name, the context in which the graph is executed. It holds a list of variables and references to objects in the scene, which can be used by the blocks in the graph. The context is created when the graph is started, and is passed to each block when it is executed.
Thinking of a cookbook again, the execution context is the list of ingredients. We can have the instructions to wash, cut and fry, but without knowing what we are executing it on, we cannot do anything.

To create a new context, use the `createContext` method of the FlowGraph class:

```javascript
const context = graph.createContext();
```

The context holds a few important lists of variables:

- user variables - A list of user-defined variables, which can be used by any of the blocks in the graph. These variables are created and managed by the user, and can be used to store data that needs to be accessed by the different blocks.
- Execution variables - A block doesn't have any internal state. Instead, it stores its state in the execution context. Think about these as the "private" variables of a specific block. This is important when implementing a new block - it should never have any internal state, but should use the execution context to store its state.
- global context variables - whereas an execution variable is for a specific block, the global variables are shared among blocks that are using the same context. This is a perfect way for the graph to share information between blocks that are not directly connected to each other.
- connection values - the (cached) values of the connections between blocks. This is important for performance, as it avoids recalculating the same value multiple times.

For a developer using the flow graph, only the first list is important. This is the list of variables that can be used in the blocks. The other lists are used internally by the flow graph system.
To define a new variable, simply use the setVariable method:

```javascript
context.setVariable("myVar", 42);
```

To get the value of a variable, use the getVariable method:

```javascript
const myVar = context.getVariable("myVar");
```

However, most of the time you will only use the setVariable method. The rest will be handled by the blocks.

### Blocks

Blocks are the building blocks of the flow graph system. Each block is responsible for a specific action or set of actions, and can be connected to other blocks to create complex interactions. There are 3 main types of blocks:

- Event blocks - These blocks are triggered by events in the scene, such as a pointer down or a mesh pick. They are the starting point of the graph, and are responsible for triggering the execution of the other blocks.
- Execution blocks - These blocks are responsible for controlling the flow of execution in the graph. They can be used to create loops, branches, and other control structures. These blocks can be asynchronous.
- Data blocks - These blocks are used to perform calculations and manipulate data. They are passive in nature, and can be used to create complex expressions and algorithms. Good examples are Math blocks - add, subtract, multiply, divide, etc.

You can read more about the specific blocks we have in the [Flow Graph Blocks section](/features/featuresDeepDive/flowGraph/flowGraphBlocks). I will use different types of blocks in the next few examples, which I hope will be self-explanatory.

### Connections

Blocks are connected using flow graph connections. A flow graph connection is a link between two blocks, which allows data to be passed from one block to another. There are two types of connections:

- Data connections - These connections are used to pass data between blocks. They are represented by a solid line in the graph. They have a specific type, which determines the type of data that can be passed through the connection. For example, a number connection can only pass numbers, while a string connection can only pass strings. "Any" is also a valid type, and can be used to pass any type of data.
- Signal connections - These connections are used to control the flow of execution in the graph. They can be seen as mini "events" between blocks. They will typically be added to execution blocks.

A data connection can hold a single value. The value can either come from a data output of a block, or directly from the connection itself. The connection can also hold a default value, which will be used if the connection is not connected to any block and doesn't have an explicit value.
A signal connection holds no value, but can have a payload. Think of the payload as the event data passed when the event is triggered. It is mainly used to pass the type of error that occurred, but it can be used for other purposes as well.

The value of a connection will be cached per execution. This means that, for example, if a math block has two inputs, and both are connected to the same Random block, the Random block will be executed only once, and its value will be used for both inputs. This is important for performance, as it avoids recalculating the same value multiple times. If you want to have different random values, use two different Random blocks.

Execution blocks will typically have an "in" and an "out" signal connection. The "in" connection is used to trigger the execution of the block, and the "out" connection is used to signal that the block has executed.
Asynchronous blocks will have an additional "done" signal connection, which is used to signal that the block has finished executing. In this case, the "out" can be thought of as a "passthrough" connection, which is used to pass execution to the next block. Most blocks also have an "error" signal connection, which is used to signal that an error has occurred during execution.

## Simple abstract example to explain the concepts

<Alert severity="info">
For examples and writing your own first graph, please refer to the [Write your first flow graph](/features/featuresDeepDive/flowGraph/flowGraphExamples).
</Alert>

To understand the different types of blocks and connections, let's think of a simple "rinse, cut, and fry a potato and a carrot" recipe (for developers, of course). I will mostly use pseudocode, so please don't take this example, run it in the playground, and wonder why your carrots are not frying.

The steps are these:

1. Rinse
1. Cut
1. Fry

This is a list of execution blocks: Get, Rinse, Cut, Fry. Each of these instructions has a list of inputs and outputs:

| Block | Data inputs                          | Signal inputs             | Data outputs     | Signal outputs                               |
| ----- | ------------------------------------ | ------------------------- | ---------------- | -------------------------------------------- |
| Rinse | Vegetable To rinse, use soap         | start rinsing             | rinsed vegetable | started rinsing, done rinsing                |
| Cut   | rinsed vegetable, knife, type of cut | stat cutting              | cut vegetable    | started cutting, done cutting, error cutting |
| Fry   | cut vegetable, oil, temperature      | start frying, stop frying | fried vegetable  | started frying, done frying, error frying    |

There is another instruction missing - `Start cooking`. This is the event block that will be the trigger to start the entire process. All of those are added to a simple graph:

Start cooking -> Rinse -> Cut -> Fry

And since we have two vegetables to cut, we will have two contexts (because it makes sense in this case). The first context will be used for the potato, and the second one for the carrot. The graph will be executed twice, once for each context.

So, let's create the graph first:

```javascript
const graph = coordinator.createGraph();
```

Then, we will create the contexts and set the needed variables:

```javascript
const potatoContext = graph.createContext();
potatoContext.setVariable("vegetable", "potato");
potatoContext.setVariable("cutType", "slices");

const carrotContext = graph.createContext();
carrotContext.setVariable("vegetable", "carrot");
carrotContext.setVariable("cutType", "sticks");
```

Now, we will create the blocks:

```javascript
// data blocks
const getVegetableBlock = new GetVariableBlock({ variableName: "vegetable" });
const getCutTypeBlock = new GetVariableBlock({ variableName: "cutType" });

// execution blocks
const rinseBlock = new RinseBlock();
rinseBlock.vegetableToRinse.connectTo(getVegetableBlock);
// using a value directly, on each of the contexts
rinseBlock.useSoap.setValue(true, potatoContext);
rinseBlock.useSoap.setValue(false, carrotContext);

const cutBlock = new CutBlock();
cutBlock.rinsedVegetable.connectTo(rinseBlock.rinsedVegetable); // connect the two blocks using a data connection
cutBlock.cutType.connectTo(getCutTypeBlock);
// trigger cut when done rinsing
rinseBlock.doneRinsing.connectTo(cutBlock.startCutting);

const fryBlock = new FryBlock();
fryBlock.cutVegetable.connectTo(cutBlock.cutVegetable); // connect the two blocks using a data connection

// now the event block
const startCookingBlock = new StartCookingBlock();
graph.addEventBlock(startCookingBlock);

graph.start();
```

Now the graph will be executed twice -- once for a potato and once for a carrot. We are still missing a few things (which you can think about how to implement yourself):

- Error handling
- Kids safety
- Serving
- Different temperatures, different knives, different types of frying

This is not the perfect example, but I hope it makes the concepts easier to understand.



## Flow Graph Examples

As stated previously, the flow graph is a perfect match for a visual editor. However, if you want to use the flow graph in code, you will need to write your own graphs.

This section will show you how to write your own graphs using code. Let's start with a few basic examples.

### Example 1: Simple output to the console

This flow graph logs a message on the console when the scene is loaded.

![Basic example 1](/img/flowGraph/basic1.webp)

```javascript
const coord = new FlowGraphCoordinator({ scene });

const graph = coord.createGraph();

const ctx = graph.createContext();

const sceneReady = new FlowGraphSceneReadyEventBlock();
graph.addEventBlock(sceneReady);

const log = new FlowGraphConsoleLogBlock();
log.message.setValue("Hello, world!", ctx);
sceneReady.done.connectTo(log.in);

coord.start();
```

<Playground id="#FQWPBI" title="Flow Graph basic example 1" snapshot="refs/pull/16201/merge"/>

### Example 2: Simple output to the console using a GetVariable block

This flow graph logs a message on the console when the scene is loaded. The message is stored in a variable on the context and can be reused.

![Basic example 2](/img/flowGraph/basic2.webp)

```javascript
const coord = new FlowGraphCoordinator({ scene });
const graph = coord.createGraph();
graph.createContext();
const sceneReady = new FlowGraphSceneReadyEventBlock();
graph.addEventBlock(sceneReady);

const log = new FlowGraphConsoleLogBlock();
const getVariableBlock = new FlowGraphGetVariableBlock({
  variable: "sceneReadyLogMessage",
  initialValue: "Hello Scene",
});
log.message.connectTo(getVariableBlock.value);
sceneReady.done.connectTo(log.in);

coord.start();
```

<Playground id="#FQWPBI#1" title="Flow Graph basic example 2" snapshot="refs/pull/16201/merge"/>

### Example 3 - Position interpolation using the animation and interpolation blocks

This flow graph animates a sphere from one position to another using the animation and interpolation blocks.

![Basic example 3](/img/flowGraph/basic3.webp)

```javascript
const coord = new FlowGraphCoordinator({ scene });
const graph = coord.createGraph();
const context = graph.createContext();
const sceneReady = new FlowGraphSceneReadyEventBlock();
graph.addEventBlock(sceneReady);

const interpolationBlock = new FlowGraphInterpolationBlock({
  animationType: Constants.ANIMATIONTYPE_VECTOR3,
  duration: 1,
  propertyName: "position",
});
interpolationBlock.endValue.setValue(new Vector3(1, 2, 3), context);

const assetToWorkOn = new FlowGraphGetAssetBlock({
  type: FlowGraphAssetType.Mesh,
  index: 0,
});

const playAnimation = new FlowGraphPlayAnimationBlock();
playAnimation.object.connectTo(assetToWorkOn.value);
playAnimation.animation.connectTo(interpolationBlock.animation);

sceneReady.done.connectTo(playAnimation.in);

coord.start();
```

<Playground id="#FQWPBI#5" title="Flow Graph basic example 3" snapshot="refs/pull/16201/merge"/>

### Example 4 - Multiple contexts running the same interpolation graph

This flow graph moves the two assets in the scene using the same interpolation graph.

```javascript
const coord = new FlowGraphCoordinator({ scene });
const graph = coord.createGraph();
const sceneReady = new FlowGraphSceneReadyEventBlock();
graph.addEventBlock(sceneReady);

const ctx1 = graph.createContext();
ctx1.setVariable("assetToWorkOn", sphere);
ctx1.setVariable("endPosition", new Vector3(1, 2, 3));
const ctx2 = graph.createContext();
ctx2.setVariable("assetToWorkOn", ground);
ctx2.setVariable("endPosition", new Vector3(-3, -2, 1));

const getVariableBlock = new FlowGraphGetVariableBlock({
  variable: "sceneReadyLogMessage",
  initialValue: "Hello Scene",
});

var log = new FlowGraphConsoleLogBlock();
sceneReady.done.connectTo(log.in);
log.message.connectTo(getVariableBlock.value);

// start an interpolation animation
const interpolationBlock = new FlowGraphInterpolationBlock({
  animationType: Constants.ANIMATIONTYPE_VECTOR3,
  duration: 1,
  propertyName: "position",
});

const endPosition = new FlowGraphGetVariableBlock({
  variable: "endPosition",
});

interpolationBlock.keyFrames[0].value.connectTo(endPosition.value);

const asset = new FlowGraphGetVariableBlock({
  variable: "assetToWorkOn",
});

const playAnimation = new FlowGraphPlayAnimationBlock();

playAnimation.object.connectTo(asset.value);
playAnimation.animation.connectTo(interpolationBlock.animation);

sceneReady.done.connectTo(playAnimation.in);

coord.start();
```

<Playground id="#FQWPBI#11" title="Flow Graph basic example 4" snapshot="refs/pull/16201/merge"/>


## The Babylon.js Flow Graph System

The [Flow Graph](/features/featuresDeepDive/flowGraph/flowGraphBasicConcepts) system is a powerful tool for creating interactive scenes in Babylon.js. It allows developers to create complex interactions and behaviors without writing extensive code, making it accessible to both programmers and non-programmers alike.
The Flow Graph system is designed to be intuitive and user-friendly, with a visual interface that allows users to create and manipulate blocks representing different actions and events. This makes it easy to create complex interactions by simply connecting blocks together.
The Flow Graph system is particularly useful for creating interactive experiences in games, simulations, and other applications where user interaction is a key component. It allows developers to create dynamic and responsive environments that can adapt to user input in real-time.

A flow graph becomes much easier to author when it has a corresponding visual editor. Babylon.js now includes a dedicated [Flow Graph Editor](/toolsAndResources/flowGraphEditor) that lets you create, test, validate, and debug graphs visually.

Under the hood, the flow graph is used when a glTF asset with the ratified `KHR_interactivity` extension is loaded. Each valid behavior graph is converted to a Babylon Flow Graph, and the selected graph runs when the user interacts with the scene. See [Loading KHR_interactivity Assets](/features/featuresDeepDive/importers/glTF/khrInteractivity) for validation rules, loader options, inspection APIs, and editor import behavior.

If you want to understand the runtime model, continue with the sections below. If you want to build graphs through a visual tool, start with the [Flow Graph Editor documentation](/toolsAndResources/flowGraphEditor).


# Exporting to 3MF

## What is 3MF?

3MF (3D Manufacturing Format) is an open, XML-based file format designed for additive manufacturing and 3D printing workflows. Unlike formats such as STL, 3MF is a versatile container that carries geometry, units, materials, colors, metadata, and structural relationships in a single zip-based package (OPC — Open Packaging Conventions). It is natively supported by most modern slicers, CAD tools, and manufacturing pipelines.

Because 3MF is designed to faithfully represent manufacturing intent, a Babylon.js scene may need to be prepared before exporting. For example, you may want to apply world transforms, merge or split meshes by material, assign meaningful names, set a specific unit, or strip rendering-only data that has no manufacturing meaning. The exporter works directly on the meshes you pass to it, so you remain in full control of what goes into the file.

---

## Installation and prerequisites

The serializer relies on [fflate](https://github.com/101arrowz/fflate) for zip compression. By default it loads fflate lazily from a CDN:

```typescript
// Override the CDN URL before creating any serializer instance (optional)
import { ThreeMfSerializerGlobalConfiguration } from "babylonjs-serializers";
ThreeMfSerializerGlobalConfiguration.FFLATEUrl = "https://cdn.example.com/fflate.js";
```

If fflate is already present on `globalThis.fflate` (bundled by your application), the dynamic load is skipped automatically.

---

## Basic usage

### Serialize to a memory buffer

The simplest way to export one or more meshes is `ThreeMf.SerializeToMemoryAsync`. It buffers the entire 3MF archive into a `Uint8Array` that you can then save or upload.

```typescript
import { ThreeMfSerializer, ThreeMf } from "babylonjs-serializers";

const serializer = new ThreeMfSerializer();

const buffer = await ThreeMf.SerializeToMemoryAsync(serializer, mesh1, mesh2);

if (buffer) {
    // Save as a file in the browser
    const blob = new Blob([buffer], { type: "application/octet-stream" });
    const url = URL.createObjectURL(blob);
    const a = document.createElement("a");
    a.href = url;
    a.download = "model.3mf";
    a.click();
    URL.revokeObjectURL(url);
}
```

### Stream to a custom sink

For large scenes or environments where you want to avoid buffering the entire archive in memory (e.g., writing directly to a Node.js file stream), use `serializeAsync` with a sink callback:

```typescript
import { ThreeMfSerializer } from "babylonjs-serializers";
import { createWriteStream } from "fs";

const serializer = new ThreeMfSerializer({ unit: ST_Unit.millimeter });
const chunks: Uint8Array[] = [];

await serializer.serializeAsync(
    (err, chunk, final) => {
        // append chunk to your stream / buffer
        chunks.push(chunk);
    },
    mesh1,
    mesh2
);
```

---

## Serializer options

Options are passed as an object to the `ThreeMfSerializer` constructor. All fields are optional.

| Option | Type | Default | Description |
|---|---|---|---|
| `unit` | `ST_Unit` | `ST_Unit.meter` | Unit used for all coordinates in the exported file. Must match the scale of your scene. |
| `exportInstances` | `boolean` | `false` | When `true`, `InstancedMesh` objects are exported as additional build items that reference the shared geometry of their source mesh — no geometry duplication. When `false`, instances are silently ignored. |
| `metadata` | `Record<string, string>` | `undefined` | Arbitrary key/value pairs written as model-level metadata. Standard keys include `Title`, `Designer`, `Description`, `Copyright`, `LicenseTerms`, `CreationDate`, `ModificationDate`, and `Application`. |

### Units

The `ST_Unit` enum provides the full set of units supported by the 3MF specification:

```typescript
import { ST_Unit } from "babylonjs-serializers";

// Available values
ST_Unit.micron
ST_Unit.millimeter  // most common for desktop 3D printing
ST_Unit.centimeter
ST_Unit.inch
ST_Unit.foot
ST_Unit.meter       // default for ThreeMfSerializer
```

> **Important:** The unit does not rescale coordinates. It declares to the consuming application how to interpret the raw numbers in the file. Make sure the unit you choose matches the actual scale of your mesh vertices.

### Example: millimeter export with metadata

```typescript
import { ThreeMfSerializer, ST_Unit, ThreeMf } from "babylonjs-serializers";

const serializer = new ThreeMfSerializer({
    unit: ST_Unit.millimeter,
    metadata: {
        Title: "My Part",
        Designer: "Jane Doe",
        Description: "Bracket assembly for prototype v2",
        CreationDate: new Date().toISOString().slice(0, 10),
    },
});

const buffer = await ThreeMf.SerializeToMemoryAsync(serializer, bracket);
```

### Example: exporting instances

When a scene contains many copies of the same object created with `Mesh.createInstance()`, enabling `exportInstances` avoids duplicating geometry for every copy:

```typescript
const serializer = new ThreeMfSerializer({ exportInstances: true });

// sourceMesh is exported once as a resource object.
// each InstancedMesh becomes a separate build item pointing to that object.
const buffer = await ThreeMf.SerializeToMemoryAsync(serializer, sourceMesh, ...sourceMesh.instances);
```

---

## Preparing your scene for export

Because 3MF targets manufacturing workflows, some aspects of a typical Babylon.js scene may need attention before exporting:

- **Apply transforms:** The serializer uses each mesh's current world matrix. If you want a "baked" export with no runtime transform, call `mesh.bakeCurrentTransformIntoVertices()` beforehand.
- **Units and scale:** If your scene is in centimeters but the slicer expects millimeters, either rescale the meshes or choose `ST_Unit.centimeter` so the consumer can convert correctly.
- **Submeshes and materials:** Each Babylon.js `SubMesh` is exported as its own 3MF object resource. This allows downstream tools to assign per-object colors or materials. If you want a single object per mesh, merge submeshes before exporting.
- **Names:** Object names in the exported file come from `mesh.name`. Give meshes meaningful names to make the 3MF easier to work with in slicer or CAD software.
- **Non-manifold geometry:** 3MF consumers typically require watertight (manifold) geometry for printing. Validate and repair meshes as needed before export.

---

## Advanced: using the builders directly

The serializer internally uses a set of fluent builder classes. You can use these directly if you need to construct a 3MF file from raw geometry data (independent of any Babylon.js mesh):

```typescript
import {
    ThreeMfModelBuilder,
    ThreeMfMeshBuilder,
    ThreeMfMaterialBuilder,
    ThreeMfDocumentBuilder,
    ST_Unit,
} from "babylonjs-serializers";

// 1. Define a material group
const material = new ThreeMfMaterialBuilder(1)
    .withColor("Red", { r: 0.8, g: 0.1, b: 0.1 })
    .withColor("Blue", { r: 0.1, g: 0.1, b: 0.8 })
    .build();

// 2. Define a mesh resource (positions: flat x,y,z array; indices: flat i,j,k array)
const mesh = new ThreeMfMeshBuilder(2)
    .withName("Cube")
    .withData({ positions: [...], indices: [...] })
    .withMaterial(1, 0) // reference material group id=1, entry index 0
    .build();

// 3. Assemble the model
const model = new ThreeMfModelBuilder()
    .withUnit(ST_Unit.millimeter)
    .withMetaData("Title", "My Model")
    .withMaterial(material)
    .withMesh(mesh)
    .withBuild(2) // add mesh id=2 to the build list
    .build();

// 4. Wrap in an OPC document
const document = new ThreeMfDocumentBuilder()
    .withModel(model)
    .build();
```

### Builder reference

| Builder | Purpose |
|---|---|
| `ThreeMfModelBuilder` | Assembles the root 3MF model: unit, metadata, resources (meshes + materials), and build items. |
| `ThreeMfMeshBuilder` | Creates a mesh resource object from a flat positions array and a flat indices array. Accepts an optional vertex/triangle post-process handler. |
| `ThreeMfMaterialBuilder` | Creates a `basematerials` resource group. Colors are expressed as linear RGB and converted to sRGB hex automatically. |
| `ThreeMfComponentsBuilder` | Creates a composite object made of references to other resource objects with per-component transforms. |
| `ThreeMfDocumentBuilder` | Wraps a model into a full OPC document (content types + relationships + model part). |

### `ThreeMfMeshBuilder` post-process handlers

If you need to transform individual vertices or triangles during export (e.g., to remap coordinates or inject per-triangle property references), you can attach handlers:

```typescript
const mesh = new ThreeMfMeshBuilder(id)
    .withData(data)
    .withPostProcessHandlers(
        (vertex) => {
            // transform or annotate the vertex
            return vertex;
        },
        (triangle) => {
            // assign per-triangle material references
            triangle.pid = materialGroupId;
            triangle.p1 = 0;
            return triangle;
        }
    )
    .build();
```


Flow Graph

The Babylon.js Flow Graph System

Coming next

Flow Graph Blocks

A detailed overview of the Flow Graph blocks.

Flow Graph Basic Concepts and Getting Started

Learn all about the Babylon.js Flow Graph system.

Flow Graph Examples and Write Your Own

Learn how to write your own flow graph.

Flow Graph Advanced Usage

Learn about advanced concepts of the Flow Graph system.