DEV Community: Bubu Dong

Previewing a Gaussian Splat .ply in three.js without a splat renderer

Bubu Dong — Mon, 02 Nov 2026 03:39:08 +0000

If you've trained a 3D Gaussian Splat, or exported one from a capture app, you end up with a .ply file. Open it in a normal 3D viewer and you get one of three things: an error, a cloud of grey dots, or a tangle of random triangles.

I work on a browser-based PLY viewer, and I wanted it to answer one question quickly: what is in this file? A full splat renderer is a bigger project, so the goal here was a fast preview with the right colors, the near-invisible splats left out, and the camera aimed at the subject.

The file I tested with is the bonsai scene from the Mip-NeRF 360 dataset (trained splat from the dylanebert/3dgs collection on Hugging Face). It has 1,157,141 splats in 287 MB.

1. It's a point cloud, not a mesh

A splat PLY has a vertex element and no face element. three.js's PLYLoader gives you a BufferGeometry with no index. If you pass that to a THREE.Mesh, which is what a generic viewer does, three.js treats every three consecutive vertices as a triangle. That's where the random-triangle tangle comes from.

The fix is to check for an index and use THREE.Points when there isn't one:

if (!geometry.getIndex()) {
  return new THREE.Points(geometry, new THREE.PointsMaterial({
    size: pointSize,
    sizeAttenuation: true,
    vertexColors: hasColor,
  }));
}

2. Detecting a splat from the header

The header tells you which kind of PLY you have. Here's the bonsai file (with the 45 f_rest_* lines shortened):

format binary_little_endian 1.0
element vertex 1157141
property float x
property float y
property float z
property float nx
property float ny
property float nz
property float f_dc_0
property float f_dc_1
property float f_dc_2
property float f_rest_0
...
property float f_rest_44
property float opacity
property float scale_0
property float scale_1
property float scale_2
property float rot_0
property float rot_1
property float rot_2
property float rot_3
end_header

There are no red/green/blue properties. A f_dc_0 property is a reliable sign that the file is a splat. Each splat is 62 floats, or 248 bytes. The 45 f_rest_* values make up 72.6% of the file. They hold view-dependent color, and a preview can ignore them.

3. Turning `f_dc` into a color

f_dc_0..2 are the zero-order spherical-harmonic coefficients for R, G and B. The base color is:

color = 0.5 + SH_C0 * f_dc      where SH_C0 = 0.28209479177387814

PLYLoader ignores properties it doesn't know about unless you map them to an attribute name:

const loader = new PLYLoader();
loader.setCustomPropertyNameMapping({
  shDc: ["f_dc_0", "f_dc_1", "f_dc_2"],
  splatOpacity: ["opacity"],
});
const geometry = loader.parse(buffer);

const dc = geometry.getAttribute("shDc");
const colors = new Float32Array(dc.count * 3);
const c = new THREE.Color();
const clamp = (v: number) => Math.min(1, Math.max(0, 0.5 + SH_C0 * v));
for (let i = 0; i < dc.count; i++) {
  c.setRGB(clamp(dc.getX(i)), clamp(dc.getY(i)), clamp(dc.getZ(i)), THREE.SRGBColorSpace);
  colors.set([c.r, c.g, c.b], i * 3);
}
geometry.setAttribute("color", new THREE.BufferAttribute(colors, 3));

Pass THREE.SRGBColorSpace to setRGB. The vertex color attribute is expected in linear space, and this value is a display color. If you skip the conversion, the colors come out washed out.

4. Most splats are almost invisible

This one surprised me. Opacity is stored as a logit, so the real alpha is sigmoid(opacity). Across the bonsai file:

alpha below	share of splats
0.05	21.8%
0.10	37.7%
0.25	61.9%
0.50	79.5%

A splat renderer blends all of these and the faint ones barely show. A point renderer draws every one as a solid dot, so more than a third of the points are haze that shouldn't be visible.

I drop splats below 10% alpha. The comparison happens in logit space, so there's no exp per point:

const MIN_ALPHA = 0.1;
const minLogit = Math.log(MIN_ALPHA / (1 - MIN_ALPHA)); // ≈ -2.197
for (let i = 0; i < n; i++) {
  if (opacity.getX(i) >= minLogit) keep.push(i);
}

The viewer shows how many it skipped, so nothing disappears silently.

5. Framing: aim at the subject, not at the floaters

My viewer fits the camera to the object's bounding sphere. On a trained splat, a handful of stray points far from the scene stretch that sphere. Here are the bonsai splats' distances from their median position:

percentile	distance
50th	8.99
90th	14.42
99th	18.63
max	37.81

The farthest point is twice as far out as the 99th percentile, so the scene took up a small patch in the middle of the view. For point clouds I now sample up to 20k points, take the per-axis median as the center and the 95th-percentile distance as the radius:

const center = new THREE.Vector3(median(xs), median(ys), median(zs));
const dist = xs.map((x, i) =>
  Math.hypot(x - center.x, ys[i] - center.y, zs[i] - center.z)
).sort((a, b) => a - b);
const radius = dist[Math.floor(dist.length * 0.95)];

I use this sphere only when it's much tighter than the exact bounds. A clean scan with no outliers keeps the exact fit, so nothing gets clipped.

6. Point size

One fixed size doesn't work, because scenes range from millimetres to hundreds of metres. I scale it from the bounding-box diagonal and the point count, then clamp it:

const pointSize = Math.min(diag / 50,
  Math.max(diag / 2000, (diag / Math.sqrt(count)) * 1.5));

Denser clouds get smaller points, and the clamps stop it going to extremes.

What this is not

A real splat renderer draws each splat as an oriented, stretched ellipse (scale_*, rot_*), sorts the splats by depth, alpha-blends them, and evaluates the view-dependent color (f_rest_*). None of that happens here. The goal is a quick check of what a file contains, the kind of check you'd do before loading it into a real splat tool. The viewer says this on screen too.

Two more limits:

The viewer takes files up to 200 MB. The full bonsai file is 287 MB, so for the screenshots I kept every second splat (578,571 of them).
A splat has no surface, so it can't be exported as STL or 3MF. The viewer refuses with a clear message instead of writing an empty file. If you need a mesh, reconstruct a surface first (for example, Poisson reconstruction in MeshLab or CloudCompare).

Try it

flip3d.app/ply-viewer opens splat PLYs, scanner point clouds and colored meshes. It also shows the file's header fields, so you can see exactly which properties are in the file. Everything runs in your browser and the file isn't uploaded. The code is in the repo: lib/converters/parse.ts (reading and filtering) and components/MeshViewer.tsx (framing).

If you have a PLY that shows up wrong, send it my way in the comments.

How Bambu Studio stores multi-color painting in a 3MF — decoding paint_color in the browser

Bubu Dong — Thu, 15 Oct 2026 08:01:00 +0000

Download a multi-color model from MakerWorld, open the .3mf in almost any viewer other than Bambu Studio, and you get a single gray (or single-color) blob. The colors are in the file, though. They just aren't stored the way most 3D software expects.

I recently added support for this to a browser-based 3MF viewer I work on, and the format turned out to be compact and pretty neat. Here's how it works.

Background: in an earlier post I covered why PrusaSlicer can't open Bambu 3MFs at all: the geometry is split across 3D/Objects/*.model files using the 3MF production extension. This post assumes you've already flattened that and have the triangles.

Two kinds of color in a Bambu 3MF

1. Per-object filament. Each object (or part) is assigned to a filament slot. That lives in Metadata/model_settings.config:

<object id="2">
  <metadata key="name" value="Cat"/>
  <metadata key="extruder" value="3"/>
</object>

The actual colors are in Metadata/project_settings.config, which is JSON despite the extension:

"filament_colour": ["#202020", "#C12E1F", "#FF6A13", ...],
"filament_type":   ["PLA", "PLA", "PLA", ...]

So extruder = 3 means "use filament_colour[2]". That alone gets you a correctly tinted model when each color is a separate part.

2. Per-triangle painting. When someone uses the paint brush in Bambu Studio (or Orca), the color goes on the triangles themselves, as an extra attribute:

<triangle v1="10" v2="11" v3="12" paint_color="4"/>
<triangle v1="12" v2="13" v3="10" paint_color="8"/>
<triangle v1="14" v2="15" v3="16" paint_color="4C"/>
<triangle v1="16" v2="17" v3="18"/>

A triangle without the attribute uses the object's own filament. PrusaSlicer writes exactly the same encoding under a different name, slic3rpe:mmu_segmentation, because Bambu Studio forked it from PrusaSlicer's TriangleSelector.

Decoding the hex string

It isn't a color, and it isn't a plain slot number either. It's a serialized subdivision tree. When you paint across part of a triangle, the slicer splits that triangle into smaller ones and paints those. The string stores the whole tree, one hex digit (nibble) per node.

Two things are unusual:

You read the string from the last character backwards.
Each nibble packs two fields: the low 2 bits are the number of split sides, the high 2 bits are the color (for leaves).

nibble = 0b SS CC         (read right to left through the string)
        CC = low 2 bits  = split sides
        SS = high 2 bits = state, when this node is a leaf

split == 0  → leaf
   SS < 3   → state = SS
   SS == 3  → state = (next nibble) + 3     // escape for slots ≥ 3
split > 0   → node has split + 1 children; decode them next, recursively

State 0 means "unpainted, use the object's filament". State n means filament slot n.

Some real values from a MakerWorld model:

`paint_color`	read as	slot
`4`	`0100`: leaf, SS=1	1
`8`	`1000`: leaf, SS=2	2
`0C`	`C`=`1100`: leaf, SS=3, escape → next nibble `0` + 3	3
`4C`	escape → `4` + 3	7
`44043`	`3`: split into 4 children → `4`,`0`,`4`,`4`	mixed: 1,0,1,1

In TypeScript:

export function decodePaintState(hex: string): number {
  let pos = hex.length - 1;
  const next = () => (pos < 0 ? 0 : parseInt(hex[pos--], 16) || 0);
  const weight = new Map<number, number>();

  const visit = (w: number, depth: number) => {
    const code = next();
    const split = code & 0b11;
    if (split === 0 || depth > 16) {
      const state = (code & 0b1100) === 0b1100 ? next() + 3 : code >> 2;
      weight.set(state, (weight.get(state) ?? 0) + w);
      return;
    }
    for (let i = 0; i < split + 1; i++) visit(w / (split + 1), depth + 1);
  };

  visit(1, 0);
  // Dominant color wins
  let best = 0, bestW = -1;
  for (const [s, w] of weight) if (w > bestW) { best = s; bestW = w; }
  return best;
}

The simplification I made (and why)

A faithful renderer would rebuild the subdivided triangles and color each one. For a viewer I didn't need that. I give each original triangle the color of whichever leaf state covers most of it, weighting children equally at each split level. It's approximate, but:

On the model I tested (221,124 triangles, 7 filaments) only a small share of triangles are split at all; most are single leaves like 4 or 8.
Decoding the whole file takes about 60 ms in the browser.
Visually you lose only the sub-triangle detail along color borders, so a border can look slightly jagged.

Wiring it into three.js

ThreeMFLoader drops unknown attributes, so I scan the XML myself with a regex pass (fast enough at this size), collect a Uint8Array of states per object, and then match each painted object to the mesh the loader produced:

Match by triangle count plus the first vertex position (the loader keeps vertex order).
Convert the geometry to non-indexed so each triangle owns its 3 vertices.
Write a color attribute: state 0 → object filament, state n → filament_colour[n-1].
Use a white material with vertexColors: true.

One gotcha: three.js expects the color attribute in linear space, but filament colors are sRGB hex. new THREE.Color("#C12E1F") does the conversion for you (color management is on by default since r152). If you parse the hex bytes yourself and divide by 255, you skip that step and the colors come out washed out.

Try it

The viewer is at flip3d.app/3mf-viewer. Drop a Bambu or PrusaSlicer 3MF on it and you get the painted colors, plates, filament list and the slicer's own thumbnail. It runs entirely in your browser, so the file never gets uploaded. The decoder is in the repo at lib/converters/3mf-paint.ts.

If you have a 3MF that renders wrong, I'd like to see it. Leave a comment.

Why PrusaSlicer can't open your Bambu 3MF — and how I flattened the 3MF production extension in the browser

Bubu Dong — Wed, 27 May 2026 07:05:22 +0000

You find a great model on MakerWorld, download the .3mf, open PrusaSlicer to tweak it... and PrusaSlicer just won't load it. No mesh, or an error, or an empty plate. The file isn't corrupt — Bambu Studio opens it fine. So what's going on?

I went down this rabbit hole after a real bug report on a PrusaSlicer GitHub issue, fixed it, and the fix runs entirely in the browser. Here's the anatomy of the problem and how the flattening works.

A 3MF is just a zip

.3mf is a zip archive. Rename one to .zip, unzip it, and a simple one looks like:

3D/3dmodel.model        ← the geometry (XML)
[Content_Types].xml
_rels/.rels
Metadata/...            ← thumbnails, slicer settings

3dmodel.model holds <vertices> and <triangles> inside <resources>, and a <build> block that places those objects on the plate. Any slicer that speaks vanilla 3MF reads this and you're done.

Bambu uses the "production extension"

Open a Bambu Studio 3MF and the root model looks very different:

<model requiredextensions="p" xmlns:p="http://schemas.microsoft.com/3dmanufacturing/production/2015/06" ...>
  <resources>
    <object id="1" p:UUID="...">
      <components>
        <component p:path="/3D/Objects/object_1.model" objectid="1" p:UUID="..."/>
        <component p:path="/3D/Objects/object_2.model" objectid="1" p:UUID="..."/>
        ...
      </components>
    </object>
  </resources>
  <build>...</build>
</model>

Notice: the root model has no geometry of its own. It declares requiredextensions="p" (the 3MF production extension) and points at a pile of external part files:

3D/3dmodel.model               ← no meshes, just <component p:path=...> references
3D/Objects/object_1.model      ← actual <vertices>/<triangles>
3D/Objects/object_2.model
... (one real file had 25 of these)

The production extension exists to split big assemblies across files and stream them. Bambu Studio leans on it heavily. The catch: PrusaSlicer doesn't implement the production extension. It sees requiredextensions="p", sees a root model with no geometry, and gives up. That's the whole bug.

The fix: flatten it back to vanilla 3MF

The goal is to produce a single self-contained 3dmodel.model with all geometry inlined, no p: namespace, no external parts — the boring kind of 3MF every slicer reads. Sounds simple; the fiddly part is the ID namespaces.

Each part file has its own local object id space. A <component objectid="1"> inside the root refers to id 1 in the file named by p:path, not id 1 in the root. So you can't just concatenate — you have to remap.

The flattening steps:

Assign globally-unique object ids across every .model file in the archive.
Inline external meshes in dependency order — topological sort so leaf meshes come before the assemblies that reference them.
Rewrite every reference: each p:path + objectid pair, same-file <component> references, and the <build> item objectids, all repointed to the new global ids.
Strip the extension: drop requiredextensions, the production (p) namespace, and Bambu's vendor namespace.
Emit a clean container: a minimal [Content_Types].xml and _rels/.rels (this also fixes dangling thumbnail relationships).

Why I did it with string ops, not a DOM parser

The transform only touches structural tags — <object>, <component>, <build>, the namespace declarations. It never needs to read or rewrite the <vertex> / <triangle> bodies, which are the huge part.

So instead of pulling in a DOM/XML parser (heavy, and browser/Node behave differently), it's careful string manipulation over the structural elements. Two payoffs:

It runs identically in Node and the browser, so I could validate the exact same code against a real file on the command line.
It's fast and memory-light even on multi-megabyte files.

Did it actually work?

The bug report came with a real 6.3 MB file from MakerWorld — 25 external object models. After flattening:

151,317 vertices in → 151,317 out
302,542 triangles in → 302,542 out
all 25 external files merged into one root model
every reference resolved, no forward references, XML well-formed
zero production-extension residue

Then the actual test: the flattened file opens in PrusaSlicer. Same geometry, now as a vanilla 3MF.

Try it / steal it

I put this in a free, browser-only tool — drop a Bambu .3mf, get a Prusa-friendly .3mf back, nothing uploaded: flip3d.app/tools/bambu-3mf-to-prusa. It's part of Flip3D, a set of 3D file tools that all run client-side.

Update: the same flattener now powers a free 3MF viewer — drop any Bambu Studio, Orca or PrusaSlicer .3mf to see the whole project with each object in its filament color, plus the plates, printer and slicer thumbnail. Still 100% in the browser, nothing uploaded.

Follow-up: How Bambu Studio stores multi-color painting in a 3MF: decoding the per-triangle paint_color data so painted models show their real colors.

It's open source if you want to read the flattener or file an issue: github.com/suyfdong/flip3d.

If you've hit the "PrusaSlicer won't open my Bambu file" wall, that's why — and now you know exactly what's happening under the zip.

I built free loan payoff calculators to help people save on interest

Bubu Dong — Fri, 13 Feb 2026 02:45:09 +0000

I recently shipped a side project: PayoffCalculators.org — a set of free online loan payoff calculators.

Why I built this

Most mortgage calculators only show you the monthly payment. They don't answer the real question: how much can I save by paying extra?

I wanted a simple tool where you plug in your loan details, add an extra monthly payment, and instantly see:

How many months you cut off your loan
How much interest you save
A full amortization schedule

What's included

Tech stack

Next.js + Tailwind CSS, deployed on Cloudflare Workers. The calculation formulas are open source:
loan-payoff-formulas.

No signup, no ads, no tracking. Just math.

Would love any feedback!

DEV Community: Bubu Dong

Previewing a Gaussian Splat .ply in three.js without a splat renderer

1. It's a point cloud, not a mesh

2. Detecting a splat from the header

3. Turning f_dc into a color

4. Most splats are almost invisible

5. Framing: aim at the subject, not at the floaters

6. Point size

What this is not

Try it

How Bambu Studio stores multi-color painting in a 3MF — decoding paint_color in the browser

Two kinds of color in a Bambu 3MF

Decoding the hex string

The simplification I made (and why)

Wiring it into three.js

Try it

Why PrusaSlicer can't open your Bambu 3MF — and how I flattened the 3MF production extension in the browser

A 3MF is just a zip

Bambu uses the "production extension"

The fix: flatten it back to vanilla 3MF

Why I did it with string ops, not a DOM parser

Did it actually work?

Try it / steal it

I built free loan payoff calculators to help people save on interest

Why I built this

What's included

Tech stack

3. Turning `f_dc` into a color