Rig Bake › Guides › Make a text-to-3D model real-time ready

Make a text-to-3D model real-time ready

Meshy, Tripo, Rodin and Luma hand you a few hundred thousand triangles for a prop that needs a few thousand. Here is how to cut it without losing the silhouette or the textures.

Open Rig Bake — free, in your browser

No sign-up. No upload — models stay on your machine. Works in any WebGL 2 browser.

Every text-to-3D generator has the same blind spot: it does not know which parts of your shape matter, so it spends triangles evenly across the surface. The result is a prop described by 200,000–500,000 triangles that a few thousand would have covered — visually fine in the generator's preview, and immediately a problem the moment you put a dozen of them in a scene.

The fix is decimation, not remodelling, and it does not require Blender. What follows takes about two minutes in a browser tab, and the model keeps its UVs, its textures and its rig.

How to do it

Find out what you are actually working with. Drop the .glb, .gltf or .fbx into the reduce polygons page. It reports the triangle count before it changes anything. If the number is six figures and the asset is a prop, everything below applies.
Decide a target count, not a percentage. Work out what the asset needs to be: 200–1,500 triangles for a background prop, 1,500–8,000 for something held near the camera, 5,000–15,000 for a character on mobile or a headset, 20,000–60,000 for a desktop character. Then convert that to a percentage of what you have — for generated models it usually lands between 3% and 15%.
Reduce once, to that number. Set the keep-fraction and run it. Do it in a single pass: decimating an already-decimated result measures error against an approximation rather than your original, so the silhouette erodes faster than going straight to the target would have. If the result is too aggressive, return to the original file and pick a different number.
Check the silhouette, not the wireframe. Look at the model from the angle the player will actually see it, at the size it will actually be. A decimated mesh looks alarming in wireframe and identical in render — the texture and the normal map carry the detail your triangles were describing.
Fix the file size separately. If the GLB is still large, the mesh was never the problem: textures are most of the bytes in a typical file. Run it through Compress GLB to resize and re-encode the maps.

Why the textures survive and the triangles do not

A quadric error decimator scores every possible edge collapse by how far it would move the surface, then takes the cheapest ones first. Flat regions disappear early; curvature and outline are expensive and survive to the end. That is why a model can lose 90% of its triangles and still read as the same object — the discarded ones were describing flatness.

The metric used here is attribute-aware, meaning UV distortion and shading normals are weighed alongside geometry. A collapse that would be cheap geometrically but would smear the texture across a seam is scored as expensive and skipped. The texture images themselves are never touched; the UV coordinates ride along on the vertices that survive.

Skin weights ride along the same way, so a rigged character comes out rigged. This matters for AI models specifically, because most generators now auto-rig — and a decimator that is not weight-aware will happily merge two vertices belonging to different bones and tear the mesh apart the first time it animates.

When decimation is the wrong tool

Decimation keeps your original topology and removes triangles from it. It does not produce clean edge flow, and it will not give you the loops around a wrist or a shoulder that good deformation needs. For a background prop, a weapon, a piece of scenery — anything that does not bend — this does not matter and decimation is the right and fastest answer.

For a hero character that has to deform well, you want new topology rather than less of the old, which is quad remesh: it rebuilds the surface as quads following the shape, re-unwraps it and re-bakes the textures onto the new layout. Slower, and the correct choice when the mesh has to animate closely.

And if the model is broken as well as heavy — exploded bind pose, inverted normals, wrong scale, floating debris — repair it before you reduce it. Model doctor reports what is wrong; decimating a broken mesh just gives you a lighter broken mesh.

The numbers on a real model

A Meshy-generated croissant shipped at 385,872 triangles and 19.3 MB. Re-unwrapped and re-baked it came down to 19,287 triangles and 4.7 MB with 98% atlas coverage, in 8.4 seconds in the browser. Straight decimation to the same triangle count is faster still — a few seconds — and keeps the original UV layout instead of building a new one.

Neither number required a desktop application, an account, or uploading the model anywhere.

Frequently asked questions

How many triangles is too many for real-time?

It depends on how many of the object are on screen at once, not on the object alone. One hero character at 60,000 triangles is fine; sixty background props at 60,000 each is not. The practical test is your target frame rate on your target hardware — but as a starting point, anything a text-to-3D generator produces for a single prop is one to two orders of magnitude above what that prop needs.

Will decimating break the rig or the animations?

No, provided the decimator carries skin weights through — this one does, and it never merges vertices bound to different bones. Animation clips are stored on the skeleton rather than the mesh, so they are unaffected by the triangle count entirely.

Should I reduce polygons before or after rigging?

Before, if you have the choice — a lighter mesh is faster to work with at every later step, and weight painting on 400,000 vertices is unpleasant. If the model arrived already rigged, as most AI-generated ones do, reducing afterwards is fine; the weights are preserved.

Do I lose the textures if I reduce the polygon count?

No. Textures are images referenced by UV coordinates, and both come through untouched. What can go wrong is the UVs distorting so the image lands in the wrong place — which is exactly what an attribute-aware error metric exists to prevent.

Is Blender better for this?

Blender's Decimate modifier is the same family of algorithm, so the output is comparable. Blender is better when the decimation is one step in a longer session you are already having in Blender. A browser tab is better when it is the only thing you need, because it takes ten seconds and no install.

Does any of this get uploaded?

No. The decimator is WebAssembly running in your own tab — the file never leaves your machine, which is also why it keeps working if your connection drops after the page has loaded.