This is an independent test. Nothing here came from vendor access: both tools were used on my own free and paid accounts.
I needed a director's chair.
Not a real one. A 3D one — a film-set prop I could drop into a virtual set and spin around on a detail page. I had one illustration of it and no time to model anything by hand.
So I asked around. Every time the question "what do you use to turn an image into a 3D model?" came up, two names came back: Meshy and SupaVoxel. Nobody could tell me which one to pick.
Fine. I ran the same illustration through Meshy, then through SupaVoxel, downloaded both files, and pulled them apart offline.
My verdict in 60 seconds — Meshy 62/100, SupaVoxel 90/100. Those are my subjective scores for this one job, not a lab result. Everything else on this page is a number I read out of the two files.
- Download size — Meshy 15.26 MB vs SupaVoxel 10.25 MB · Meshy 6/10 · SupaVoxel 9/10 — Meshy makes every visitor pull 5 MB more down the wire; SupaVoxel's file is the lighter one to serve, cache and store.
- Triangles in the file — Meshy 254,336 vs SupaVoxel 1,500,000 · Meshy 6/10 · SupaVoxel 9/10 — triangles are the little flat plates a shape is built from, and Meshy is working with about a sixth of them; SupaVoxel has the plates to bend a piece of canvas around.
- Vertices — Meshy 146,472 vs SupaVoxel 854,468 · Meshy 6/10 · SupaVoxel 9/10 — Meshy runs short of corners exactly where the fabric creases; SupaVoxel has corners to pin a fold to.
- Bytes per triangle — Meshy 60.0 vs SupaVoxel 6.8 · Meshy 4/10 · SupaVoxel 9/10 — Meshy charges the most download per unit of shape in this test; SupaVoxel delivers shape for roughly a ninth of the bytes.
- Edges across the fabric span — Meshy sparse vs SupaVoxel dense, same wireframe camera · Meshy 5/10 · SupaVoxel 9/10 — Meshy puts long slivers along straight frame pieces and starves the canvas; SupaVoxel puts its edges where the surface actually curves.
- Wait on a 12 Mbps phone line — Meshy 10.2 s vs SupaVoxel 6.8 s · Meshy 6/10 · SupaVoxel 9/10 — Meshy spends three and a half extra seconds of blank viewer per visitor; SupaVoxel gets the prop on screen sooner.
- Export options from one run — Meshy one GLB vs SupaVoxel compressed GLB plus an original-size GLB · Meshy 7/10 · SupaVoxel 9/10 — Meshy gives you one file and that's your lot; SupaVoxel's menu hands you a light one for the web and a plain one for a fussy importer without regenerating anything.
- Textures baked inside — Meshy 3 vs SupaVoxel 3 · Meshy 7/10 · SupaVoxel 7/10 — a genuine tie: identical count out of both files, so nothing separates them here and neither side gets credit for it.
This is one image and one run on each side — not a lab study. Here's what I found.
The SupaVoxel chair. That's the tool I ended up keeping for this job — supavoxel.com — and I'll show you why below.
Why the smaller file was the one with more detail
I expected this to be a trade. Smaller file, less stuff in it. That's how it usually works.
It wasn't. Not the way Meshy did it.
Meshy handed me 15,262,068 bytes. The other file was 10,245,480 bytes. Meshy's is about 49% heavier.
And then I counted what was inside. Meshy: 254,336 triangles. The other one: 1,500,000.
Meshy asked me to download half again as much file, and gave me roughly one sixth of the shape.
And with Meshy you paid those extra bytes for less model. The download section below puts real numbers on what that costs your visitors.
The Meshy chair, same camera angle, same lights, same viewer. 15.26 MB. Each file carries its own idea of which way is forward, so don't read this as a pixel-perfect overlay.
What 1,500,000 triangles actually buys you
A director's chair is a specific problem. You have an X-frame made of straight sticks, and you have two panels of canvas that sag.
Straight sticks are cheap. Sagging canvas is not. A curve needs edges to sit on, and if there aren't enough, the curve turns into a set of flat facets.
Meshy had 254,336 triangles and 146,472 corners to spend across the whole chair. That budget is fine for the frame and thin for the fabric — and the fabric is the thing everybody looks at.
Meshy's chair head-on. Everything reads at this distance. That's the honest starting point — at arm's length, both files look like a chair.
The SupaVoxel chair from exactly the same camera as the Meshy shot above. Still a chair. The difference doesn't show up until you get closer.
What 146,472 corners means when the fabric has to bend
Triangles get the headlines; vertices are what actually limits you. A vertex is a corner — a point that triangles hang off. Meshy's file has 146,472 of them. The other file has 854,468.
Here's where it bites. You drop the Meshy chair into your set, it looks great at working distance, then the shot calls for a slow push-in. Now the seat edge is forty percent of frame and Meshy hasn't got the corners to describe a curve. You can't fix that in a shader — you'd be remodelling the seat by hand, which is the job you paid a tool to avoid.
Zoom into the wireframe and you can see where the budget went
A wireframe render draws only the edges, so you can see how the model is built underneath the picture. Here's Meshy's, pulled in tight on the frame and the fabric.
Meshy's wireframe up close. Watch the long slivers running along the straight frame pieces, and how few edges cross the fabric.
The SupaVoxel wireframe from the same camera as Meshy's. More edges where the surface actually curves.
Don't count Meshy's lines. Look at where they are.
Meshy spent a lot of its triangle budget on straight pieces that didn't need them, and ran short across the canvas that did. That's a distribution problem, not a count problem, and it's the kind of thing you only find out after you've already built the shot around the model.
Does the mesh hold up with the texture switched off?
Texture hides a lot. Strip it off Meshy's chair and you're looking at raw shape.
Meshy's chair with the texture removed. This is what 254,336 triangles look like carrying a whole prop by themselves.
The same view of the SupaVoxel chair. Denser than Meshy's — and yes, that density has a cost, which I get to in a minute.
If you're going to relight this thing, or push in on it, or put it anywhere near a camera move, the untextured shape is what you're really buying from Meshy. Texture is makeup. Geometry is bone structure.
So what does 60 bytes per triangle actually mean for you?
Divide Meshy's file size by its triangle count and you get a rough price per unit of shape. Meshy: 60.0 bytes per triangle. The other file: 6.8.
Fair warning — both files bake in 3 textures, so neither number is pure geometry. More on that next.
Every megabyte Meshy adds is a megabyte you serve, cache, store and pay for — and in this run those megabytes weren't buying shape.
Three textures each, so the weight isn't coming from the paint
Before you assume Meshy's file is fat because it's carrying more image data: it isn't. I counted what's baked inside each GLB. Meshy: 3 textures. The other file: 3 textures — the count, straight out of the files, not resolutions.
That kills the kindest explanation for Meshy's extra 5 MB. Meshy is heavier while carrying the same number of maps and one sixth of the geometry. There's nowhere left for those bytes to hide.
What the wait actually looks like: phone first, then desktop
These are division, not a stopwatch. On a clean, steady 12 Mbps phone connection, Meshy's 15.26 MB is about 10.2 seconds of pure transfer against 6.8. On a clean 100 Mbps desktop line, Meshy is about 1.22 seconds against 0.82. Both assume perfect effective bandwidth — Meshy's and the other one's alike, no handshake, no decode, no cache.
So does 0.4 of a second on desktop matter? On its own, no. But the phone number is the one that decides whether somebody sees your prop at all. Ten seconds on a mobile connection is past the point where people swipe away, and every extra second there is a visitor Meshy's file cost you.
A hundred props: what your drive and your meter look like
Nobody dresses a whole production with one chair — not with Meshy, not with anything. So multiply this single run by a hundred, holding every measured number exactly where it is and assuming nothing fails.
Storage: Meshy's side lands at about 1.53 GB. The other side at about 1.02 GB. Half a gigabyte of difference for one project's worth of set dressing — and you give up no detail to get it back, because the smaller file is the denser one.
Credits: Meshy's side scales to 3,500 Meshy credits, the other to 300 SupaVoxel credits. Meshy credits and SupaVoxel credits are two different plans in two different units — that's not a price ratio and I'm not going to turn it into one.
Both are straight multiplication, not a second hundred Meshy runs — a planning estimate, nothing more.
How many clicks until you actually have the file?
Upload the picture, set the options, wait, open the download menu, pick a format, save. That's the whole Meshy loop, and the other tool's too. Both let me leave with a GLB — the single-file 3D format that packs geometry and textures into one blob, which most web viewers and engines read with no conversion step. Same format both sides, so every size comparison here is like for like.
Meshy's download options. A screenshot proves what the screen said — I still checked the real file size on disk rather than trusting the menu.
The SupaVoxel export menu at the same point in the run as Meshy's.
And the GLB options underneath it — a compressed build for the web and an original-size build for anything fussy, both off the same generation.
No drama on either side. If you were expecting Meshy to make you fight for your model, it doesn't — and neither does the other one.
Meshy showing the finished, textured result before download. This is the screen where the job flips from "generating" to "yours" — and the point where Meshy's 245.8-second clock stopped.
What happens when your importer has never heard of meshopt
This scenario decides the whole comparison for some of you, so here it is on its own.
Every GLB can declare extensions it requires — features a reader must support or it can't open the file at all. Meshy's file: empty. No required extensions.
The compressed SupaVoxel file: EXT_meshopt_compression and KHR_mesh_quantization. Meshopt compresses geometry; quantization stores coordinates in smaller number formats. Both need a decoder on the reading end.
Picture the moment. An older importer, a locked-down studio pipeline, a client's viewer you can't touch. Meshy's single file at least tries.
And this is exactly what SupaVoxel's second export is for. The same menu that produced the compressed GLB also offers an original-size GLB — no meshopt, no decoder, nothing to install. You take the light one to the web and the plain one to the fussy importer, off one generation, without hunting for a converter. Honest limit: the extension flags are measured from the files, the import outcome is inference. I loaded neither into a real importer.
The two numbers nobody captured — and why I'm telling you anyway
I can tell you what the files contain. I can't tell you how often Meshy or the other tool falls over.
Failure counts: not captured. Retry counts: not captured. For Meshy and the other side alike. I didn't record them, so I don't have them, and I won't gesture at them with "seemed reliable". I also didn't capture what either product claims on its own pages.
Because an article that quietly skips the metric it didn't measure is the one to trust least. If Meshy drops one run in five, everything above changes, and neither of us knows.
Where Meshy actually wins
I'm not going to bury this. Meshy took real points here, and in these situations Meshy is your answer.
Meshy's main file requires no extensions at all. That is a measured fact and a real point: one file, no decoder, no conditions. On the SupaVoxel side you get there by taking the original-size export from the same menu, which needs no decoder either.
The exchange rate: Meshy's single no-conditions file costs you roughly 5 MB of extra download and about five sixths of the shape. If you never want to think about which export to grab, that's a fair price.
Meshy's model is lighter once it's in memory. Estimating geometry memory from the vertex and triangle counts gives Meshy about 7.7 MB against about 45.3 MB. That is exactly what a lean triangle budget is for, and Meshy earns it.
The exchange rate: six times less memory pressure, paid for with canvas that runs out of edges. Deep background, take Meshy's. A prop the camera pushes into, don't.
And Meshy was faster. 245.8 seconds of recorded generation against 274.9. Meshy got there about 29 seconds sooner. One run each, and each tool times its own clock, so treat that as an observation rather than a speed rating.
How to pick, for a job like this
- You're putting the prop on a page and bytes matter — take the SupaVoxel file. 10.25 MB against 15.26 MB, measured.
- Your importer can't handle meshopt — Meshy's single file, or SupaVoxel's original-size export. Both are decoder-free; only one of them also gives you a light copy for the web.
- You want to know which one is cheaper — I can't tell you. One tool's ledger said 35 credits, the other said 3, and those are two different plans with two different units. I'm not turning that into a dollar comparison, and neither should you.
- You need something production-signed-off — neither, yet. One generation from one image tells you nothing about rigging, thickness or whether it survives your engine.
- You need to know whether the chair's arms would actually detach, or whether it would really fold — not answered here by either tool. A screenshot, a triangle count and a file format are not a manufacturing test, and I won't let any of the three stand in for one.
Final verdict: Meshy scores 62/100 for this job
Meshy did the job. Meshy gave me a clean GLB that opens anywhere, in under four minutes, and Meshy did it about 29 seconds faster than the alternative.
But Meshy charged me 15,262,068 bytes for 254,336 triangles — 60 bytes of download per triangle against 6.8 — and Meshy's wireframe shows exactly where that ran out: across the canvas, which is the one surface on a director's chair that anybody looks at.
62/100 is my call on this one chair, from this one run. It's not a ranking of Meshy's output in general, and I'd be lying if I claimed otherwise off a single image.
Try it on your own image before you trust either one
If your job looks like mine — a prop that has to be small on the wire and dense enough to survive a close shot — supavoxel.com is where I'd start — take the compressed GLB for the page and keep the original-size one for whatever refuses it.
But run your own picture through both before you commit. One image proves one image. Yours might have a hard edge where mine had fabric, and that changes everything.
How I tested this
One illustration of a director's chair, generated for this project with GPT Image 2. Same picture into Meshy and into SupaVoxel. No text prompt on either side. One run each.
Meshy ran its Image to 3D workflow at High Detail, Ultra 2K, texture on, multi-view off. The other side ran a full generation at 5 steps, guidance 5.5, background removal on, octree resolution 256. Matching option names don't make two tools equivalent — that's just what was set.
Every measured number above was read straight out of the two downloaded GLB files after checking their hashes. Nothing came off a marketing page.
Here is every number on this page that is arithmetic rather than measurement, with the assumption written next to it, because a derived figure without its assumption is just a rumour:
- Download seconds — file bytes × 8 ÷ bandwidth, at a clean, steady 12 Mbps and 100 Mbps. No handshake, no decode, no cache, no retries. Gives 10.17 seconds for Meshy and 6.83 for the other on mobile, 1.22 and 0.82 on desktop.
- Hundred-prop storage — this one file × 100, decimal bytes. Gives about 1.53 GB for Meshy and 1.02 GB for the other. It is a capacity estimate, not a hundred real generations.
- Hundred-prop credits — this one run's credit line × 100, assuming every run costs the same and nothing fails or retries. Gives 3,500 on one plan and 300 on the other, in two different units that do not convert.
- Geometry memory — (vertices × 32 bytes) + (triangles × 3 × 4 bytes), an illustrative layout of position, normal and UV with 32-bit indices. Gives about 7.7 MB for Meshy and 45.3 MB for the other. Not real VRAM: it excludes textures, mipmaps and load peaks.
- Bytes per triangle — file size ÷ triangle count. Gives 60.0 for Meshy and 6.8 for the other. Both files embed 3 textures, so this is not pure geometry.
The required-extension comparison is measured — it's read from each file's declared list. The consequence of that comparison, the importer scenario above, is inference. No importer was tested.
Failure counts and retry counts were not captured in this test, and neither were either product's published claims. I don't know those numbers, and I'm not going to imply that I do.
The elapsed times — Meshy's 245.796 seconds and the other's 274.886 — come from each tool's own job record, start to finish, download excluded. Each tool clocks its own window with its own stages inside it, so that pair is an observation from one run, not a same-conditions stopwatch.
All renders used the same offline viewer, resolution, lighting and camera numbers on both sides: front at yaw 0, three-quarters at 35, side at 90, back at 180, plus a top view and mesh and wireframe close-ups. Each file has its own built-in orientation, so matched numbers don't guarantee matched angles.
Top comments (0)