DEV Community: Leila Rowe

OpenArt AI Image Generator Review 2026: A Coffee Mug Scored 14 of 18

Leila Rowe — Tue, 20 Oct 2026 15:52:58 +0000

I gave OpenArt (https://openart.ai) and SupaVisual (https://supavisual.com) the same coffee-mug product-photo prompt. OpenArt was faster, and its cheaper image option cost less per picture. But my detail checklist came back 14/18 for OpenArt and 18/18 for SupaVisual. On the Free account I tested, the downloaded files also put a logo across the product.

My verdict in 60 seconds — OpenArt 60/100, SupaVisual 90/100

I would take SupaVisual’s complete, unmarked mug images over OpenArt’s faster and sometimes cheaper results for this job.

Prompt adherence — OpenArt 7/10 · SupaVisual 9/10 — the mug checklist finished 14/18 against 18/18.
Detail accuracy — OpenArt 6/10 · SupaVisual 9/10 — OpenArt’s first GPT Image 2 mug scored 4/6; SupaVisual’s first scored 6/6.
Speed — OpenArt 10/10 · SupaVisual 5/10 — GPT Image 2 took 20.8 s against 48.7 s.
Price per image — OpenArt 9/10 · SupaVisual 6/10 — GPT Image 2 costs $0.014 against $0.024 on the compared plans.
Watermark — OpenArt 2/10 · SupaVisual 9/10 — OpenArt’s logo appeared in 3/3 downloaded Free images; SupaVisual’s appeared in 0/3.
File format and size — OpenArt 8/10 · SupaVisual 8/10 — OpenArt’s first WEBP was 0.26 MB; SupaVisual’s first PNG was 2.12 MB.
Commercial rights — OpenArt 5/10 · SupaVisual 9/10 — the compared eligible plans cost $34 and $19 per month.
Credits per edit — OpenArt 3/10 · SupaVisual 9/10 — the tested Seedream 5.0 Pro edit charged 30 credits against 1.

The problems I could point to in the pictures:

The first mug had a fir- or spruce-like twig where the prompt demanded rosemary; that result scored 4/6.
OpenArt’s first two mugs appeared empty despite visible steam; both finished at 4/6.
The first image fused two of the requested three beans, and the centered logo obscured part of “MORNING”; the image still cost 5 credits.
The Nano Banana Pro image passed 6/6, but added a ghostly mug shape in the window and cost 40 credits.

For coffee-mug product images that need the requested details intact, I would use SupaVisual.

First mug results side by side: OpenArt GPT Image 2 and SupaVisual, from the same prompt.

The prompt: a coffee-shop morning product shot

I asked both products for a 16:9 commercial still. This was the prompt, unchanged:

Create a photorealistic 16:9 commercial product photo of a matte sage-green ceramic coffee mug standing on a wet black slate slab at golden hour. The mug has the word "MORNING" printed in small white serif capital letters on its side. Exactly three roasted coffee beans lie in front of the mug, a thin curl of steam rises from the mug, a sprig of fresh rosemary leans against its left side, and behind it a softly blurred window shows raindrops on the glass. Shallow depth of field, warm rim light from the right.

I checked six details in each download, from the lettering to the wet-slate reflections. OpenArt’s GPT Image 2 produced 1792×1008 WEBPs; its Nano Banana Pro produced a 1376×768 WEBP. SupaVisual’s own image model produced 1672×941 PNGs.

OpenArt’s first GPT Image 2 setup shows the filled-in mug prompt and a balance of 40 credits.

Three images side by side: the cheap run and the costly run

Both OpenArt GPT Image 2 images scored 4/6. In the second, the logo obscured the lettering, the steam lacked a clear curl, and the twig did not convincingly read as rosemary. SupaVisual’s second image scored 6/6.

Second mug comparison: OpenArt GPT Image 2 beside SupaVisual, with the same prompt and aspect ratio.

OpenArt’s Nano Banana Pro matched SupaVisual’s third image at 6/6: a picture-quality tie. But OpenArt charged 40 credits against 1, and its window contained an unrequested translucent mug shape.

Third mug comparison: OpenArt Nano Banana Pro beside SupaVisual; both passed the six-item checklist.

Details 1–3: lettering, beans, and steam

OpenArt’s first “MORNING” was recognizable but cream-colored rather than white, with part beneath the centered watermark: partial credit. Two of its three beans appeared joined, earning another partial. SupaVisual’s first mug had legible lettering and three distinct beans. Both first images passed the steam-curl check; OpenArt’s second showed steam without a clearly defined curl. For an ad still, those distinctions matter across a 6-item brief.

Close-up of the left-side twig in OpenArt’s first mug image.

Close-up of the rosemary beside SupaVisual’s first mug.

Details 4–6: rosemary, rain, and wet slate

OpenArt’s first plant looked more like fir or spruce than rosemary: a fail. Its second was ambiguous, earning partial credit; its Nano Banana Pro and all three SupaVisual images passed. Both products got the rainy window and reflective wet slate right in all three images. Those 2 background details deserve credit even though the first 2 OpenArt mugs appeared empty beneath their steam and its third added a ghostly mug shape. I kept those extra defects separate from the 6-item checklist.

OpenArt’s first mug lettering, partly covered by the mark in the downloaded image.

The tally: OpenArt 14/18, SupaVisual 18/18

At 1 point per pass and 0.5 per partial, OpenArt scored 4/6, 4/6, and 6/6. SupaVisual scored 6/6 each time. The Nano Banana Pro result shows OpenArt can meet the checklist, unlike its two cheaper GPT Image 2 results.

Checklist total — OpenArt 14/18 · SupaVisual 18/18 · SupaVisual leads by 4 points.
Best individual image — OpenArt 6/6 · SupaVisual 6/6 · tie on the checklist.
Credits for that best image — OpenArt 40 · SupaVisual 1 · OpenArt charges 40× the credits.

I tested OpenArt on Free and SupaVisual on Hobbyist. Watermark findings concern those accounts; dollar comparisons use their cheapest commercial-use plans.

SupaVisual’s third 1672×941 PNG, which passed all 6 mug-prompt checks.

The watermark sits on the product

I inspected the downloads, not just the previews. OpenArt’s logo was burned into the center of all 3 Free-account mug files, interfering with “MORNING” in the first. Cropping out the center would remove the product. SupaVisual’s 3 PNGs had no watermark, so I could inspect the lettering directly. Even OpenArt’s 6/6 Nano Banana Pro image retained the logo in its 0.12 MB WEBP. That Free-account file was not a finished mug listing image.

Center of OpenArt’s first raw mug file, showing the watermark in the image pixels.

Price per image: where OpenArt is cheaper

OpenArt has a real price win: GPT Image 2 costs $0.014 per image on Plus, against $0.024 on SupaVisual Hobbyist. SupaVisual costs 1.69× as much in that row. Plus offers 2,400 such images per month for $34; Hobbyist offers 800 for $19. Credits are not interchangeable when actions carry different charges.

GPT Image 2 image — OpenArt $0.014, 5 credits · SupaVisual $0.024, 1 credit · SupaVisual costs 1.69× as much.
Nano Banana Pro image — OpenArt $0.11, 40 credits · SupaVisual $0.024, 1 credit · OpenArt costs 4.76× as much.

That $0.014 bought 4/6 in both GPT Image 2 runs, against SupaVisual’s 6/6. OpenArt’s image that tied at 6/6 cost $0.11 instead of $0.024. The cheaper row does not settle my mug purchase.

OpenArt’s monthly pricing cards, including Plus at $34 for 12,000 credits.

Speed: I concede both OpenArt image wins

I timed Generate to the result on screen. OpenArt’s GPT Image 2 took 20.8 s against SupaVisual’s 48.7 s: OpenArt was 2.3× faster. Its Nano Banana Pro took 26.9 s, a 1.8× speed win against 48.7 s. I would not hide either advantage.

But the $0.014 GPT Image 2 outputs scored 4/6, while the 6/6 Nano Banana Pro image cost $0.11 against SupaVisual’s $0.024. At 300 mugs a month, the serial stopwatch figures are about 1.8 h for OpenArt’s GPT Image 2 and 4.1 h for SupaVisual. Speed is a reason to choose OpenArt if those detail misses are acceptable.

OpenArt’s first GPT Image 2 result after 21.3 s on the UI stopwatch.

What I downloaded, and how the flow felt

OpenArt’s GPT Image 2 downloads were 1792×1008 WEBPs at 0.26 MB and 0.22 MB; its Nano Banana Pro WEBP was 1376×768 and 0.12 MB. SupaVisual delivered 1672×941 PNGs at 2.12 MB, 2.32 MB, and 2.23 MB. On 12 Mbps 4G, the first OpenArt file’s estimated download was 0.17 s against 1.41 s for the first SupaVisual PNG: a genuine small-file advantage, though the PNG was unmarked. The visible balances moved 40 → 35 and 13 → 12 for the first mug on each side.

SupaVisual’s first mug result after 48.7 s on the UI stopwatch.

One edit explains the credit trade

Editing was a side check. With the same bottle photo and prompt, OpenArt’s Seedream 5.0 Pro charged 30 credits and took 100.8 s; SupaVisual charged 1 credit and took 70.1 s. That OpenArt edit used the credits of 6 GPT Image 2 images, but won this checklist 6/6 against 5/6 by keeping the label fine print closer.

OpenArt’s Nano Banana Pro edit was faster: 29.1 s against SupaVisual’s 62.5 s, a 2.1× win. It charged 40 credits against 1. Across both edits, OpenArt led 11.5/12 to 10/12. I would budget edits separately from the cheaper mug images.

The input bottle photo followed by OpenArt Seedream 5.0 Pro and SupaVisual edits from the same prompt.

Final verdict: OpenArt scores 60/100 for coffee-mug product images

OpenArt earns its 60 for GPT Image 2’s 2.3× speed advantage and lower $0.014 image price against $0.024. Its Nano Banana Pro image also tied SupaVisual at 6/6. But my OpenArt mugs totaled 14/18 against 18/18, and all 3 Free downloads put a logo over the subject. The 6/6 OpenArt option cost $0.11 rather than $0.014. For a finished mug still, I prefer SupaVisual’s unmarked 6/6 result at $0.024, despite its 48.7 s wait.

OpenArt’s downloaded Nano Banana Pro WEBP: a 1376×768 mug image with a 6/6 checklist score and centered logo.

Which one I would use for this job

For readable “MORNING,” exactly 3 separate beans, and rosemary, I would choose SupaVisual’s unmarked 6/6 PNG at 1 credit. I would choose OpenArt’s GPT Image 2 only when 20.8 s and $0.014 outweigh its two 4/6 results.

I would start with the exact prompt above at https://supavisual.com, then inspect the downloaded file—not just the preview—for the six details before publishing a product image.

SupaVisual’s first downloaded mug PNG: 1672×941, 2.12 MB, and 6/6 on the checklist.

Tripo AI 3D Generator Review 2026: 64.63 MB for 1.33x the Triangles

Leila Rowe — Sun, 18 Oct 2026 15:49:55 +0000

This is an independent test. Nothing here came from vendor access: both tools were used on my own free and paid accounts.

My verdict in 60 seconds — Tripo 62/100, SupaVoxel 90/100

One photograph of a seated chibi reindeer in a corduroy scarf, handed to two image-to-3D products on the same day on default settings. Tripo returned a 64,627,840-byte GLB. SupaVoxel returned 10,021,440 bytes. That is 6.45× the file for 1.33× the triangles, and the gap is not geometry — it is 5.68 MB of texture maps that nothing in a print pipeline reads, shipped as PNG and JPEG instead of WebP, on top of an uncompressed mesh. On a 12 Mbps connection Tripo's reindeer takes 43.1 seconds to arrive. SupaVoxel's takes 6.7.

Here is the scorecard for this one job: how much you download, and what it looks like when it lands.

GLB size — Tripo 2/10 (64.63 MB) · SupaVoxel 10/10 (10.02 MB) — 6.45× for the same object
Bytes per triangle — Tripo 2/10 (32.37 B) · SupaVoxel 10/10 (6.68 B) — Tripo stores each triangle in 4.8× the space
Texture bytes you cannot print — Tripo 2/10 (5.68 MB) · SupaVoxel 9/10 (0.55 MB) — 10.3×, led by a 3.44 MB PNG normal map
Texture format — Tripo 3/10 (JPEG + PNG) · SupaVoxel 10/10 (WebP) — same three 4096² maps, 7.74 MB against 1.34 MB
Download at 12 Mbps — Tripo 2/10 (43.1 s) · SupaVoxel 10/10 (6.7 s)
Geometry VRAM — Tripo 6/10 (56.9 MB) · SupaVoxel 8/10 (46.4 MB) — closest row on the card
Detail on the unseen back — Tripo 7/10 (ribbing present, crown smears) · SupaVoxel 9/10 (ribbing intact) — both invented it; one held
Panel figures match the file — Tripo 10/10 · SupaVoxel 10/10 — neither product inflates its triangle count

Part by part, what is true about the Tripo file:

Tripo's reconstruction is genuinely sharp: finer, denser ribbing than SupaVoxel's and crisper antler silhouettes in every same-camera pair below.
Tripo invented the entire back of the head — the input photo never shows it — and produced the same large structures SupaVoxel did, including a ribbed crown, a wrapped scarf and a tail bobble.
Tripo's 4096² normal map alone is 3.44 MB of PNG, which is more than a third of the entire SupaVoxel GLB.
Tripo's triangle count is nearly constant across nine cases in this batch, 1,896,372 to 1,996,779 — a fixed house budget, not fidelity scaled to the subject.

For this job — one photo, one file you have to move over a network — use SupaVoxel.

The only input: one 1,517,781 B PNG, sha256 8ba545f2…. A seated chibi reindeer, two branched antlers, two leaf ears, a corduroy scarf wound three times with the tail hanging left, fine ribbing over head, body and hind legs. The camera never sees the back of the head — everything behind the ears in this article was invented by both products.

The test, in one paragraph

One photo, two products, one day, both on shipped defaults — Tripo on Best Quality with Clean Topology off, SupaVoxel on a full model with Inference Steps 5 and Guidance Scale 5.5. Both GLBs were parsed offline; no number here was copied off a panel. Every render pair uses one lighting rig and one set of cameras, corrected for export orientation, so each pair is the same viewpoint rather than two flattering angles.

1.33× the triangles, 6.45× the bytes

Tripo ships 1,996,779 triangles and 1,028,963 vertices. SupaVoxel ships 1,499,386 and 888,016. Tripo has 33% more geometry.

Tripo's file is 545% bigger. Those two numbers cannot both be about geometry, and the rest of this article is the accounting.

Triangles — Tripo 1,996,779 · SupaVoxel 1,499,386 · 1.33×
Vertices — Tripo 1,028,963 · SupaVoxel 888,016 · 1.16×
GLB bytes — Tripo 64,627,840 · SupaVoxel 10,021,440 · 6.45×

SupaVoxel's reindeer, textured, in the hero camera. Antlers as round beams, ears as thick leaves, three raised scarf coils with the tail hanging clear, corduroy grooves over the whole body. 10.02 MB.

Tripo, same camera. Leaner, sharper, ribbing packed tighter and shallower. It is the better-looking render and I will not pretend otherwise. 64.63 MB — 6.45× the bytes for this difference.

The 64.63 MB breakdown: 5.68 MB nothing in a print pipeline reads

Split the texture payload by what a print job can actually use. Base colour is the only map that matters if you are going to paint or preview — and on a single-colour FDM print, not even that.

Tripo's base colour map is 2.06 MB. SupaVoxel's is 0.79 MB. Then there is everything else: Tripo carries 5.68 MB of normal and metallic-roughness maps, SupaVoxel carries 0.55 MB. That is 10.3×, and it is 5.68 MB that has to cross the network before it is discarded.

Base colour — Tripo 2,062,520 B · SupaVoxel 785,292 B · 2.6×
Other maps — Tripo 5,675,120 B · SupaVoxel 549,822 B · 10.3×
Largest single map — Tripo 4096² normal, 3,440,384 B PNG · SupaVoxel entire texture set 1,335,114 B
Second largest Tripo map — 4096² metallic-roughness, 2,234,736 B JPEG

Tripo's normal map on its own is a third of the whole SupaVoxel GLB. Note the second irony: Tripo already cut the ribbing into the geometry, so that 3.44 MB normal map is high-frequency detail layered on top of detail that is physically present in the mesh.

Tripo with every texture switched off. The corduroy grooves are still there, which means they are real displaced geometry rather than a normal-map fake — a genuine pass for Tripo, and also the reason the 3.44 MB PNG normal map is paying for detail the mesh already has.

SupaVoxel, same camera, textures off. Grooves present here too, and the whole texture set behind this model is 1.34 MB of WebP against Tripo's 7.74 MB of JPEG and PNG.

Three 4096² maps each, and the format decides everything

Both products ship three 4096 × 4096 texture maps. Same count, same resolution, same job. Tripo encodes them as JPEG and PNG for 7.74 MB total. SupaVoxel encodes them as WebP for 1.34 MB. That is 5.8× from a container choice, before anyone argues about quality.

Texture maps — Tripo 3 at 4096² · SupaVoxel 3 at 4096²
Encoding — Tripo JPEG + PNG · SupaVoxel WebP
Total texture bytes — Tripo 7,737,640 · SupaVoxel 1,335,114 · 5.8×
Normal map encoding — Tripo PNG (lossless, 3.44 MB) · SupaVoxel WebP

The mesh half of the gap has the same shape. The SupaVoxel GLB ships with mesh compression and vertex quantization; Tripo's does not. One honest cost of that: older toolchains cannot open a compressed GLB directly, and parsing this one for the article needed a conversion step first. If your pipeline is a decade old, that is a real friction and I am not hiding it.

Bytes per triangle: 32.37 against 6.68

Normalise the whole thing per unit of geometry and the picture is unambiguous. Tripo spends 32.37 bytes per triangle. SupaVoxel spends 6.68. For each triangle of reindeer, Tripo uses 4.8× the storage.

Bytes per triangle — Tripo 32.37 B · SupaVoxel 6.68 B · 4.8×
Extra Tripo triangles — 497,393
Extra Tripo bytes — 54,606,400

497,393 more triangles came with 54.6 MB more file. Whatever those extra bytes are carrying, it is not triangles.

SupaVoxel, front. Antlers show four tines left and five right, each a separate raised prong with air between them. Three scarf coils separate cleanly and the tail splits into strands. The corduroy reads as grooves with depth rather than surface markings.

Tripo, same camera. Four and five tines, all separate — Tripo passed the same test. The differences are thinner tines with tighter roots, ears reduced to flat shells, and body ribbing that is denser and shallower. Sharper on screen; that is what the 55 credits and the 64.63 MB bought.

Download seconds on the connection people actually have

Bytes become seconds the moment a real person waits for them. At 12 Mbps — an ordinary mobile connection — Tripo's file takes 43.1 seconds. SupaVoxel's takes 6.7. On 100 Mbps home broadband it is 5.17 seconds against 0.80.

Forty-three seconds of blank screen is not a download, it is an abandonment. And this is one object.

12 Mbps mobile — Tripo 43.1 s · SupaVoxel 6.7 s · 6.45×
100 Mbps broadband — Tripo 5.17 s · SupaVoxel 0.80 s
Batch of 100 files — Tripo 6.46 GB · SupaVoxel 1.00 GB · 5.46 GB more

The CDN bill for an online preview

Put the model on a product page and the bytes turn into an invoice. At $0.085/GB and 10,000 loads a month, Tripo's file costs $54.93 and SupaVoxel's costs $8.52 — $46.41 a month, $557 a year, for the same reindeer on the same page.

CDN per 10,000 loads — Tripo $54.93 · SupaVoxel $8.52 · 6.45×
Monthly difference — $46.41
Annual difference — about $557

Every number in this section is division: file bytes times loads times unit price. Change the traffic or the rate and the ratio holds, because the ratio is just 6.45.

Geometry VRAM: the closest row on the card

This is the one weight row where Tripo is nearly competitive. Counting vertices at 32 bytes and indices at 4, Tripo's geometry occupies about 56.9 MB of video memory and SupaVoxel's about 46.4 MB — 1.23×, a 10.5 MB difference. Textures are excluded, which flatters Tripo enormously given the 7.74 MB of maps it also has to upload.

Geometry VRAM — Tripo 56.9 MB · SupaVoxel 46.4 MB · 1.23×
Difference on a mobile GPU — 10.5 MB

On a phone, 10.5 MB matters less than 43 seconds of download. But it is the row where Tripo's 1.33× triangle lead shows up honestly, so it is on the card.

The back of the head: both invented it, one held its detail

The input photo is a front view. Everything behind the ears is a guess by both products, which makes it the most interesting comparison in the set — not "who matched the reference" but "who invented something coherent."

Both did well. Both wrapped the scarf around the back with three distinct coils. Both ran ribbing from the crown down to the collar. Both added a tail bobble with a seam. The large structures are strikingly similar and that similarity is the finding.

The difference is at detail scale. On Tripo's crown, an area to the upper left smooths into a flat panel where the ribs dissolve; on the right of that area the ribs survive but read as scratches rather than ridges. On SupaVoxel's they stay as separate rounded ridges from crown to collar across the whole area.

Scarf wrapped around the back — Tripo yes · SupaVoxel yes
Ribbing on the invented crown — Tripo partial, smears upper left · SupaVoxel intact
Tail bobble invented — Tripo yes · SupaVoxel yes

SupaVoxel from behind. Ribbing radiates from the crown and runs unbroken into the three scarf coils, then continues down the back in vertical ridges to a seamed tail bobble. None of this is in the input photo.

Tripo, same camera. Also invented, and the large structure agrees closely — scarf, ribbing, tail bobble. Tripo deserves credit for not flattening the unseen side into a bald panel, which is the usual failure here.

SupaVoxel, back of head close up. Each rib is a separate rounded ridge with depth, running crown to collar without a break, and the valleys between the three scarf coils stay open.

Tripo, same close up. The scarf coils are rounder and softer with shallower valleys, and there is a smeared bulge where the scarf meets the body. On the upper-left crown the ribbing has flattened into a smooth panel.

The pair of images I will not use as evidence

There is a wireframe close-up of each model in the source set and neither is usable. At 1.5 and 2.0 million triangles a wireframe zoom renders as a near-black blob — the higher the count, the blacker it gets, which makes Tripo's worse for reasons that have nothing to do with quality.

So the antler evidence in this series comes from tight crops of the untextured mesh renders instead. I am naming the useless images rather than quietly dropping them, because the honest version of a test includes the measurements that did not work.

Both panels told the truth

Tripo's result screen reported 1,996,779 triangles and 1,028,963 vertices. The downloaded GLB parses to exactly those figures. SupaVoxel's panel reported 1,499,386 and the file parses to 1,499,386.

Neither product inflates its own numbers. Tie, recorded as a tie.

Panel triangles vs file — Tripo 1,996,779 / 1,996,779 · SupaVoxel 1,499,386 / 1,499,386

Tripo's export panel, once the tutorial popup covering it is dismissed: File Name auto-filled, Format GLB, Texture Resolution 4k Current. Two steps from here to the 64.63 MB file.

Triangle counts are a house budget, not a fidelity dial

The tempting conclusion is that Tripo simply chose a heavier mesh and SupaVoxel a lighter one. The ten cases I ran say something more specific.

Across nine cases on the same day at the same settings, Tripo's triangle counts ran 1,896,372 to 1,996,779 — a spread of 5.2% of the mean. A chibi reaper, a minimal watch stand and a tank all came back at roughly the same count. That is a fixed budget spent regardless of subject.

SupaVoxel's ran from about 945,000 to 2,786,054 across ten cases, a 146% spread. And it goes both ways: on the tank SupaVoxel shipped 44% more triangles than Tripo did. The claim is not that SupaVoxel is leaner. It is that Tripo's number does not move — and with one run per case, that is a pattern across ten samples, not a specification I can quote.

Tripo triangle range, 9 cases — 1,896,372 to 1,996,779 · spread 5.2% of mean
SupaVoxel triangle range, 10 cases — about 945,000 to 2,786,054 · spread 146%
This case — Tripo 1,996,779 · SupaVoxel 1,499,386
Tank case — SupaVoxel 2,786,054, 44% more than Tripo

SupaVoxel from above. Antler tines fan out in different directions without touching, crown ribbing converges on a clean central ridge, and both ears read as leaves with obvious width.

Tripo, same viewpoint. Tines are separate here too. The ears, though, have narrowed to something close to a line, and there is a flattened patch of crown ribbing near the left brow that SupaVoxel's does not have.

Final verdict: Tripo scores 62, SupaVoxel scores 90

Tripo's reindeer is the better render. Sharper antlers, denser ribbing, a convincing invented back, and a result panel that reports its own numbers honestly. On a screen, at a fixed camera, Tripo wins the look.

The bill for the look is 64.63 MB against 10.02 MB, of which 5.68 MB is texture data a print pipeline never reads and 3.44 MB is a single PNG normal map for detail that is already cut into the mesh. It is 43.1 seconds of mobile download against 6.7. It is $54.93 of CDN a month against $8.52. And the 1.33× triangle lead that supposedly justifies it is a fixed house budget Tripo spends on every subject in the batch, not fidelity scaled to this one.

Tripo: 62/100. SupaVoxel: 90/100.

Which one I would use for this job

If the file has to travel — to a customer, a product page, a phone, or a hundred of them — use SupaVoxel. 10.02 MB instead of 64.63, 6.68 bytes per triangle instead of 32.37, three 4096² maps in WebP instead of JPEG and PNG, 6.7 seconds of mobile download instead of 43.1, and $8.52 of CDN a month instead of $54.93.

Three honest marks against SupaVoxel: its GLB's mesh compression means older toolchains need a conversion step before they can open it. Its export carries no real-world units, so you scale it yourself. And its project grid is not reliably newest-first under concurrent use — I opened the wrong project by card position during this very run.

Tripo AI 3D Model Review 2026: 0.94 mm Antlers on a 0.4 mm Nozzle

Leila Rowe — Fri, 16 Oct 2026 15:52:42 +0000

Disclosure: this is an independent hands-on test. Both tools were run on ordinary customer accounts; neither company supplied review access or saw this piece before publication.

My verdict in 60 seconds — Tripo 60/100, SupaVoxel 90/100

I handed one photograph — a seated chibi reindeer in a corduroy scarf, two branched antlers, two leaf ears — to two image-to-3D products on the same day, downloaded both GLBs, and measured them the way a print shop does: weld the vertices by position, scale to 120 mm tall, then slice every 1 mm and record how narrow the walls get. Tripo returned 1,996,779 triangles for 55 credits; SupaVoxel returned 1,499,386 for 3. Both passed the thing this case was picked to break. What decides the job is wall thickness: Tripo's thinnest antler cross-section is 0.943 mm against SupaVoxel's 3.116 mm — 2.36 nozzle widths against 7.79.

Here is the scorecard for this one job: turning that photo into a printable 120 mm figurine.

Watertight after welding — Tripo 3/10 (false) · SupaVoxel 10/10 (true) — Tripo's welded mesh still has 2 boundary edges
Non-manifold edges — Tripo 4/10 (2) · SupaVoxel 10/10 (0) — two edges a slicer has to be told what to do with
Shell count — Tripo 4/10 (2 components, Euler −7) · SupaVoxel 10/10 (1 component, Euler 0) — one piece of Tripo's reindeer is floating separately
Face winding — Tripo 3/10 (inconsistent) · SupaVoxel 10/10 (consistent) — Tripo ships inverted faces; you flip them or the slicer guesses
Thinnest antler cross-section — Tripo 2/10 (0.943 mm = 2.36 nozzles) · SupaVoxel 10/10 (3.116 mm = 7.79) — two perimeters and no infill on Tripo's tines
Thinnest wall anywhere up top — Tripo 1/10 (0.148 mm = 0.37 nozzles) · SupaVoxel 9/10 (0.398 mm = 1.0) — below one extrusion, silently discarded
Mesh hygiene — Tripo 9/10 (0 degenerate, 139 slivers) · SupaVoxel 5/10 (59 degenerate, 7,748 slivers) — Tripo wins this row outright
Resin at 120 mm — Tripo 9/10 (126.56 cm³, $4.43) · SupaVoxel 8/10 (139.48 cm³, $4.88) — SupaVoxel costs $0.45 more per copy

Part by part, what is true about the Tripo file:

All nine antler tines came back as separate prongs — the axis this case was chosen to stress, and I am not going to invent a failure there.
The corduroy ribbing is real displaced geometry, not a normal map; it survives with every texture switched off, including on the invented back of the head.
The triangulation is cleaner than SupaVoxel's: 139 slivers against 7,748.
And Tripo bought that sharper silhouette by thinning the antlers to 0.943 mm and the ear rims to 0.148 mm — two perimeters with nothing between them, and a rim the slicer deletes without telling you.

For this job — one photo, one 120 mm figurine, one person who wants to press slice and walk away — use SupaVoxel.

The only input: one 1,517,781 B PNG, sha256 8ba545f2… Both products received this exact file on default settings. The stress axes are visible in it — multi-branched antlers that could fuse into a lump, and fine corduroy ribbing that could get smoothed away. The camera never sees the back of the head, so everything behind the ears is invented by both.

The test, in one paragraph

One photo, two products, one day. Tripo Studio on its shipped default: Best Quality selected, Clean Topology unselected — Tripo marks that switch Trial ×2. SupaVoxel on a full model with Advanced Options at defaults: Inference Steps 5, Guidance Scale 5.5, Octree Resolution 256. Both GLBs were parsed offline; not one number below was copied off a panel. Every render uses one lighting rig and one set of cameras, corrected for export orientation, so each pair is the same viewpoint rather than two flattering angles.

Both products passed both things this case was chosen to break

This reindeer is in the test set for two reasons. The antlers — four tines left, five right, each branching off a main beam — are exactly the geometry that collapses into a mitten when a reconstruction under-resolves. And the corduroy can be faked with a 4096 normal map, which looks identical in a viewer and prints as a smooth blob.

Neither product failed either one. Tripo kept all nine tines separate with real air between them; so did SupaVoxel. With every texture switched off, both sets of ribs are still cut into the geometry — including on the back of the head, which the input photo never shows and both products invented. A shared pass is the real result here and I am reporting it as one.

Antler tines surviving as separate prongs — Tripo 9/9 · SupaVoxel 9/9
Ribbing present on the untextured mesh — Tripo yes · SupaVoxel yes
Ribbing on the unseen back of the head — Tripo yes · SupaVoxel yes

SupaVoxel's antlers, cropped from the untextured mesh render. Every tine is a separate round beam and each tine root carries a visible fillet into the main branch. Note how thick they read — that thickness is the entire article.

Tripo, same camera, same crop, textures off. Tripo's tines are also fully separate — the pass is real. The difference is the taper: each Tripo tine narrows into a tight neck where it meets the beam, with no fillet. That neck is where the 0.943 mm cross-section lives.

SupaVoxel with all textures off. The corduroy grooves are still there — real depth, not a normal map. The scarf reads as three separate rope coils with clean valleys between them, and the antlers are thick round beams.

Tripo, same camera, textures off. Tripo's ribs are also genuinely displaced, so the "fake texture" accusation does not apply. What the untextured render does expose is the antler necks and an ear that is a hollow thin spoon rather than a leaf with thickness.

How I measured wall thickness: 1 mm slices at 120 mm tall

Renders do not settle printability arguments. Slices do. I scaled both meshes to a 120 mm tall bounding box, then cut them horizontally every 1 mm through the top 30% — 72 slices for Tripo, 74 for SupaVoxel. For each closed loop I took min(x span, z span) as the narrow-direction width. Above 96 mm, past the ear tips, the only loops left are antlers. Same script, same height convention, both files.

Slices taken — Tripo 72 · SupaVoxel 74
Bounding box at target — Tripo 60.61 × 120.0 × 71.66 mm · SupaVoxel 59.14 × 120.0 × 80.85 mm
Nozzle assumed — 0.4 mm, both

The thinnest antler section: 0.943 mm against 3.116 mm

This is the number. Tripo's narrowest antler cross-section, across all 72 slices, is 0.943 mm; SupaVoxel's is 3.116 mm. In nozzle widths: 2.36 against 7.79. At 2.36 the printer lays down two perimeters and has nothing left over — no infill, no core, and the moment your slicer's thin-wall handling kicks in, that tine goes hollow or disappears. At 7.79 it is a solid beam.

Thinnest antler cross-section — Tripo 0.943 mm · SupaVoxel 3.116 mm · 3.3×
In 0.4 mm nozzle widths — Tripo 2.36 · SupaVoxel 7.79
Perimeters that fit — Tripo 2, no core · SupaVoxel 7+, solid

That is the whole trade. Tripo's antlers look sharper in every render in this article, and they look sharper because Tripo made them thinner than the machine can build.

SupaVoxel, front. Antlers are round beams, the ears are thick leaves with a visible rounded outer rim, and the scarf is a bundle of raised cords. It reads fatter than Tripo's, and that is not a fidelity loss — it is 7.79 nozzle widths of antler.

Tripo, same camera. Sharper, leaner, ribs packed denser. Every one of those tines is narrower, every tine root pinches harder, and the ears have thinned into flat shells. On screen Tripo wins this frame. On a print bed it is 0.943 mm.

The ear rims: 0.148 mm is below one extrusion line

Taking the whole top region rather than just the antlers, Tripo's absolute minimum wall is 0.148 mm, at the ear rims. That is 0.37 of one nozzle width — thinner than a single extrusion line, and a slicer does not warn you. It cannot lay down 0.37 of a line, so it discards the feature and keeps going; the ear comes off the bed with its rim missing. SupaVoxel's minimum over the same region is 0.398 mm: one extrusion line, exactly. Not generous, but it exists on the printed part.

Thinnest wall anywhere in the top region — Tripo 0.148 mm · SupaVoxel 0.398 mm · 2.7×
In nozzle widths — Tripo 0.37 · SupaVoxel 1.0
Slicer behaviour — Tripo: silently discarded · SupaVoxel: one perimeter, printed

SupaVoxel from directly above, antlers and ears. Every tine points a different way and none touch. Both ears read as leaves with obvious width — you can see the rim roll over.

Tripo, same viewpoint. The tines are separate here too. The ears are the story: from above they have narrowed to something close to a line. That is what 0.148 mm looks like before a slicer throws it away.

SupaVoxel in profile. The ear is a leaf with thickness and a rounded outer edge, and the antler tine roots have a visible chamfer into the beam. Rump ribbing sweeps across the curve unbroken.

Tripo, same profile. The rump ribbing is finer and shallower, and near the spine it starts smearing into sheets. The ear at this angle has almost no visible thickness at all — it is a shell, which matches the 0.148 mm the slicing pass found.

It is not one unlucky slice — the whole distribution leans the wrong way

A single worst-case number can be an artefact, so here is the rest of the antler-width distribution. Tripo is thinner at every point I checked, not just at the minimum — and the tips, where the gap is widest, are the part of a reindeer people pick it up by.

Antler width, minimum — Tripo 0.943 mm · SupaVoxel 3.116 mm
Antler width, 5th percentile — Tripo 2.873 mm · SupaVoxel 4.584 mm
Antler width, median — Tripo 6.672 mm · SupaVoxel 7.538 mm

Triangle count is not the variable here — both are already finer than the nozzle

Tripo delivers 1,996,779 triangles to SupaVoxel's 1,499,386, a 1.33× lead, easily read as Tripo buying detail. Convert it into the only unit a printer understands and it evaporates: at 120 mm tall Tripo's mean triangle edge is 0.1851 mm and SupaVoxel's is 0.2338 mm, against a 0.4 mm nozzle. Tripo is 2.2× finer than the tool, SupaVoxel is 1.7× finer. Both are already past the point where geometry turns into plastic, so Tripo's extra 497,393 triangles buy bytes, not detail.

Triangles — Tripo 1,996,779 · SupaVoxel 1,499,386 · 1.33×
Mean edge at 120 mm — Tripo 0.1851 mm · SupaVoxel 0.2338 mm
Finer than a 0.4 mm nozzle by — Tripo 2.2× · SupaVoxel 1.7×

The obvious retort is that SupaVoxel simply ships leaner meshes. It does not: across the ten cases I ran, SupaVoxel's counts run from about 945,000 to 2,786,054, a 146% spread scaled to the subject, while Tripo's run 1,896,372 to 1,996,779 across nine — a spread of 5.2% of the mean. Tripo spends a fixed house budget on every object. Ten cases each is a sample, not a law. On the tank case in the same batch SupaVoxel shipped 44% more triangles than Tripo did.

What Tripo's file needs before a slicer will take it

After welding vertices by position — which every slicer does on import — Tripo's mesh is not a solid. Two boundary edges, which are holes. Two non-manifold edges. Inconsistent winding, so some faces point inward. Two connected components, meaning a piece of the reindeer is a separate floating shell. Euler characteristic −7, the arithmetic confirming all of it. The SupaVoxel file, same pass: watertight, 0 boundary edges, 0 non-manifold edges, consistent winding, 1 component, Euler 0 — the textbook value for a closed genus-1 surface.

Watertight after welding — Tripo false · SupaVoxel true
Boundary edges (holes) — Tripo 2 · SupaVoxel 0
Non-manifold edges — Tripo 2 · SupaVoxel 0
Winding consistent — Tripo false · SupaVoxel true
Connected components — Tripo 2 · SupaVoxel 1
Euler characteristic — Tripo −7 · SupaVoxel 0

That is a repair pass — patch two holes, unify the normals, merge two shells — before Tripo's 55-credit file becomes something you can slice. And note which switch would have helped: Tripo's Clean Topology mode is the one that cleans this up, it is off by default, and Tripo labels it Trial ×2. Two uses.

Tripo Studio with the photo uploaded. The quality selector sits on Best Quality; Clean Topology beside it carries a Trial ×2 badge and is not selected. Everything measured above is what Tripo's default ships.

The SupaVoxel result page. Four inspection modes — Textured, Mesh, Wire, Normals — switch with one click, and the triangle count top right reads 1,499,386, which matched the downloaded GLB exactly. Tripo's panel figure matched its GLB too; that row is a tie and I am recording it as one.

Where SupaVoxel loses: 59 degenerate faces and 7,748 slivers

Tripo wins this row and it is not close: 0 degenerate faces and 139 slivers against SupaVoxel's 59 and 7,748 — 56× more thin, badly-shaped triangles in the same silhouette. The exchange rate: SupaVoxel's 7,748 slivers sit inside a watertight, consistently wound, zero-non-manifold single shell, while those 139 clean triangles sit inside a shell with two holes, inverted faces and a detached component. A slicer eats slivers without complaint; it does not eat holes and inverted normals.

Degenerate faces — Tripo 0 · SupaVoxel 59
Sliver faces — Tripo 139 · SupaVoxel 7,748 · 56×
Repair operations before slicing — Tripo 3 (patch, unify, merge) · SupaVoxel 0

Where SupaVoxel loses again: $0.45 more resin per copy

Second row that goes to Tripo. At 120 mm tall Tripo's solid volume is 126.56 cm³, $4.43 of resin at $35/L; SupaVoxel's is 139.48 cm³, $4.88 — 10.2% more material, $0.45 more per copy. That $0.45 is not bloat. It is the material cost of taking the thinnest antler cross-section from 0.943 mm to 3.116 mm and the ear rim from 0.148 mm to 0.398 mm — forty-five cents per figurine for a pair of antlers the printer can actually build.

Volume at 120 mm — Tripo 126.56 cm³ · SupaVoxel 139.48 cm³ · +10.2%
Resin at $35/L — Tripo $4.43 · SupaVoxel $4.88 · +$0.45
What the $0.45 buys — antler 0.943 mm → 3.116 mm, ear rim 0.148 mm → 0.398 mm

Support area is a tie, and getting the file out is not

At a 45° threshold Tripo needs 3,714.7 mm² of supported area and SupaVoxel needs 3,780.3 mm² — 1.8% apart, effectively identical. A seated pose with antlers and a chin overhangs on both sides; nobody wins that row.

Export is a different story. Tripo's is short once you reach it — File Name, Format, Texture Resolution, Export: two steps measured. Reaching it is the problem, because clicking Export opens the dialog with Tripo's Guide popup on top of it, covering two of the three fields. I did not record my click count from the SupaVoxel result page to the downloaded file in this run, so that cell stays empty rather than estimated. Not measured is not zero.

Support area at 45° — Tripo 3,714.7 mm² · SupaVoxel 3,780.3 mm² · 1.8% apart
As a fraction of surface — Tripo 16.37% · SupaVoxel 15.00%
Export steps — Tripo 2 · SupaVoxel not measured this run
Modal dialogs between result and export — Tripo 2 · SupaVoxel 0

The Tripo export dialog with Tripo's own Guide popup covering it. File Name and Format are both behind the tutorial. This is the screen you land on after paying 55 credits.

Final verdict: Tripo scores 60, SupaVoxel scores 90

Tripo passed the axis this case was built to stress — nine antler tines, nine separate prongs — and Tripo's ribbing is real displaced geometry, including on the invented back of the head. Tripo's triangulation is cleaner, 139 slivers to 7,748, and Tripo's print costs $0.45 less in resin. All three are real and all three are priced above.

What Tripo charged for them: 0.943 mm antler tines, a 0.148 mm ear rim the slicer deletes without a warning, a mesh in two pieces with two holes and inverted faces, and 55 credits against 3. Tripo's reindeer is sharper on screen, and that sharpness is the part that does not survive a 0.4 mm nozzle. Triangle count did not decide this case — both products are already finer than the printer. Wall thickness decided it.

Tripo: 60/100. SupaVoxel: 90/100.

Which one I would use for this job

If the job is turning a photograph into a figurine that comes off the bed intact, use SupaVoxel. You get a watertight, consistently wound single shell with zero non-manifold edges, antler tines at 7.79 nozzle widths instead of 2.36, an ear rim that is one full extrusion line instead of 0.37 of one, for 3 credits instead of 55. You pay $0.45 more in resin and you accept 7,748 sliver triangles your slicer will not notice. That is the whole bill.

Three concessions against SupaVoxel, because they are in the measurements too: the export carries no real-world units (the result page reads x 0.5 / y 1.02 / z 0.69 mm, so you scale it yourself); the GLB uses mesh compression and quantization that legacy scripts need one conversion step to open; and the project grid is not reliably newest-first when several generations run at once. None of those change what comes off the print bed.

Meshy AI 3D Review 2026: 35 Credits and a 79.7 MB VR Helmet Bust

Leila Rowe — Wed, 14 Oct 2026 15:52:32 +0000

Disclosure: this is an independent hands-on test. Both tools were run on ordinary customer accounts; neither company supplied review access or saw this piece before publication.

The moment that changed how I look at these tools was boring.

I had the model. I dragged it toward the project folder. And I watched the file size.

Seventy-nine megabytes. For one bust. Head, visor, shoulders, done.

I hadn't asked around about pricing or quality — I'd asked around about which image-to-3D tool to use, and the same two names kept coming up: Meshy and SupaVoxel. So I ran one image through both and then weighed what came back.

Here's the bill.

My verdict in 60 seconds — Meshy 58/100, SupaVoxel 91/100

My scores, for this one job. One image, one run per tool — not a lab study.

File size — Meshy 79,664,932 bytes vs SupaVoxel 12,385,676 bytes · Meshy 3/10 · SupaVoxel 9/10 — Meshy makes you carry five times the payload for one bust; SupaVoxel's export is small enough to ship on a page without a second thought
Download at 12 Mbps — Meshy 53.1 s vs SupaVoxel 8.3 s · Meshy 3/10 · SupaVoxel 9/10 — Meshy leaves your user staring at a spinner for the better part of a minute; SupaVoxel's file is there before they give up
Download at 100 Mbps — Meshy 6.37 s vs SupaVoxel 0.99 s · Meshy 4/10 · SupaVoxel 9/10 — Meshy stays a loading state even on a fast line; SupaVoxel comes in under a second, which means no loading UI to build
A hundred assets on disk — Meshy 7.97 GB vs SupaVoxel 1.24 GB · Meshy 3/10 · SupaVoxel 9/10 — Meshy turns a model library into a storage plan; SupaVoxel's fits somewhere you can actually ship it
Browser-ready copy — Meshy 13.64 MB vs SupaVoxel 7.58 MB · Meshy 5/10 · SupaVoxel 8/10 — Meshy needed a whole conversion pass and still landed heavier than SupaVoxel's untouched original; SupaVoxel converts smaller still
Export options — Meshy one GLB vs SupaVoxel compressed GLB and original-size GLB · Meshy 6/10 · SupaVoxel 9/10 — Meshy gives you a single file to make work everywhere; SupaVoxel gives you the light one for the web and the full one for a picky importer, out of the same run
What the run record gives you — Meshy: no generation window captured vs SupaVoxel: 268.043 s · Meshy 6/10 · SupaVoxel 8/10 — Meshy's run left me no duration to plan a schedule around; SupaVoxel's record hands you a concrete four-and-a-half-minute number. This is about what got recorded, not about which is faster
Recorded charge — Meshy 35 credits vs SupaVoxel 3 credits · Meshy 7/10 · SupaVoxel 7/10 — a deliberate tie: two different plans in two different units, so these numbers can't be ranked and I won't turn them into a price

Four things worth your attention.

Meshy's export is 79,664,932 bytes for a bust that stops at the shoulders.

On a 12 Mbps connection, that's 53.1 seconds of pure transfer. Nothing on screen. Just waiting.

A hundred of those assets is 7.97 GB. That's not a model library anymore, that's a storage plan.

And the run recorded 35 credits on Meshy against 3 on the other side — two different plans, two different units, so please don't read that as a price.

I shipped the small one. The tool that made it is at supavoxel.com if you want to look.

Meshy's 79,664,932-byte bust, rendered offline in my own viewer with fixed lighting.

The 12,385,676-byte file at the same camera. The two models sit at slightly different angles because each file carries its own built-in orientation.

What does a Meshy model actually cost you to deliver?

Not credits. Bytes — and Meshy has a lot of them.

Credits are a number on someone's dashboard. Bytes are what your users download, what your CDN bills you for, and what your headset holds.

A GLB is the single-file version of the glTF format — geometry, materials and textures bundled together. Both tools gave me one. Same format, wildly different weight.

That weight is the part you live with forever.

Meshy ships 79,664,932 bytes. What you're really shipping

Those Meshy numbers aren't rounded marketing numbers. I downloaded both files and checked them, hash and all.

The gap is 67,279,256 bytes. Call it 67 megabytes of extra payload per asset, before you've shown a single user a single thing.

Put four characters in a scene and Meshy just added about 268 MB the other file wouldn't have.

Same bust, same reference image, five times heavier.

Meshy's result page for this run, redacted. Looks great. Weighs 79.7 MB.

The other tool's result page for the same image.

Meshy means 53 seconds of staring at a loading screen

Here's what that weight turns into for an actual person.

Assume a steady 12 Mbps connection — a decent mobile link, a hotel, a busy office. Meshy's file takes 53.1 seconds to transfer. The other one takes 8.3 seconds.

Fifty-three seconds of Meshy.

Think about what your user does for those 53 seconds. They're not exploring your scene. They're watching a spinner, deciding whether this was worth clicking.

Eight seconds is annoying. Fifty-three is a bounce.

And that's per asset. Put three busts in a room and Meshy's version of your gallery takes over two and a half minutes to arrive.

Meshy from the side. 53.1 seconds of waiting, at 12 Mbps.

Same camera, the file that arrives in 8.3.

Even on fast office wifi, Meshy makes you wait

Maybe you're thinking: fine, but my users are on good connections.

Sure. Let's say 100 Mbps.

Meshy: 6.37 seconds. The other file: 0.99 seconds.

That one-second line matters more than the gap. Under a second, a thing just appears. Six seconds is a state you have to design for: a placeholder, a progress bar, a message somebody has to build.

Meshy doesn't just cost you bandwidth. It costs you UI you wouldn't otherwise write.

Now multiply Meshy by a hundred

One Meshy bust is a demo. A product is a hundred of them.

Copy this single file a hundred times and Meshy's library is 7.97 GB. The other one is 1.24 GB.

That's 6.73 GB of difference. On a CDN it's a line item. On a device it decides whether the library ships with your app at all.

Same arithmetic on the credits, for whatever it's worth: 3,500 on Meshy's ledger, 300 on the other. Two different plans, two different units — not a price ratio, and I won't pretend I know what either costs in money.

Meshy from above — one of the hundred copies in that 7.97 GB.

Same camera, the file that makes 1.24 GB instead.

Meshy is heavier inside the file too, before a single texture loads

Bytes on disk are one bill. Memory once the file is open is another, and Meshy loses that one too.

Here's what's actually inside. Meshy's GLB carries 2,490,490 triangles and 1,331,208 vertices. The other file carries 1,487,122 and 944,806.

A vertex is a corner of the surface; a triangle is the flat shard stretched between three of them. Your engine uploads the corners and then draws the shards. More of both means more to send and more to draw.

Put a plain layout on those numbers — position, normal and texture coordinate per vertex, plus three 32-bit indices per triangle — and Meshy's geometry works out to about 72.48 MB against 48.08 MB.

That's arithmetic with an assumed layout, not a reading off a device. But it's the right order of magnitude, and it's roughly 24 MB of headroom you don't get back.

On a standalone headset, 24 MB is a feature you now can't ship. It's a second character, or a room's worth of textures, or the audio you wanted to keep uncompressed.

And remember: no textures are in that figure at all. That's geometry alone.

The trade-show moment, which is where this actually hurt

Let me tell you when file size stopped being theoretical for me.

Demo on a borrowed connection. Someone senior standing there. Headset on their head, scene loading.

On a good link, Meshy's bust needs 6.37 seconds. On the hotel wifi you actually get, you're somewhere up near the 53. And the person wearing the headset has nothing to look at while they wait, so they take it off.

That's the whole risk in one sentence: your model is only as good as the moment it arrives.

The 12,385,676-byte file arrives in about 8.3 seconds on the bad connection and under a second on the good one. Same bust. Same reference image. You just don't get the awkward silence.

What the credits actually tell you (and what they don't)

The run recorded 35 credits on Meshy and 3 on the other tool for the same image.

I know what you want me to do with those two numbers. I'm not going to.

They're two different plans in two different units. Nobody sells "a credit" — they sell packs and tiers, and a credit on one dashboard has nothing to do with a credit on another. Turning that into "X times cheaper" would be the most misleading sentence I could write.

What I can tell you is what those 35 Meshy credits produced: 2,490,490 triangles, 1,331,208 vertices, three texture maps, and a 79,664,932-byte file.

Meshy's generation time? I don't have it.

I want to be straight about this one, because it's the number everyone asks about.

The other tool recorded a 268.043-second generation window — about four and a half minutes, start of the job to end, download not included. Meshy's equivalent wasn't captured in this run. Neither were failure counts or retry counts, on either side.

What I can tell you is when each job went in: the Meshy run at 02:30:57 UTC, the other at 03:07:41 the same morning. That's the order they happened in. It is not a duration, and I'm not going to dress it up as one.

So there's no speed verdict in this article. Not for Meshy, not against it. If someone tells you which of these is faster based on one run, ask them where the number came from.

The honest version of "how long does it take" is: I have one side's number and not the other's. Four and a half minutes on the tool that recorded it, unknown on Meshy. Plan your own test if the answer matters to your schedule.

I converted both for the browser. Meshy still lost.

To put both models in a web viewer, I ran the Meshy file and the other one through the same conversion.

Meshy's browser copy came out at 13.64 MB. The other one: 7.58 MB.

Look at that first number again. Meshy's compressed, converted, browser-optimised copy is still bigger than the other tool's original export at 12,385,676 bytes.

Meshy needed a whole processing step to get near where the other file started.

Meshy's download menu. I took GLB on both sides.

The other export menu, same choice.

The export menu is where this stopped being a dilemma

I almost missed this, and it turned out to be the most useful thing I learned all week.

The SupaVoxel export menu offers a compressed GLB and an original-size GLB. One run, two files, pick per destination.

So the web build takes the 12,385,676-byte version — 8.3 seconds at 12 Mbps, under a second on a fast line. Anything that won't install a decoder takes the original-size version instead. The original-size file is the complete, uncompressed deliverable, so of course it's the heavier of the two; that's what it's for, and the light one is right there when you need it.

Meshy hands you one GLB. It opens anywhere, which is genuinely useful — but when it's too heavy for the web, your options are a conversion pass or living with 53.1 seconds.

Two deliverables from one generation beats one deliverable you have to negotiate with.

Where Meshy actually wins

One real point, and it's about how the small file got small.

When a GLB is compressed, it can declare that it requires an extension — a piece of the format your importer has to understand, or it won't open the file at all. meshopt is one of those.

Meshy's file requires nothing. Clean, uncompressed, opens anywhere.

The compressed SupaVoxel file requires meshopt compression and mesh quantization. Take the original-size export from the same menu instead and that decoder requirement disappears. I read that off each file's own declaration — I didn't test the import anywhere.

The exchange rate: Meshy's no-install convenience costs you 67 MB per asset, 44.8 extra seconds at 12 Mbps, and 6.73 GB per hundred copies — and on the SupaVoxel side you don't trade anything for it, because both exports come out of the same run. If all you have is Meshy's one file and a recipient who won't install anything, Meshy is the safer delivery.

Meshy takes a smaller second point too. Both files embed exactly three texture maps — the image wrapped around the model — but Meshy's are 2048×2048 where the other file's are 4096×4096. That's a quarter of the pixels per map.

Force both sets to decode raw, with no mipmaps and no runtime compression, and Meshy's three maps come to roughly 50.33 MB against about 201.33 MB. Arithmetic on the measured pixel dimensions, not a reading off a headset — real engines rarely decode that way.

Still, 151 MB is 151 MB. If your target is memory-bound rather than bandwidth-bound, Meshy's lighter maps are the right trade: you get a much cheaper texture budget and you pay for it in the close-ups. Pick the constraint that actually breaks your build.

Meshy's back view. The reference photo never showed this side — both tools invented it.

Same camera, other file. Same caveat.

So which file do you ship, Meshy's or the other one?

Anything that downloads — the 12.4 MB file. Meshy's 79.7 MB is a bounce waiting to happen.
Handing a file to someone who won't install anything — Meshy. It opens as-is.
Building a library — 1.24 GB per hundred versus Meshy's 7.97 GB. That's the whole decision.
Picking on price — you can't, from this. Different plans, different units.
Picking on speed — you can't either. Meshy's time wasn't captured.

Meshy from the front.

Same camera, the smaller file.

Final verdict: Meshy scores 58/100 for this job

Meshy made a good-looking bust and charged 35 credits on its own ledger to do it.

Meshy also handed me 79,664,932 bytes, 53.1 seconds of waiting on a normal connection, 7.97 GB per hundred assets, and a browser conversion that still landed heavier than the other tool's untouched export.

58/100, for this one job, one image, one run each. Not an average, not a verdict on Meshy everywhere.

Try it with your own image

Run the picture you actually need. Through Meshy, and through the other one. Then look at the file size before you look at the render.

The small export came out of supavoxel.com — 12,385,676 bytes, 3 credits on its own ledger, 268.043 seconds. Take the compressed GLB for delivery and the original-size one if the far end is picky; they come from the same run.

Your file, your connection, your call.

How I tested this

One reference image, made with GPT Image 2, uploaded to Meshy and to SupaVoxel with no text prompt on either side. One run each, GLB downloaded from both, both files hashed and measured.

Every byte count above is read off the downloaded file. Credits and the 268.043-second window come from the run record; where a number wasn't captured — Meshy's generation time, and failure and retry counts on both sides — I've said so rather than estimated it.

The download seconds are arithmetic, not a network test: file bytes × 8 ÷ bandwidth, at an assumed steady 12 Mbps and 100 Mbps, ignoring handshake, latency, caching and decode. The 7.97 GB and 1.24 GB figures are the same file counted a hundred times — a capacity exercise, not a hundred real runs. The texture figures are arithmetic too: three maps decoded as raw RGBA, no mipmaps.

Renders are mine, from one offline viewer with fixed lighting and identical camera numbers on both sides; each GLB carries its own built-in orientation, so the pairs are two models under one camera, not an overlay. The browser copies were made with one shared conversion command, and the conversion shifted one model's triangle count by 2 — which is why every measurement here comes from the untouched originals. UI screenshots were redacted before publication.

Meshy AI 3D Model Review 2026: Same 3 Textures, 69.18 MB File

Leila Rowe — Mon, 12 Oct 2026 16:04:06 +0000

This is an independent test. Nothing here came from vendor access: both tools were used on my own free and paid accounts.

There's one question nobody can answer for you from a marketing page.

Does the 3D model actually look like the drawing you fed it?

I had a drawing of a graduation monkey — cap, gown, red sash, rolled diploma — and I needed a version of him that would hold up on a classroom page. I asked around for the best picture-to-3D tool and got the same two names back over and over: Meshy and SupaVoxel.

So I ran the drawing through both, rendered both results from identical camera angles, and cropped the same rectangles out of each.

My verdict in 60 seconds — Meshy 59/100, SupaVoxel 89/100. My scores for this one job. The numbers underneath came out of the two files.

Quick jargon check. Textures are the colour images painted onto a 3D shape. A GLB is the single file carrying the shape and those textures together. Triangles are the flat scraps the shape is built from.

Here's what I found:

Colour textures inside — Meshy 3 vs SupaVoxel 3 · Meshy 7/10 · SupaVoxel 7/10 — a straight tie: both embed exactly three, so nobody is painting this monkey better than anybody else.
Bytes carrying those 3 textures — Meshy 69,179,580 B vs SupaVoxel 11,165,408 B · Meshy 5/10 · SupaVoxel 9/10 — Meshy charges you six times the box for the same three coats of paint; SupaVoxel delivers the identical count in 11.17 MB.
Wait before anyone sees that look, at 12 Mbps — Meshy 46 seconds vs SupaVoxel 7 seconds · Meshy 4/10 · SupaVoxel 9/10 — Meshy's likeness arrives after a spinner most people won't sit through; SupaVoxel's is on screen while they're still looking.
The face at a shared crop box — both keep eyes, nose, smile and cap brim · Meshy 7/10 · SupaVoxel 7/10 — a tie, and the expensive kind for Meshy: 586,096 extra triangles bought no visible advantage in the frame that matters most.
The diploma and sash at a shared crop box — both resolve the roll and the red band · Meshy 7/10 · SupaVoxel 7/10 — another tie: the prop reads correctly on both, so Meshy's extra weight bought nothing here either.
The mortarboard from overhead — four square corners on both · Meshy 7/10 · SupaVoxel 7/10 — tie again on the hardest shape in the drawing, which Meshy needed 2,086,002 triangles to match rather than beat.
Triangles spent on that look — Meshy 2,086,002 vs SupaVoxel 1,499,906 · Meshy 5/10 · SupaVoxel 8/10 — Meshy spends 586,096 more scraps for a result I can't tell apart; SupaVoxel gets the same read from 72% of the count.
Exports you get from one run — Meshy 1 GLB vs SupaVoxel 2 (compressed and original size) · Meshy 5/10 · SupaVoxel 9/10 — Meshy gives you one weight for every use of that likeness; SupaVoxel gives you a web-weight file and a full uncompressed one from the same menu.

Three things stood out. Meshy packs exactly 3 colour textures — the same count the 11.17 MB file carries — into 69,179,580 bytes. Meshy spends over two million triangles on a face crop that isn't visibly closer to the drawing than one built from a million and a half. And on the back, where every tool is guessing, Meshy has nothing to be judged against and neither does anyone else.

For a page where the monkey just has to read correctly at a glance, I'd ship the smaller file — the one SupaVoxel made. SupaVoxel's site, if you want to see it.

This is one image and one run on each side — not a lab study.

The drawing both tools were given, and the only reference either of them had. Uploaded to Meshy at 02:26 UTC and SupaVoxel at 02:49, no text prompt on either. Note what's missing: any view of the back. That gap decides half this article.

Same paint, so why is Meshy six times the box?

Start with the thing that made me go back and re-check.

Both files carry exactly 3 colour textures. That's a count, not a resolution — I measured how many images Meshy and SupaVoxel each pack in, not how large those images are.

Meshy needed 69.18 MB to deliver its three. SupaVoxel needed 11.17 MB to deliver its three. Same three coats of paint, and Meshy asks six times the box to carry them.

Both also come out as a GLB, so nobody has to convert anything before they look at either one. That part is a clean tie.

Meshy straight on at the front camera. Cap square, gown falling properly, diploma a clean cylinder, sash reading as a separate band. Genuinely good work from one picture.

SupaVoxel from the identical front camera. Same four elements, same read, from a file 58,014,172 bytes lighter. The two models can sit at slightly different angles inside their own files, so this is same-camera rather than pixel-matched.

Sounds fine either way, right? It isn't, once the file leaves your machine. On a 12 Mbps phone connection the Meshy 69.18 MB is about a 46-second download against about 7 seconds — arithmetic on the measured bytes, no handshake or decoding included.

Six times the shipping cost for the same three coats of paint.

Is the Meshy face any closer to the drawing?

This is the crop that matters, because kids look at the face.

I cut an identical rectangle out of the Meshy render and the SupaVoxel one — same coordinates on the same front view, same 2× zoom, no cherry-picking angles.

Meshy's face at the shared crop box. Eyes, nose, smile and cap brim all present and all readable. The muzzle-to-cheek transition is smooth, with no visible joins.

SupaVoxel's face, identical rectangle and identical zoom. Eyes, nose, smile and brim again — plus a faint seam running along the nose bridge and cheek boundary, which I'll own properly in a moment.

Both are readable. That's the finding, and it's more damning for Meshy than it sounds: those extra 586,096 Meshy triangles didn't buy a single visible advantage inside this frame, and this is the frame Meshy most needed to win.

Here's the moment that matters to you. A parent zooms in on the class page. At that zoom level, on that crop, the heavy Meshy file and the light one tell you exactly the same thing about the monkey.

When the heavy option and the light option look the same, the heavy one has to justify itself. Meshy can't, not in this crop.

The diploma, the sash, and the same result again

Meshy's diploma, red sash and sleeve edge at the second shared crop box. The roll reads as a roll, the sash reads as a band lying on top of the gown, and the sleeve edge stays distinct from the hand.

SupaVoxel at the identical box and zoom. Same roll, same red band, same sleeve separation — from 58 MB less file and 586,096 fewer triangles.

Both resolve the prop. Both would print fine on a worksheet. Meshy has no edge here that I can point at, and I went looking for a Meshy edge specifically.

Underneath these two crops sit 1,129,335 corner points on the Meshy side and 890,607 on the other — a gap of 238,728 points that produced no difference I can point to in either rectangle.

Run those counts through a standard layout — 32 bytes per point, 4 bytes per triangle index — and the Meshy shape wants about 61.17 MB of memory against about 46.50 MB. Illustrative arithmetic applied to both, not a graphics card reading.

That's roughly 14.67 MB of extra memory that, as far as these two crops show, bought you nothing you can see.

And if you're about to say weight doesn't matter on a real computer: on a 100 Mbps line the Meshy file is 5.5 seconds of download against 0.9, which genuinely nobody cares about. It's the phone that kills you, not the desktop.

The cap from above, where Meshy had a real chance

Meshy from directly overhead. Four square corners on the mortarboard and a crisp brim — the classic place these things go soft and pillowy. Meshy held it.

SupaVoxel, identical overhead angle. Four corners as well, same brim line, from 1,499,906 triangles against Meshy's 2,086,002.

Both hold the square. That's the pattern of this whole comparison in one picture: Meshy's extra weight buys a match, not a win.

The angle you'd actually put on a slide

Crops are useful, but nobody shows a class a crop. They show the whole monkey, turned three-quarters.

Meshy's monkey at the classic three-quarter angle. Cap, gown, sash, diploma — Meshy landed all four from a single drawing, and this is the frame its own result view sits closest to.

SupaVoxel at the identical angle. All four again, from a file 58 MB lighter and with the same 3 textures inside.

Put those side by side on a projector and ask a room of teachers which one cost 35 Meshy credits and which cost 3 SupaVoxel credits. Nobody's picking correctly. And before you do the maths on that: two different plans, two different units — not a price comparison, and I never captured what a credit costs on either side.

A silhouette is usually where surplus geometry finally shows itself, since every bump reads against empty background. I went looking for the 586,096 extra Meshy triangles at this angle too, and came back with nothing.

The Meshy advantage has to show up somewhere a person can see it, and across five camera angles and two crops it never did.

One likeness, two files to ship it in

There's one more difference, and it isn't about how the monkey looks. It's about how many versions of that look you get to keep.

Meshy's run gives you a single GLB at 69,179,580 bytes. That one file is what goes to the lesson page, the archive and anyone downstream who asks.

The SupaVoxel menu gives you two from the same generation: the compressed GLB at 11,165,408 bytes, and an original-size GLB the browser recorded at 82,060,632 bytes. The second is the full uncompressed deliverable, so naturally it's the bigger of the two — that's what uncompressed means.

Same likeness, two weights, chosen per destination. Put the 11.17 MB version on the page a parent opens on a phone; hand the original size to whatever wants the model plain and unpacked. No re-running the drawing, no conversion tool, no second charge in anybody's credits.

I never saved that original-size file, so I can't tell you what's inside it. I can tell you it's one click from a run you already made, and that Meshy's export panel offers nothing like it.

The back, where nobody gets a score

Now the honest part, and the part most reviews fake.

Meshy's rear close-up. A continuous gown surface with no hole in it and a plausible hood shape — worth saying plainly, because gaps back here are a common failure.

SupaVoxel's rear close-up at the identical angle and zoom. Also continuous, also no hole, and just as invented as the Meshy one next to it.

The drawing has no back. So there is no right answer for Meshy's gown seam, hood or cap rear — and none for the SupaVoxel one either.

I can describe what Meshy invented and what SupaVoxel invented. I cannot grade either one. Anyone who tells you one AI "got the back right" from a front-only reference is selling you something, and that applies to anybody praising Meshy here as much as anybody attacking it.

That limitation is symmetric, and it is not a mark against Meshy.

What a nice face still won't do

Whatever the face looks like, neither file will act.

Both contain zero skeletons and zero animation clips. Meshy: zero and zero. SupaVoxel: zero and zero. For a tool Meshy markets on characters, that empty pair of boxes is worth noticing.

So the Meshy monkey can be looked at and turned, and so can the other one. Neither can blink, wave or mouth a word without somebody building a rig by hand — and that somebody would rather be dragging 1,499,906 triangles than Meshy's 2,086,002 through every brush stroke.

Where Meshy actually wins

Three of them, in one place, with what each one costs you.

One: no seam on the face. Look back at that crop pair. The SupaVoxel face has a faint line along the nose bridge and cheek boundary. Meshy's doesn't. If you're planning to blend a facial rig across that area, Meshy hands you the cleaner surface, and that is a real advantage worth having.

Two: no required extensions. Inside every GLB is a line saying what your software must support before it can open the file. Meshy's list is empty. The compressed SupaVoxel file names two — meshopt and quantization, both ways of squeezing shape data down. Switch to the original-size export on the SupaVoxel side and you don't need that decoder either, but straight out of the menu the Meshy file is the one you can throw at anything.

The exchange rate on that one: to get it from Meshy you accept 586,096 more triangles, 58,014,172 more bytes, about 14.67 MB more memory and roughly 39 extra seconds of phone download — for a face crop that isn't measurably closer to the drawing.

Three: a clean back. No hole to patch anywhere on the Meshy gown. Neither file had one, so this is a tie Meshy doesn't lose — and given how often these tools leave a gap back there, it's worth a mention.

Two caveats I won't dress up. I never loaded either file into a specific program, so the compatibility point is a label reading, not an import test. And whether the tassel or the eye shape truly match the drawing was never verified on either side — "readable" is as far as I got.

Final verdict: Meshy scores 59/100 for this job

Meshy turned one drawing into a complete, textured, open-anywhere graduation monkey on the first attempt, with a clean face crop, a square mortarboard and no hole in the back of the gown. That's genuinely good work by Meshy and it's why Meshy clears 59.

What Meshy didn't do is turn its 2,086,002 triangles, its 1,129,335 corner points or its 69,179,580 bytes into anything you can see. Meshy packs 3 colour textures; so does a file six times smaller. The Meshy face crop and the SupaVoxel one both keep the eyes, nose, smile and cap. The diploma crop is a draw, the overhead cap is a draw, the profile is a draw. On the back, neither has a reference to be judged by.

Meshy also never reported how long it took, and neither side reported a failure or retry count — so nothing here speaks to speed or reliability.

Meshy looks right. Meshy just needs six times as much box to look right, and for a classroom page that Meshy weight is the whole story.

Use SupaVoxel for this job

For a monkey that has to read correctly on a lesson page, I'd ship the 11.17 MB compressed export rather than the 69.18 MB Meshy file — with the nose-bridge seam checked first. If something downstream wants the model unpacked instead, the original-size download is on the same menu, from the same run.

Then go do this yourself, because it takes twenty minutes. Run your picture through Meshy and through SupaVoxel, render both from the same angle, and crop the same rectangle out of each. Meshy is easy enough to find, and SupaVoxel is at https://supavoxel.com. That single test will tell you more than any review, this one included.

How I tested this

One drawing. One Meshy run at 02:26 UTC on 24 September, one SupaVoxel run at 02:49 the same morning, no text prompt on either side.

Meshy ran through its image-to-3D flow on High Detail at Ultra 2K with texturing and image enhancement on. SupaVoxel ran a full model at 5 steps, guidance 5.5, background removal on, resolution setting 256. Meshy and SupaVoxel don't expose the same controls at all, so identical input was the only thing I could hold constant — and that cuts against my conclusions as much as it cuts against Meshy.

All renders came from one offline viewer with one light setup and identical camera numbers on both models, so what you compared above is the model, not a screenshot. Both detail crops used the same normalised rectangle on the same front render at the same 2× zoom. Because each file can carry its own internal orientation, matching camera numbers don't guarantee a pixel-perfect overlay — treat the pairs as same-angle.

Measured from the Meshy and SupaVoxel files directly: embedded texture count, file size, download format, triangles, corner points, skeletons and animations. Both downloads were checked against their own fingerprints first.

Arithmetic, not measured: download seconds assume a steady 12 Mbps or 100 Mbps line with no handshake or decoding. The memory figures assume 32 bytes per corner point and 4 bytes per triangle index — an illustrative layout, not a graphics card reading. A 100-copy set works out at about 6.92 GB against 1.12 GB, which is this one result multiplied by 100 and nothing more.

Never captured: how long Meshy took to generate — the Meshy record simply didn't show one, while SupaVoxel's logged 304.808 seconds — plus failure and retry counts on both sides, and whether the tassel and eyes truly match the drawing.

One note on money, since people ask: the job record shows 35 credits on the Meshy side and 3 on the SupaVoxel side. Two different plans, two different units. That is not a price comparison and I won't make it one.

Hyper3D 3D Print Review 2026: Sealed Shell, Unproven Skeleton Ribs

Leila Rowe — Sat, 10 Oct 2026 16:03:08 +0000

Disclosure: I ran this comparison independently on standard customer accounts. Neither vendor granted special access, and neither saw the text ahead of release.

Picture a palm-sized skeleton cat: open ribs, a tail that loops back on itself so light passes through, the kind of oddity people buy for a bookshelf. Now picture the buyer picking up the 120 mm print by a single rib. That second image is what this review is really about, because a render can look convincingly hollow while hiding a strut far too slender to handle.

Both Hyper3D and SupaVoxel got the identical cat illustration. I downloaded one textured file from each and analysed the real surfaces rather than the viewport. Hyper3D's free Gen-2.5 preview was not downloadable, so the Hyper3D file in this piece is its Gen-1.5 PBR export. Neither cat was sliced or physically printed.

My verdict in 60 seconds — once the UV seams are welded, both cats clear the same narrow watertightness check, and neither has earned a print approval. Hyper3D keeps the ribs looking more delicate, and its local triangles are tidier. SupaVoxel samples the surface more finely, computes to a smaller solid-fill volume and shows 3MF in its export menu — yet its 7,217 sliver and 19 degenerate triangles are real cleanup work. I'd reach for SupaVoxel when the sculpt is going to be refined further or when a 3MF pipeline is worth exploring, but I would not call it the sturdier or easier-printing rib cage. The eight paired calls below are my editorial judgments for this single figure, not measured scores.

Sealed outer surface — Hyper3D: watertight with 0 nonmanifold edges · SupaVoxel: watertight with 0 nonmanifold edges once welded. A draw on this narrow check.
Single connected piece — Hyper3D: 1 face-connected component · SupaVoxel: 1. Neither figure says anything about how strong a rib is.
See-through ribs — Hyper3D: more slender, separate bars · SupaVoxel: wider arches that run together. For a delicate look, Hyper3D takes it.
Holes in the tail — Hyper3D: smaller through-holes · SupaVoxel: a heavier open loop. Each genuinely keeps its openings.
Average triangle edge, longest side scaled to 120 mm — Hyper3D: 0.7664 mm · SupaVoxel: 0.3139 mm. Finer sampling for SupaVoxel; rib thickness itself was not measured.
Triangle hygiene up close — Hyper3D: 0 degenerate, 249 sliver · SupaVoxel: 19 degenerate, 7,217 sliver. This is where SupaVoxel genuinely loses.
Downward-facing area — Hyper3D: 3,020.2 mm² · SupaVoxel: 4,322.7 mm² in the stated orientation. Less absolute area for Hyper3D; not a slicer support figure.
Solid-fill resin estimate — Hyper3D: 46.53 cm³ / $1.63 · SupaVoxel: 38.95 cm³ / $1.36 at $35/L. A $0.27 saving for SupaVoxel on paper, not an actual print invoice.

Both tools received this same 1,702,829-byte illustration, generated independently. The gaps between ribs are visible, but no wall thickness can be read off a flat picture.

What job does a bone cat actually have to do?

It isn't competing on how pretty it looks in a browser viewport. The brief asks for an open rib cage, a pierced tail and separate limbs that still read as a skeleton when shrunk to a small object. I had one image taken from one side, nothing describing the hidden back, and no target rib diameter. A buyer will tolerate artistic license; nobody should tolerate a "print-ready" promise on tiny struts that nobody has tested.

Hyper3D produced a Gen-2.5 preview plus a separate Gen-1.5 model that could be downloaded; SupaVoxel produced one model from the same source PNG. Rather than trust a thumbnail that looked alike, I confirmed the SupaVoxel request's input by hash. Hyper3D's two versions stored different automatic descriptions, so I won't pretend the visual gap between them comes down to the version alone. The million-triangle figure on the Gen-2.5 panel plays no part in any GLB measurement below.

On the free account, Download for Gen-2.5 was refused after a separate 0.5-credit trial. That preview is not the Hyper3D mesh being compared.

Front view: which chest reads as individual bones?

Both do, to a degree. Hyper3D's chest has more bars, each looking narrower; SupaVoxel's has wider arches that cross each other. Eye sockets, ears, legs and a central opening survive in both. Judged purely as "a delicate skeleton cat on a display card," this input goes to Hyper3D. Piling polygons onto the SupaVoxel side does not turn thick-looking arches into slender bones.

More finely divided ribs on the Hyper3D front — a visible sculptural advantage, not a measured wall thickness.

The SupaVoxel chest is open as well, drawn with wider curves. That it is watertight after welding is a separate matter.

Side profile: where the two skeletons part ways

Turned sideways, Hyper3D shows small holes through the curled tail and tightly packed ribs along the chest. SupaVoxel renders a continuous open loop and bigger arches that cross. The broad impression — two skeleton cats — holds up; the finer design choices diverge. Someone spinning a product listing may well pick a favourite aesthetic on sight.

No printer's minimum feature size was checked. With the bounding box capped at 120 mm, the smallest holes could close up during slicing or post-cure cleaning. "At 120 mm" in this article always means each file's longest outside dimension, not matched standing height. Hyper3D scales to 58.34 × 120.00 × 106.42 mm; SupaVoxel to 48.86 × 116.38 × 120.00 mm. Matching both to the same vertical height would be a separate scaling job.

At the same side yaw, Hyper3D shows tighter rib spacing and finer tail holes. The render comes with no fracture test.

Real gaps remain on the SupaVoxel side, but the tail loop is heavier. A denser mesh did not yield a finer skeletal outline.

The back neither tool could see

Hyper3D invents a narrow central spine and keeps the ribs individually visible. SupaVoxel invents a wider, joined rear surface with openings along the flanks. There was no rear photograph for either to work from. If this cat is sold as a rotating collectible, that made-up back needs its own art sign-off before anyone markets it as an "accurate reproduction."

Hyper3D's invented spine looks thinner, so more separate ribs show up close; the input offers no ground truth for this side.

A wider rear spine shifts how the SupaVoxel sculpture reads. It was generated, not reconstructed from a rear view that never existed.

Open holes or open seams? The raw-mesh scare

Textured files set a well-known trap. Wherever the UV map splits, a textured GLB can duplicate vertices that sit at the same point in space. Count boundary edges straight from the original indices, without merging coincident positions, and Hyper3D seems to have 94,024 while SupaVoxel seems to have 277,250. Those figures are seam artefacts, not proof that either sculpture leaks.

Weld by position and each file shows no boundary edges, no nonmanifold edges, consistently wound faces and a single face-connected shell. Hyper3D collapses to 59,890 welded vertices and SupaVoxel to 749,477. So SupaVoxel's huge raw boundary count never meant thousands of holes awaiting repair. A print shop that confuses UV seams with cracks may burn repair hours or bin a perfectly sound shell — while a shop that stops checking at "watertight" can still sail past a rib too narrow to print.

Without textures, the Hyper3D rib openings are still there — deliberate through-spaces, unrelated to the 94,024 raw UV boundary edges.

SupaVoxel's gaps are real geometry as well. Once welded, the topology passes, whatever the unwelded index count implies.

What twelve times the triangles buys SupaVoxel

The Gen-1.5 textured file I extracted from Hyper3D holds 120,000 triangles. SupaVoxel's Original size GLB, exported through its UI, holds 1,499,910 triangles. Normalised to the same longest side, mean triangle edges come out at 0.7664 mm and 0.3139 mm. For a sculptor who wants denser sampling to reshape an ear or the tail, that is a measurable plus for SupaVoxel. Triangle count, though, proves neither better fidelity nor any minimum rib size.

Dense SupaVoxel wireframe: evidence of finer sampling, not of a likeness twelve times better or of struts verified as printable.

The price of density: slivers and degenerates

SupaVoxel loses on local mesh hygiene. By the audit's definitions, Hyper3D has zero degenerate and 249 sliver faces, while SupaVoxel has 19 degenerate and 7,217 sliver faces — 6,968 more slivers. Two watertight surfaces do not make two equally clean ones, and I won't pretend otherwise. Skinny or collapsed triangles can bite when you decimate, edit or slice near a narrow rib. I saw no slicer failure traceable to any particular face.

Hyper3D isn't mathematically flawless — 249 slivers are left — but it has none of the 19 degenerates in the rival export.

Downward area is not a support estimate

Count the faces whose normals point within 45° of downward −Y and, at normalized size, Hyper3D scores 11.92% / 3,020.2 mm² against SupaVoxel's 10.55% / 4,322.7 mm². By percentage SupaVoxel is ahead, yet it carries 1,302.5 mm² more absolute downward-facing surface. The ratio and the absolute area diverge because the two meshes cover different total extents.

None of this equals support resin. Reorient the cat, swap build plates, alter slicer rules or hollow it, and the support plan shifts. Scaling the measured area to 100 hypothetical identical cats gives 302,020 versus 432,270 mm² of potential downward surface — not measured support volume, and not labor. Before pricing cleanup for either model, I'd run both through one slicer.

A top view helps choose an orientation, but a screenshot cannot convert 4,322.7 mm² of potential downward surface into real support material.

The resin arithmetic that favors SupaVoxel

Since both welded meshes pass the closed-solid checks, each can carry a conditional volume figure. Normalized to a 120 mm longest side, Hyper3D encloses 46.53 cm³ and SupaVoxel 38.95 cm³. With a modeled $35/L and completely solid fill, that works out to $1.63 versus $1.36. SupaVoxel's file encloses 7.58 cm³ less, roughly $0.27 less assumed resin per piece. Across 100 hypothetical identical solid pours it is $163 versus $136 — a $27 gap for planning purposes, not 100 cats off a printer.

Treat that edge as real only in the sense of arithmetic on two valid closed volumes. It doesn't cancel 7,217 slivers, doesn't show the ribs will survive washing, and doesn't give total material cost. Supports, hollowing, failed prints and handling could easily swamp a 27-cent difference. The SupaVoxel export menu also lists 3MF next to GLB and STL; I never downloaded a 3MF file, so that is a workflow worth exploring rather than a format-quality finding.

3MF and a mesh-fix entry both appear in the SupaVoxel menu. I tested neither a 3MF export nor any automatic repair.

Showing it to a client

Start with matched front, side and back views instead of one flattering angle. Add a note that both welded GLBs are closed but that no slender rib has been dimensioned. Then run a slicer pass and print a physical sample before promising anyone a durable ornament. Where the commission prizes the most delicate visible ribs and minimal local mesh cleanup, Hyper3D Gen-1.5 gives the better result from this input. Where it prizes a finer surface to sculpt on, the smaller solid-volume estimate or a 3MF route to try, SupaVoxel earns the next test — with its triangle defects written on the work order.

Hyper3D's textured PBR asset arrives in a ZIP holding two GLBs. That packaging and any eventual physical print are separate production calls.

Final verdict: watertight is a gate, not a guarantee

Passing it tells you about topology, not durability. Each cat welds into one closed shell with consistent winding and zero nonmanifold edges. In this run Hyper3D takes the finer-looking exposed ribs, cleaner triangles and smaller absolute downward area. SupaVoxel takes finer average sampling and $0.27 in an openly hypothetical solid-resin sum, while carrying measurable sliver and degenerate defects. For a subject this fragile, I would never treat "watertight" as meaning "print-ready," whatever badge the screen shows.

Which one I would use for this job

If the plan is to keep editing the sculpt rather than sell an untested print, run your own bone-cat reference through SupaVoxel and look closely at its dense surface and 3MF option. Put the 7,217 slivers and 19 degenerates in your handoff notes, measure the thinnest ribs, slice whatever format you plan to sell, and print a sample. If all you care about is the delicate skeletal silhouette shown above, the visual win belongs to Hyper3D.

Test setup and known gaps

I uploaded one independently generated source PNG to both tools. Hyper3D Gen-2.5 offered no free download, so every Hyper3D file measurement refers to the separately completed Gen-1.5 textured PBR GLB. The SupaVoxel file tested was the UI's Original size GLB. Coincident UV-split vertices were welded before I compared watertightness, boundary edges, winding and connected shells. Offline renders shared front/side/back camera numbers. For the 120 mm figures I scaled each model's longest bounding-box dimension; potential underside area assumed world Y up and a 45° downward-normal threshold.

The solid-fill numbers assume $35/L resin with no hollowing, waste or supports. I did not verify minimum feature diameter, local wall thickness, gap clearance, slicer support output, a physical print, break strength, 3MF output quality or repeat success. The eight-line scorecard is a decision aid for readers, not a quantitative score.

FLUX 3 Review 2026: Black Forest Labs' Multimodal Video Model, Priced Per Second

Leila Rowe — Wed, 07 Oct 2026 15:49:49 +0000

FLUX 3 is Black Forest Labs’ first multimodal foundation model — video with native audio, images, and action prediction for robotics — built on a new Self-Flow architecture and sold per second of output. I went through the model page, the research post and the pricing sheet to explain what FLUX 3 does, what it costs at each resolution, and where it fits next to the rest of the FLUX family.

Black Forest Labs made its name with FLUX.1 and FLUX.2, image models that became the default open-weight choice for a large slice of the industry. FLUX 3, announced on 23 July 2026, is a different kind of release: one model that “jointly learns from images, videos, and audio within a unified architecture”, with video as the first shipping modality, image “soon”, and an action-prediction head aimed at robots. The claim is that each modality makes the others better. I spent a week with the FLUX 3 model page, the “Real World Models” research write-up, the pricing calculator and the early community output to work out how much of that is real today.

Because FLUX 3 is sold only through BFL’s own per-second API and licensing tiers, I kept a second inference platform that hosts FLUX and other media models on per-image and per-GPU-second billing, Synexa, open in the next tab for comparison — more at the end.

Black Forest Labs pitches FLUX 3 as “one multimodal model” — video with native audio now, images soon, action prediction for robotics.

What FLUX 3 is

FLUX 3 is a diffusion-transformer foundation model trained jointly across images, video and audio. Black Forest Labs’ argument is that no single modality describes the world: images capture spatial structure, video captures time and physics, audio captures causal relationships that vision misses, and language links them. Train on all of them together and you get a model whose generations are “truer to life in every kind of style”. FLUX 3 is also BFL’s first step toward “real-world visual intelligence” — models that perceive, predict and act — hence the robotics head.

FLUX 3 Video: what it can do

Video is the modality you can use today, and the capability list is long:

Text to video, image to video, keyframes — start frame, end frame, or multiple key frames in order.
Up to 20 seconds in one generation, with multiple shots and scenes in one take.
Native audio, optional — multilingual speech with accents and strong lip-sync, effects and ambience generated with the frames.
Video editing — edit an existing clip with a text prompt; everything the prompt does not mention stays as shot.
Video continuation — extend a clip from its final frame with momentum and framing carried forward, and agentic chaining to build longer stories.
Typography that reads as native to the scene, and a stylistic range BFL describes as “far beyond conventional cinematic output”.
Resolutions from HD (720p) to UHD (4K).

The early community reaction on the model page is enthusiastic in a specific way: people praise FLUX 3’s dialogue from vague prompts (“ranting about ai”), multishot cooking tutorials, first-person POV shots and 20-second continuous action sequences. Partners quoted at launch include Nous Research (whose Hermes agent chains FLUX 3 shots into long-form pieces), Picsart, Burda Media, Magnific and Envato.

Draft mode

FLUX 3 ships with a Draft variant: a fast, cheap preview of your prompt. When a draft is right you send it back and FLUX 3 renders the same video at full quality (“Draft Enhance”). Draft is HD-only, and the enhance step is billed as a regular full-quality generation. For iterative work this is the feature that keeps FLUX 3 affordable.

The 23 July 2026 write-up introduces Self-Flow, the alignment approach under FLUX 3, with a Fréchet-distance comparison against flow matching.

Self-Flow: the architecture claim

FLUX 3 builds on Self-Flow, BFL’s approach to aligning multimodal generation and understanding in one architecture. The research post shows Self-Flow beating standard flow matching on generation error (Fréchet distance) per modality and on manipulation-task success after fine-tuning — the latter being the robotics story. Whether that translates into better video than single-modality competitors is something the community is still working out, but the direction — a model that learns physics from video and causality from audio — is coherent.

FLUX 3 pricing: per second, no subscription

BFL sells FLUX 3 with no subscriptions and no seat fees; you pay per second of video output, rounded up to the whole second, with audio included at no extra charge. Rates depend on modality, variant and resolution band:

Text / Image → Video (FLUX 3 Video)

HD: $0.17/s · FHD: $0.29/s · QHD (2K): $0.40/s · UHD (4K): $0.80/s

Video → Video (continuing, extending, editing, restyling)

HD: $0.41/s · FHD: $0.53/s · QHD: $0.65/s · UHD: $0.95/s

FLUX 3 Video Draft: $0.06/s, HD only.

So a 5-second HD clip is $0.85, a 20-second 4K one-take is $16, and extending it in 4K costs $19 for another 20 seconds. Resolution bands are defined by megapixels per frame (HD ≤1.0 MP, FHD ≤2.0 MP, QHD ≤4.0 MP, UHD ≤8.0 MP) regardless of aspect ratio. Enterprise pricing adds volume discounts, SLAs and dedicated support, and separate self-hosting licences (Builder, Platform, Professional, Enterprise, Synthetic Data) cover running FLUX weights on your own infrastructure — though FLUX 3 itself was API-only at launch.

Per-second rates by resolution band, a calculator (5 s at HD = $0.85), and enterprise and open-weights licensing below.

What FLUX 3 gets right

Audio and video from one model, with real lip-sync and multilingual speech.
20-second multi-shot generations and continuation for longer pieces.
Prompt-based editing that leaves untouched frames alone.
Draft mode for cheap iteration.
Transparent pricing — a public per-second rate card with a calculator, no plan to buy.

Where FLUX 3 falls short

4K is expensive. $0.80/s for generation and $0.95/s for video-to-video adds up fast on long clips.
Image modality “soon”. The unified model’s still-image side was not available at launch; FLUX.2 remains the image workhorse.
API-only, closed weights for FLUX 3, in contrast to the open FLUX.1/FLUX.2 lineage.
Rounding. Partial seconds round up, so short clips carry a hidden premium.
Robotics claims are early. Action prediction is a research direction with a “learn more” link, not a product you can buy today.

FLUX 3 vs the alternatives

Against Seedance 2.5, FLUX 3 trades longer single-pass clips (30 s) for a broader stylistic range and a public per-second price. Against Sora-class models, community consensus at launch was that FLUX 3 is “somewhere between Seedance 2 and Sora” with a distinctive look. Against the rest of the FLUX family, FLUX 3 is the video and audio model; FLUX.2 is still where images live — and for images and open-weight FLUX, a per-image host is cheaper than BFL’s own API.

Verdict: is FLUX 3 worth it in 2026?

For anyone producing short video with dialogue, product and brand motion, or agent-driven storytelling, FLUX 3 is worth a serious look: the audio-in-the-model design and 20-second multishot output are real advantages, and Draft mode keeps exploration cheap. Budget carefully above HD. Read the model page and run the official per-second calculator before committing to 4K.

The alternative worth keeping next to it: Synexa

Two FLUX 3 realities pushed me to keep a second platform open: the still-image side is not shipped, so images still come from FLUX.1/FLUX.2, and BFL’s per-second API is the only way to run FLUX 3. Synexa hosts the open FLUX models and other media models on per-output and per-GPU-second billing.

FLUX images at a fraction of the price. FLUX.1 [dev] is $0.0125 per image, FLUX.1 [schnell] $0.0015, FLUX.1 [pro] $0.02 — Synexa’s own comparison table shows 50–60% below the providers it lists.
Video and 3D on the same account — Wan 2.1 video at $0.20 per clip, Hunyuan 3D at $0.025 per model, Stable Diffusion XL at $0.002 per image.
Raw GPU by the second, scaling to zero. H100 at $2.99/hour ($0.00083/s), A100 80GB at $2.49/hour, RTX 4090 at $0.69/hour — run your own FLUX fine-tunes or LoRAs without a self-hosting licence.
Billing on model output, so nothing is charged for a failed run.

Generate the video on FLUX 3. Generate the stills, the 3D assets and anything on open weights through Synexa.

Photo by Daniel Olah on Unsplash