I ran into this problem while building a voxel editor for 3D-printing workflows. The solution was not a single optimization. It was a pipeline that treats parsing, voxelization, progress reporting, cancellation, and mesh reconstruction as separate concerns.

This article walks through that architecture and the trade-offs behind it.

The pipeline at a glance

The browser-side flow has six stages:

1. Parse an STL, OBJ, or 3MF file away from the UI thread.

2. Flatten the loaded Three.js object hierarchy into a triangle buffer.

3. Transfer that buffer to a dedicated voxel worker.

4. Mark surface voxels and fill the interior.

5. Generate an optimized surface mesh.

6. Transfer the result back and replace the displayed object.

The main thread owns the scene and the user interface. Workers own expensive geometry work. Messages between them contain typed arrays and small progress objects rather than Three.js scene objects.

That separation matters because Object3D, BufferGeometry, and materials are not directly transferable. A compact triangle soup is a much cleaner boundary.

Parse model formats outside the main thread

Model parsing is already expensive enough to cause visible stutters on larger files, especially for compressed 3MF archives. I use a model-loader worker that dynamically imports only the parser needed for the selected format:

async function ensureParser(extension) {
  if (extension === "stl") {
    return import("three/examples/jsm/loaders/STLLoader.js");
  }
  if (extension === "obj") {
    return import("three/examples/jsm/loaders/OBJLoader.js");
  }
  if (extension === "3mf") {
    return Promise.all([
      import("three/examples/jsm/loaders/3MFLoader.js"),
      import("three/examples/jsm/libs/fflate.module.js"),
    ]);
  }
  throw new Error("Unsupported model format");
}

Dynamic imports keep format-specific code out of the initial editor path. The worker parses the source, serializes the resulting object hierarchy into plain data, and transfers geometry buffers back to the main thread.

The UI receives progress events such as “opening file,” “applying materials,” and “preparing the preview.” These messages are not cosmetic. They prove that the event loop is still alive and give users a reason not to retry the same operation.

Reduce the scene to triangles

Voxelization does not need lights, materials, object names, or most scene metadata. It needs world-space triangles.

Before starting the voxel worker, the editor traverses the model, applies object transforms, and writes triangle coordinates into a Float32Array. Each triangle occupies nine consecutive values:

x0, y0, z0, x1, y1, z1, x2, y2, z2

This representation has three useful properties:

• it is independent of Three.js classes;

• it is sequential and cache-friendly;

• its underlying ArrayBuffer can be transferred without serialization overhead.

The editor keeps its source geometry and transfers a copy to the worker. That avoids detaching the only copy of the triangle buffer when postMessage transfers ownership.

const trianglesForWorker = sourceTriangles.slice();

worker.postMessage(
  {
    requestId,
    resolution,
    triangles: trianglesForWorker.buffer,
  },
  [trianglesForWorker.buffer],
);

Build a predictable cubic grid

The editor offers three grid resolutions: 32, 64, and 128. A cubic grid keeps cell dimensions identical on every axis and makes indexing straightforward:

const index = x + resolution * (y + resolution * z);

Occupancy lives in a Uint8Array(resolution ** 3). The cell size is derived from the largest model dimension, so the model retains its proportions while fitting inside the cube.

One small detail prevents several later problems: the grid includes an empty boundary around the source bounds. The implementation uses roughly one and a half cells of padding. Without that boundary, a surface lying exactly on the edge of the grid can block the exterior flood fill or cause asymmetric bounds when it intersects cells on both sides of a grid plane.

Padding is cheap compared with debugging a model that is mysteriously solid on one side and hollow on the other.

Mark the surface efficiently

A naive implementation would test every triangle against every voxel. That grows too quickly to be useful.

Instead, the worker processes one triangle at a time:

1. Reject degenerate triangles.

2. Compute the triangle's axis-aligned bounding box.

3. Convert that box to a bounded range of grid coordinates.

4. Run a triangle-versus-box intersection test only for cells in that range.

5. Mark intersecting cells as surface voxels.

The broad-phase bounding box removes most candidate cells before the more expensive intersection test. Progress is reported every fixed batch of triangles rather than after every triangle, which keeps message traffic low:

if (triangleIndex % 128 === 0) {
  postProgress("surface", triangleIndex / triangleCount);
}

In my pipeline, surface construction occupies the first 70% of the progress bar because it is usually the dominant stage. Progress percentages do not need to be academically precise, but they should reflect the work users actually wait for.

Fill the interior with an exterior flood fill

After surface marking, the grid contains a shell and unknown empty cells. The simplest robust way to classify the remaining cells is to flood-fill the exterior.

The worker enqueues every empty cell on the six boundary faces. It then performs a six-connected breadth-first traversal through empty neighbors. Visited cells are exterior; unvisited cells are enclosed by the surface and therefore belong to the solid volume.

while (head < tail) {
  const cell = queue[head++];

  visit(cell.x - 1, cell.y, cell.z);
  visit(cell.x + 1, cell.y, cell.z);
  visit(cell.x, cell.y - 1, cell.z);
  visit(cell.x, cell.y + 1, cell.z);
  visit(cell.x, cell.y, cell.z - 1);
  visit(cell.x, cell.y, cell.z + 1);
}

An Int32Array works well as a fixed-size queue. There are no object allocations per cell, and the queue can never contain more entries than the occupancy grid.

Once the traversal finishes, exterior markers return to zero and every other cell becomes occupied. This technique assumes that the marked shell is sufficiently closed at the chosen resolution. Small gaps can disappear at a coarse resolution or leak at a fine one, so resolution remains a modeling decision rather than a simple quality slider.

Reconstruct the mesh without emitting every cube

Rendering one cube per occupied voxel is convenient for a prototype but produces far too many internal and duplicate faces. Even emitting only exposed unit faces creates unnecessarily large files.

The worker uses greedy meshing instead. For each principal axis, it builds a 2D mask where an occupied cell meets an empty cell. Adjacent mask entries with the same orientation are merged into the largest possible rectangles. Each rectangle becomes one quad.

This dramatically reduces the number of faces on flat voxel regions.

There is a topology trap, however. A large greedy quad may meet several smaller perpendicular quads along one edge. Visually they appear closed, but exporting the large edge as a single segment creates T-junctions. Some STL, OBJ, and 3MF consumers interpret those junctions as an open mesh.

The implementation records every endpoint that appears on each grid line. Before triangulating a quad, it splits its boundary at all matching endpoints. Simple quads still become two triangles; boundaries with additional cuts are triangulated around a center vertex. The result keeps the compact greedy surface while making adjacent faces agree on edge segmentation.

That extra topology pass was more valuable than chasing a slightly smaller triangle count. For 3D printing, predictable downstream geometry is the real optimization target.

Return only transferable geometry

The worker returns positions, normals, and indices as typed arrays:

self.postMessage(
  {
    type: "result",
    requestId,
    positions: positions.buffer,
    normals: normals.buffer,
    indices: indices.buffer,
    filledCount,
    quadCount,
  },
  [positions.buffer, normals.buffer, indices.buffer],
);

The main thread wraps those arrays in BufferAttribute objects and creates the replacement mesh. No large geometry payload is copied between threads.

Each operation gets a request ID. The UI ignores events from stale workers, which matters when users switch objects or start another rebuild before an earlier message arrives.

Cancellation can be simple

JavaScript does not need cooperative cancellation inside every inner voxel loop if each rebuild owns a dedicated worker. The cancel action can terminate the worker, reject the pending operation, and restore the UI state.

This approach has a cost: starting another rebuild creates another worker. For occasional, user-triggered geometry operations, that cost is small and the lifecycle is easy to reason about.

An AbortSignal still connects voxelization to larger editor operations. For example, saving a project may need to rebuild stale voxel models first. Cancelling the save aborts the source download or parsing step and terminates the active voxel worker.

Preserve a recipe, not only the result

A voxel mesh is derived data. Saving only the generated triangles makes later edits difficult because the relationship to the source model is lost.

The editor therefore stores a small recipe alongside the result:

{
  algorithm: "surface-fill-v1",
  resolution: 64,
  sourcePartIndex: 0,
}

It also retains a source descriptor when the original file can be downloaded again. If a user changes the resolution, the mesh becomes stale and must be rebuilt from the source before pricing or saving.

This distinction between source, recipe, and derived mesh makes the feature behave like an editor rather than a one-way converter.

Practical lessons

The most reusable lessons from this implementation are not specific to voxels:

• Move both parsing and geometry processing away from the main thread.

• Cross worker boundaries with typed arrays, not framework objects.

• Design progress stages around actual computational cost.

• Keep cancellation semantics simple and deterministic.

• Treat exported topology as a correctness requirement.

• Save enough source information to rebuild derived geometry.

• Offer a few deliberate quality levels instead of an unbounded resolution input.

I use this pipeline in 3D Форматика Maker, where voxelization is one part of a broader set of browser tools for 3D-printing workflows. Building it reinforced a useful rule: browser-based geometry becomes much easier to manage once the UI thread is treated as a coordinator, not a compute engine.

If you want to explore the surrounding product, the available browser-based 3D editors cover several focused modeling and preparation workflows.