What Size Is an AI-Generated 3D Model? Four Generators, Two Formats, Three Slicers

An image-to-3D generator returns a mesh in seconds. It does not tell you how big the thing is, and neither does the file. We sent one figurine through four generators and three slicers to see what size it actually ends up.

What we measured

One image of a keychain figurine went through four generators on 2026-09-24, with default settings: TRELLIS.2 (Microsoft), Hunyuan3D-2.1 (Tencent) and Stable Fast 3D (Stability AI) through their official Hugging Face Spaces, and Neural4D on its public free tier. The input image is itself AI generated, not a photograph. That does not change a scale reading, because the size comes from the generator rather than the image, but it would flatter a quality comparison, so we are not making one.

The author of this site works for the company that makes Neural4D. It was measured on its public free tier, from the same image, with the same script as the others, and this piece ranks nothing: none of the four gives the model a real size.

Here is where each generator put the figurine, in the file’s own units, and what that becomes once the format’s unit is applied:

Generator	Format	Longest side (file units)	Read as	Size you see
TRELLIS.2	GLB	1.0013	metres	1001 mm
Stable Fast 3D	GLB	0.9392	metres	939 mm
Hunyuan3D-2.1	GLB	1.9856	metres	1986 mm
Hunyuan3D-2.1	STL	1.9856	millimetres	1.99 mm
Neural4D	GLB	2.0000	metres	2000 mm
Neural4D	STL	2.0000	millimetres	2.0 mm

Full results, method and limitations: What size an AI-generated 3D model really is, and what three slicers turn it into. The raw output is published as JSON, produced by scripts/measure-gen-scale.py.

Three more generators are missing from the table. TripoSG’s official Space failed on every attempt that day. Meshy, Tripo and Rodin put the GLB and STL download behind a paid plan on their free tiers, so there was no file to measure without paying.

Why does every generator land on 1 or 2?

Because that is the box the model was trained in. Normalisation is the step, before training, that scales every example object to fit the same small box, so that a teacup and a car look alike to the network in size. The network never learns real sizes, so what it produces sits inside that box too.

The measurements show it plainly. TRELLIS.2’s figurine is 1.0013 units tall, centred on the origin to four decimal places. Neural4D’s is exactly 2.0000 units tall, also centred exactly. Stable Fast 3D lands at 0.94. None of those numbers depends on what the figurine is: a mug or a house from the same generator would come out the same size.

One model, two files, a thousand times apart

Hunyuan3D-2.1’s own interface exports several formats, so we took the GLB and the STL from the same generation. The vertex numbers in the two files are identical. What differs is what they mean: 1.9856 metres in the GLB, 1.9856 millimetres in the STL.

So the figurine is two metres tall if you open the GLB in Blender and two millimetres tall if you drop the STL into a slicer, and neither is wrong by the rules of its own format. Nothing in either file says which one the generator meant, because it did not mean either.

What does your slicer do with a 2 mm figurine?

This is where it gets unpredictable. A slicer that receives something 2 mm tall assumes a unit mistake and tries to correct it, and the three most common ones correct it differently.

PrusaSlicer and Bambu Studio decide the unit from volume. Read as cubic millimetres, the Hunyuan3D STL has a volume of 0.45 and the Neural4D STL 0.82. The thresholds in their source code are:

Slicer	Treated as metres below	Treated as inches below	Asks first?	Our STLs
PrusaSlicer	0.001 mm³	9 mm³	Yes	Inches: × 25.4
Bambu Studio	0.008 mm³	8 mm³	No	Inches: × 25.4

Both of our files sit between the two thresholds, so both slicers call them inches. We imported them to check. PrusaSlicer 2.9.6 showed its “seem to be defined in inches” dialog, and saying yes turned the Neural4D figurine into 50.8 mm tall. Bambu Studio 02.08.02.61 produced the same 50.8 mm with no dialog at all: the equivalent prompt is commented out in its source and the conversion goes only to the log.

Cura does something else. It does not guess a unit. If the model is more than 100 times smaller than the build volume on every axis, it scales by the largest power of ten that fits and shows a message. On a 220 × 220 × 250 mm bed that is a factor of 100, and the figurine becomes 200 mm tall. On a 180 mm cube, the size of a small printer, 180 mm is only 90 times the figurine’s 2 mm height, so the rule does not fire and it stays at 2 mm. We computed Cura’s result from its source rather than importing, because its installer needs administrator rights on our test machine.

So one file gives four answers: 2 mm, 50.8 mm, 50.8 mm without being asked, and 200 mm. The dangerous ones are the middle two. A 5 cm figurine looks exactly like what you wanted, which is why nobody questions it, and it is a size neither you nor the generator chose.

When the longest side is not the object

Scaling to a target longest side is the usual advice, and on one of our four files it would have gone wrong. About two thirds of Hunyuan3D-2.1’s surface is a thin sheet, roughly 0.015 units thick, spread across its entire generation volume below the figurine and fused into the same closed shell. The file’s longest side, 1.9856, is the width of that sheet. The figurine itself is 1.47 units tall.

Scale that file so its longest side is 50 mm and you get a 50 mm sheet with a figurine of about 37 mm standing on it. A slicer will print the sheet, too, because it is part of the one solid it was given. Our guess is that the blurred background of the input image was read as a floor, but that is a guess; the other three generators did not do it with the same image.

The fix is to look before you scale. Open the file in our STL viewer or GLB viewer: a sheet like this is obvious on sight, and the diagnostics will show you the shell count and dimensions. Whether to cut it off or regenerate is the decision in repair or rebuild.

Which way is up?

Two generators, two answers. Neural4D’s STL turns the model so that its height runs along Z, which is what slicers expect. Hunyuan3D-2.1’s STL keeps the GLB’s Y-up layout. In PrusaSlicer that file arrives lying on its back, with the sheet standing up like a wall. Neither format records an up direction, which we measured in our up axis benchmark, so the only fix is to rotate it yourself.

Can the generator set the size for you?

Some can, if you ask. Meshy’s API documents an auto_size option that uses AI vision to estimate a real-world height and resize the model to it, with the origin at the bottom. Tripo’s official SDK has an auto_size flag too. Both default to off, so a model generated with default settings has no real size, the same as everything we measured.

We have not tested whether these estimates are right. They need a paid plan to download, and an estimated height is still a guess about an object the generator only saw in one picture. Check the result against a size you know.

Setting the size yourself

1. Decide one real dimension. For a figurine, the height you want. For a part that has to fit something, the dimension that has to fit.
2. Look at the model first. Check for extra geometry and for which way is up, as above. Our pre-print checklist covers the rest in order.
3. Scale uniformly until that one dimension matches. Do not type a factor like 25.4 or 1000: there is no correct factor, because the file never held a size to convert.
4. Scale before you repair. Repair tools weld and fill using tolerances in millimetres, so the same repair on a 2 mm model and a 50 mm model does different things. We measured how much in our scale before repair benchmark.

Method

Each generation used the Space or web app defaults, with the seed fixed where the interface allowed it. All files were measured with one script, which reads raw bounds in file units, applies each format’s unit, runs each STL through the three slicers’ rules as written in their source, and looks for a thin band that holds far more surface than the rest of the mesh. The imports into PrusaSlicer 2.9.6 and Bambu Studio 02.08.02.61 were done by hand on Windows and agree with the script’s computed sizes to the hundredth of a millimetre. Every setting, Space version and observation is in the published data.

Full results, method and limitations: What size an AI-generated 3D model really is, and what three slicers turn it into. The raw output is published as JSON, produced by scripts/measure-gen-scale.py.