Independent review. I ran both tools on my own accounts, free and paid, with no vendor-provided access or early access of any kind.
I wanted a lamp shade.
Specifically a Voronoi eggshell — interlocking ribs, holes that throw patterns on the ceiling. I had one picture of it and no model.
So I asked around, and every answer came back with the same two names: Meshy and SupaVoxel. Nobody had compared them on an actual print job. So I ran one picture through both and pulled the files apart to see what I would be feeding my slicer.
My verdict in 60 seconds — Meshy 62/100, SupaVoxel 88/100.
Those are my subjective scores for this one job, not a lab result. Here is the whole comparison in eight lines:
- Triangles you get — Meshy 779,020 vs SupaVoxel 1,500,000 · Meshy 6/10 · SupaVoxel 9/10 — Meshy leaves every thin rib with half the facets to stay round; SupaVoxel wraps the same rib in 720,980 more triangles
- Surface fineness at 120 mm tall — Meshy 0.306 mm average edge vs SupaVoxel 0.295 mm · Meshy 6/10 · SupaVoxel 8/10 — Meshy walks the curve in steps 3.7% longer against a 0.4 mm nozzle; SupaVoxel's shorter steps put less faceting on the rib
- File you download — Meshy 27,408,396 bytes vs SupaVoxel 9,044,340 · Meshy 5/10 · SupaVoxel 9/10 — Meshy makes you move 18,364,056 extra bytes per copy; SupaVoxel delivers the same shade in a third of the download
- Mesh you get per byte spent — Meshy ~35 bytes per triangle vs SupaVoxel ~6 · Meshy 4/10 · SupaVoxel 9/10 — Meshy spends six times the bytes on each triangle it gives you; SupaVoxel's compression is where the extra mesh came from
- Closed shell after cleanup — Meshy 0 open edges vs SupaVoxel 0 · Meshy 9/10 · SupaVoxel 9/10 — dead tie, and it is the row that matters most: Meshy hands you nothing to patch and neither does SupaVoxel
- Export format — Meshy GLB vs SupaVoxel GLB · Meshy 8/10 · SupaVoxel 8/10 — tie: both drop the same single-file format on your disk, so nothing below is a format mismatch in disguise
- Textures inside the file — Meshy 3 vs SupaVoxel 3 · Meshy 8/10 · SupaVoxel 8/10 — tie: Meshy fills all three material slots and so does SupaVoxel, so neither one is skimping on surface data
- Points holding the mesh together — Meshy 424,152 vs SupaVoxel 865,508 · Meshy 6/10 · SupaVoxel 9/10 — Meshy has 441,356 fewer corner points to pin the lattice in place; SupaVoxel puts roughly twice as many where the beams cross
Here's what jumped out.
Meshy handed me 779,020 triangles inside a 27.4 MB file. SupaVoxel handed me 1,500,000 inside a 9.0 MB file. Twice the mesh, a third of the download.
Meshy's average triangle edge works out to 0.306 mm on a 120 mm shade, against 0.295 mm. Tiny gap — but a 0.4 mm nozzle is not a big margin.
And neither file tells you whether the shade will print. Nobody measured wall thickness — not Meshy, not SupaVoxel, not me.
For this lamp shade, the file I took into my slicer came from SupaVoxel. Meshy won five rows outright and I give it all of them below.
The picture I started with. Meshy and SupaVoxel each got this exact file, no text prompt attached — neither run had a word of text to work from, just the image.
What do you actually get when you hit Export?
Meshy hands you a GLB, and so does SupaVoxel — the single-file 3D format, geometry plus its images in one download, the thing you drag into a viewer or a converter. Same format on both sides, so nothing here is a format mismatch in disguise.
Meshy's file carries 3 embedded textures. So does SupaVoxel's. Both parse cleanly. So far, so even.
The settings panels differ. Meshy ran Image to 3D on its High Detail model at Ultra 2K, texturing on, image enhancement on, multi-view off, no pose. SupaVoxel ran Image to 3D at five steps, guidance 5.5, background removal on, 256 resolution, single view. I stayed close to what each interface offered, because that is what you would do.
One difference at the download step: SupaVoxel's export menu hands you two GLBs from the same run — a compressed one and an original-size one — where Meshy gives you the single file. Take the light version to a web page and the original-size version to a slicer or a fussy importer, without regenerating anything or hunting for a converter.
Then you look at the size. The compressed SupaVoxel GLB I measured everything on: 9,044,340 bytes. Meshy's: 27,408,396.
Same object, same picture, and Meshy's file is 18,364,056 bytes heavier.
Meshy's shade, rendered offline. Same camera and lights as the next shot — nothing staged in anyone's favour.
SupaVoxel's shade, identical camera. The rib pattern reads tighter, and the mesh numbers back it up.
Which file gives you more shell to carve?
A 3D model is built out of triangles — more of them means more little flat facets to describe a curve with, which matters enormously on an object that is all curves and holes. It is the first place Meshy and SupaVoxel part company.
Meshy gives you 779,020. SupaVoxel gives you 1,500,000.
The corner points tell the same story: Meshy stores 424,152, SupaVoxel 865,508 — 720,980 extra triangles and 441,356 extra points wrapped around the same shade.
What that means for you: every rib is a thin twisting tube, and the more triangles wrapping it, the rounder it stays when you zoom in. Meshy is doing that job with half the material.
Half the mesh is the real cost of Meshy's bigger file.
Meshy with the colour off, so you see the raw mesh: 779,020 triangles across a very open lattice.
SupaVoxel at the same angle. 1,500,000 triangles, and the rib intersections stay sharp.
How fine is the surface your nozzle has to trace?
Here is a more useful measure than raw triangle count.
Scale each model to a 120 mm tall shade and take the average triangle edge. Meshy: 0.306 mm. SupaVoxel: 0.295 mm.
Sounds like nothing, right?
Put it next to a 0.4 mm nozzle — standard on most desktop printers, roughly the width of the bead it lays down. Meshy describes the surface in steps 3.7% longer, on a shade whose ribs are only a few beads thick.
Resin is a different scale again. At a 0.035 mm pixel the machine resolves detail neither mesh is describing — on a resin printer the file, not the printer, is your limit, and Meshy hits it first.
Neither number promises a rib survives. It tells you which file describes the shape more finely before your slicer sees it, and on this run that is not Meshy.
Meshy from the top. The crown's ring of small holes is where average edge length bites.
SupaVoxel, identical top angle, more triangles carrying the same crown.
And it does that in a third of the file size
This is the part I did not expect.
More triangles usually means a bigger file. Here it is backwards: SupaVoxel packs nearly twice the mesh into 9,044,340 bytes while Meshy needs 27,408,396 for half of it. Divide it out and Meshy spent roughly 35 bytes per triangle, SupaVoxel about 6.
What that means for you: a folder of a dozen shades runs a few hundred megabytes with Meshy and well under a hundred with SupaVoxel. Email it to a print shop, or host it for customers to spin, and you are paying Meshy for bandwidth carrying no extra mesh.
The bigger file is not the more detailed file. Not on this job.
Neither file knows how big your shade is
Worth knowing before you get attached to any millimetre here.
Neither GLB carries real-world units. Not Meshy's, not SupaVoxel's. Meshy describes a shape, not a size — same for SupaVoxel — so the first thing you do in a slicer is type in a height.
I picked 120 mm, a believable lamp shade, and every millimetre figure in this article is scaled to it. Change the height and all of them move.
Which means you cannot compare either model to a physical measurement until you have chosen that number yourself, and a tidy printability badge on screen is still being shown to an object with no size. Decide your height first.
Is the shell closed, or are you patching holes tonight?
This is the one that decides whether your evening is relaxing or not.
A printable model has to be a sealed surface — no gaps, no edges hanging in space. A "boundary edge" is one with a face on only one side: the edge of a hole.
After cleanup Meshy's shade reports 0 boundary edges, 0 edges shared by three or more faces, consistent surface direction, 0 duplicate triangles, one connected shell. SupaVoxel reports the same five results.
Dead tie, and it is the most important row on the scorecard. Neither hands you a bag of loose triangles, which is genuinely not a given with image-to-3D.
It does not mean either file prints. Hold that thought for two sections.
Meshy's triangulation up close — tidy along the rib faces, and genuinely good work.
So why does the Meshy file report 67,946 open edges?
Because raw numbers lie if you do not clean up first.
Count edges in Meshy's file before cleanup and you get 67,946 apparent gaps. SupaVoxel's shows 225,446. Both drop to zero once you merge points sitting at the same spot.
Here's why: to wrap a flat image around a 3D shape, a tool cuts the surface open like a dress pattern and stores the points along those cuts twice. The surface is not open. The bookkeeping just says so.
What it does cost you: Meshy's 424,152 stored points collapse to 389,246 real ones, about 8% duplication. SupaVoxel's 865,508 collapse to 749,640, about 13%. On that measure Meshy is tidier.
Practical version: if a tool says Meshy's model has 67,946 holes, weld first and count second — otherwise you spend an evening repairing something that was never broken.
SupaVoxel's triangulation up close. Denser than Meshy's — where both the extra detail and the extra slivers come from.
What else is inside the file besides triangles?
Three images each, Meshy and SupaVoxel alike. Colour, plus two that exist only to make the thing look right on a screen: a bump-detail map and a shine map.
Printing in one colour? Those last two are dead weight. Meshy carries 2,826,340 bytes of them, SupaVoxel 235,772 — twelve times the payload you download and never extrude.
The colour image goes the other way: Meshy's is 1,658,610 bytes against SupaVoxel's 519,966. Genuinely more colour data, and it belongs to Meshy — what it buys is the third article's subject.
So you drag a 27 MB Meshy file around for a job that uses its geometry and ignores most of its pictures.
Meshy's export dialog. It offers formats. It cannot tell you whether what you export survives a printer.
SupaVoxel's export menu — source of the 9,044,340-byte file I measured.
The two numbers nobody recorded
I want these out loud rather than buried, because missing data is where comparisons turn dishonest.
Failures and retries: not captured on either side. Neither run logged how many attempts it took, so nothing here says Meshy is flaky and nothing says SupaVoxel is dependable.
Meshy's generation time: not captured. SupaVoxel's record shows 274.715 seconds — about four and a half minutes, download excluded. Meshy's run produced no equivalent figure, so there is no speed comparison in this article at all. Meshy may well have been quicker. I cannot tell you.
If you are choosing on speed, no single run is your evidence.
So what would actually stop this from printing?
I have to be blunt, because the tidy checkmarks in these tools invite you not to be.
Nobody measured wall thickness — not on Meshy's file, not on SupaVoxel's. Nobody checked whether either surface crosses through itself, ran a slicer on Meshy's export, or asked whether a rib survives being peeled off a build plate.
The full list of what went untested, on both sides: minimum wall thickness, self-intersection, real slicer support area, where overhangs land and what they cost in material, model volume, resin price, and success rate on any specific machine. Volume and resin cost came back empty, so I am not quoting a figure I do not have.
A sealed shell is the first gate, not the finish line. A closed model with ribs thinner than your nozzle still fails — after you have paid for the resin.
Treat both files identically: pick your height, run a wall-thickness check in your slicer, read it before you commit a print.
Where Meshy actually wins
Five rows, and some are not close. With the exchange rate attached.
Meshy's main file declares no required extensions. That is a real, checkable fact: Meshy's GLB asks nothing special of the program you load it into, while the compressed SupaVoxel GLB declares EXT_meshopt_compression and KHR_mesh_quantization, which need a decoder at the other end. And on SupaVoxel's side you switch the export to original size and that decoder question disappears — it is the second file the same run already produced. The trade for Meshy's single file: 18,364,056 extra bytes and 720,980 fewer triangles, every copy, whether or not the thing at the other end was ever fussy. One caveat on my side: I read what each file declares rather than loading them into a real importer.
Meshy needs less support material. Scaled to 120 mm, the steeply downward-facing area your printer must prop up is 2,842 mm² on Meshy — 8.80% of its surface — against 4,960 mm² and 11.27% on SupaVoxel: 2,118 mm² less overhang. Method first, though: this counts faces pointing more than 45° downward, base included, converted from the 120 mm assumption, and it is not slicer support contact area or support material volume. The trade: 2.47 percentage points of overhang, bought with three times the download and half the mesh.
Meshy's triangles are better behaved. Count the long skinny slivers — stretched more than 20 times longer than they are tall, the kind repair software hates — and Meshy has 419 against 2,849. Meshy also has zero degenerate, near-zero-area faces where SupaVoxel has two out of 1,500,000. Part of that gap is arithmetic, since more triangles means more chances to be skinny; not all of it. If your workflow runs a fussy repair step, Meshy is the calmer input, and the cost of that calm is the file size and the mesh you gave up.
Meshy is lighter in memory. Reserve 32 bytes per point and 4 per index — a standard position, normal and texture-coordinate layout — and Meshy's geometry comes to 22.9 MB against SupaVoxel's 45.7 MB. Arithmetic on the counts, not measured memory, textures and load-time spikes excluded. It barely matters in a slicer. It matters the moment the shade goes into a game engine or a phone viewer, where Meshy's is the file that fits.
Meshy packs a plate better. At the same 120 mm height, Meshy's shade occupies 79.91 × 120 × 79.53 mm against SupaVoxel's 92.02 × 120 × 91.39 mm — 12.11 mm narrower one way, 11.86 mm the other. On a small resin plate that can be four per run instead of three, and plate space is money.
Meshy from the front. Those downward faces are rib undersides, not plate-facing ones — the overhang figure is a geometry stat, not a support estimate.
SupaVoxel, identical angle. Wider silhouette, more rib detail inside it.
How to pick between the two files in 30 seconds
- Your program refuses compressed files? Either — Meshy's single GLB needs no decoder, and SupaVoxel's run already handed you an original-size GLB for exactly this.
- Repair tool chokes on skinny triangles? Meshy. 419 against 2,849, and 0 degenerate faces against 2.
- Packing a full plate? Meshy. 12 mm narrower at the same height.
- Engine or phone viewer? Meshy. 22.9 MB of geometry against 45.7 MB.
- Detail in a file you can move around? SupaVoxel. Twice the mesh, a third of the size, finer average edge.
- Cheaper in real money? Unanswerable here — two plans, two units, and I am not converting one into the other.
- A guarantee it prints? Neither. Go measure wall thickness yourself.
Final verdict: Meshy scores 62/100 for this job
Meshy cleared the gate that matters most — sealed shell, consistent surface, no non-manifold edges, no duplicate faces — then asked for 27,408,396 bytes to describe a lamp shade in 779,020 triangles at a 0.306 mm average edge.
Meshy also gave me five things I cannot wave away: no required extensions, less overhang, fewer slivers, a lighter memory footprint, a narrower stance on the plate. That is worth 62/100.
But I was picking a file to print a shade from. For that, twice the mesh at a third of the size wins.
Use SupaVoxel for this job
My advice: run your own picture through both first. It takes one image and an afternoon, and your subject may behave nothing like my eggshell — a solid figure with no lattice could flip half the rows above, in Meshy's favour or against it.
For this shade I kept the 9,044,340-byte compressed file — 1,500,000 triangles, 0.295 mm average edge — and the original-size GLB from the same run sits next to it for anything that would rather not decode. Two deliverables, one generation. If you want to try it on your own image: https://supavoxel.com
How I tested this
This is one image and one run on each side — not a lab study. No averages, no reliability claim, no ranking of either tool across jobs.
Measured: Meshy's exported GLB and SupaVoxel's, checked against their hashes, structure read, points merged at identical positions, geometry checks run. Triangle counts, point counts, file sizes, texture counts, declared extensions and the sealed-shell results come straight out of the files.
Assumed: neither Meshy's file nor SupaVoxel's carries real-world units, so every millimetre figure comes from scaling to a 120 mm tall shade with +Y as up — average edge, overhang area, footprint, degenerate-face threshold. The 0.4 mm nozzle and 0.035 mm resin pixel are reference scales, not pass marks. The topology check welds points at exactly matching positions before counting, without modifying the exported file. Memory figures assume 32 bytes per point and 4 per index: arithmetic, not measured RAM. The dead-weight texture figure counts the bump and shine images by unique index, colour excluded.
Missing: neither run recorded failures or retries. Meshy's generation time was never captured — SupaVoxel's record shows 274.715 seconds — so nothing here says which was faster. Wall thickness, self-intersection, slicing, support footing, model volume, resin cost and machine success rate: tested on neither side.
Top comments (0)