DEV Community: Freya Mensah

OpenArt Product Photo Editor 2026: Truer Labels at 30 Credits an Edit

Freya Mensah — Tue, 20 Oct 2026 15:51:41 +0000

I gave OpenArt and SupaVisual the same phone snapshot and the same e-commerce edit prompt. OpenArt scored higher on the full edit checklist at 11.5/12 versus SupaVisual’s 10/12, but OpenArt charged 30 or 40 credits per edit, stamped both Free-plan downloads with a logo, and returned smaller WEBP files.

I tested a small-shop job: replace a tiled wall and blue cloth without changing two bottles or their labels. The edit checklist favored OpenArt, 11.5/12 to 10/12; SupaVisual charged just 1 credit per edit.

The paid comparison was SupaVisual Hobbyist at $19 for 800 credits, documented at https://supavisual.com, while OpenArt ran on Free for the hands-on files and was priced against Plus at $34 for 12,000 credits when commercial-use costs mattered.

My verdict in 60 seconds — OpenArt 66/100, SupaVisual 82/100

The label-fidelity win did not outweigh 30–40 credits per edit, a logo in the free downloads, and the $34 plan required for commercial use.

My scorecard:

Label fine print kept — OpenArt 9/10 · SupaVisual 6/10 — OpenArt scored 11.5/12 versus SupaVisual’s 10/12
Big label text and caps — OpenArt 9/10 · SupaVisual 9/10 — both kept the 4 visible product details
Background cleanup — OpenArt 9/10 · SupaVisual 9/10 — tiles and blue cloth disappeared in 2 edits each
Credits per edit — OpenArt 3/10 · SupaVisual 10/10 — OpenArt charged 30 or 40 credits versus 1
Speed per edit — OpenArt 8/10 · SupaVisual 6/10 — OpenArt Nano Banana Pro took 29.1 seconds versus SupaVisual’s 62.5 seconds
Watermark on the result — OpenArt 0/10 · SupaVisual 10/10 — OpenArt marked 2 of 2 free edits; SupaVisual marked 0
File download — OpenArt 6/10 · SupaVisual 9/10 — OpenArt returned 0.06–0.10 MB WEBP files; SupaVisual returned 1.83–1.86 MB PNG files
Commercial license — OpenArt 3/10 · SupaVisual 9/10 — commercial use starts at $34 on OpenArt; Hobbyist costs $19

The concrete OpenArt problems:

OpenArt’s default edit cost 30 credits and took 100.8 seconds.
OpenArt’s faster premium edit cost 40 credits, enough for 8 GPT Image 2 images.
The logo was burned into 2 of 2 free downloads, not just the preview page.

If every word of the label must survive untouched, OpenArt's default editor was the more faithful one in my test. For a shop editing product photos every week, I would still use SupaVisual for the bill—and proofread the label on every result.

The input photo, OpenArt edit #1, and SupaVisual edit #1 shown side by side.

The job: turn a phone snapshot into a listing photo

I uploaded the same 597×1200 JPEG on both sides and used this identical prompt:

“Turn this phone snapshot into a clean e-commerce product photo. Keep both bottles exactly as they are, including every label, the red cap on the tall bottle and the gold cap on the small bottle. Replace the tiled wall and the blue cloth with a seamless light-grey studio background, add a soft natural shadow under the bottles, and do not add any other objects or text.”

I scored 6 details per edit: legible “Eau de Eglantine,” retained “75CL” and both cap colors, removed tiles and cloth, and no added objects or text.

The input was a CC0 photo. I checked the edit menu at https://openart.ai and timed Generate to the on-screen result: 100.8 seconds for the first OpenArt edit and 70.1 seconds for the first SupaVisual edit.

The 597×1200 JPEG input photo uploaded unchanged to OpenArt and SupaVisual.

OpenArt Edit Image, default model: 30 credits and 100.8 seconds

I selected Seedream 5.0 Pro in Edit Image’s Describe mode. The balance fell from 40 to 10 credits; the result appeared after 100.8 seconds.

The result kept “Eau de Eglantine,” “75CL,” both caps, and neither unwanted background element: 6/6. Its 800×1424 WEBP weighed 0.10 MB.

OpenArt's 6/6 was the best single edit score. At 30 credits, it cost as many credits as 6 GPT Image 2 images.

The downloaded OpenArt file still had a logo burned into its center. A 6/6 checklist score did not make this Free-plan file storefront-ready.

OpenArt Seedream 5.0 Pro edit #1 after 100.8 seconds, with the balance still displayed at 10.

OpenArt with the premium editor: 40 credits and 29.1 seconds

I tried OpenArt's Nano Banana Pro next. Its 29.1-second result beat SupaVisual’s 62.5-second edit comparison by 2.1×.

That speed cost 40 credits: the balance fell from 40 to 0. The 768×1376 WEBP weighed 0.06 MB and scored 5.5/6.

The OpenArt edit kept the product name, “75CL,” caps, and background. The production and best-before dates did not: characters at the bottom of the label became corrupted. I would inspect that text before publishing.

At 40 credits, this edit cost as many credits as 8 GPT Image 2 images and still had a center watermark.

OpenArt Nano Banana Pro edit #2, a 768×1376 WEBP weighing 0.06 MB with the center logo visible.

SupaVisual: same photo, same prompt, 1 credit

SupaVisual attached the uploaded photo as the only reference image on the generate page and charged 1 credit per edit. SupaVisual’s own image model returned the first result in 70.1 seconds and the second in 54.9 seconds.

The two 1024×1536 PNG downloads weighed 1.83 MB and 1.86 MB. Both kept the product name, “75CL,” both caps, and the light-grey background; each scored 5/6.

The missing checklist point was “no added objects or text.” SupaVisual rewrote the small right-hand label column in both results. One version changed the ingredient wording and inserted an address absent from the input; the other changed the ingredient wording and added storage text.

Exact label preservation was the weakness; each edit still cost 1 credit, against Seedream 5.0 Pro’s 30.

SupaVisual edit #1 after 70.1 seconds, with the balance displayed at 10.

Side by side: the big label details survived

Across all 4 edited files, “Eau de Eglantine,” “75CL,” and both cap colors survived in 4/4. The smaller print separated the results.

The checklist totals were 11.5/12 and 10/12, respectively.

The input photo, OpenArt edit #2, and SupaVisual edit #2 shown side by side.

The fine print: where SupaVisual lost points

The bottle silhouette and studio background survived, but the small right-hand label column was rewritten in 2/2 edits.

Seedream scored 6/6; Nano Banana Pro scored 5.5/6 because its date text became corrupted. Both retained the larger label text and caps.

OpenArt's 1.5-point lead out of 12 is a real win when ingredient and date text matters.

SupaVisual edit #1 close-up showing the rewritten right side of the bottle label.

Background, caps and the big label text

Both tools removed the tiles and cloth in 2/2 edits and retained both cap colors in all 4 files. The large label text and “75CL” also survived in 4/4. Those visible successes do not excuse altered fine print: I would check every label before publishing a listing.

SupaVisual edit #1 preview: the 2 bottles against the replacement studio background.

The watermark lands on the product

The center logo was burned into 2/2 downloaded Free-plan edits: the 0.10 MB Seedream file and the 0.06 MB Nano Banana Pro file.

The OpenArt logo was not a page overlay. Cropping out a logo across the product would damage the composition; neither Free-plan download was a clean listing asset.

Neither PNG had a watermark. They were larger—1.83 MB and 1.86 MB—but clean of the center logo.

The center of the OpenArt edit #1 file with the OpenArt watermark baked into the pixels.

What an edit costs on each side

For commercial use, Plus costs $34 for 12,000 credits; Hobbyist costs $19 for 800. Per edit, that means $0.085 for Seedream 5.0 Pro, $0.11 for Nano Banana Pro, and $0.024 for SupaVisual.

I also checked OpenArt’s Generate-button quotes after uploading the same photo: Change Background showed 40 credits, Image Upscale 25, Expand Image 40, and Image Variations 5. Those were quotes, not completed runs. SupaVisual charges 1 credit per AI action, including an edit, background change, upscale, or expand. One OpenArt Seedream edit used the credits of 6 GPT Image 2 images; one Nano Banana Pro edit used the credits of 8.

Seedream 5.0 Pro edit — OpenArt 30 credits · SupaVisual 1 credit · OpenArt costs 3.57× as much
Nano Banana Pro edit — OpenArt 40 credits · SupaVisual 1 credit · OpenArt costs 4.76× as much
Edits per month — OpenArt 400 Seedream edits or 300 Nano edits · SupaVisual 800 edits · 2× to 2.67× more SupaVisual edits
100 Seedream edits — OpenArt 3,000 credits · SupaVisual 100 credits · OpenArt uses 30× more credits

Annual-billing cards showed Starter at $13, Plus at $27, Pro at $44, and Wonder at $175 per month. The edit comparison above uses monthly prices: $34 and $19.

OpenArt’s annual-billing pricing cards for Starter, Plus, Pro, and Wonder.

Where OpenArt genuinely wins

OpenArt's genuine wins are 11.5/12 label fidelity against 10/12, and Nano Banana Pro’s 29.1-second edit against 62.5 seconds.

OpenArt was quicker on images, too: GPT Image 2 took 20.8 seconds against SupaVisual’s 48.7 seconds (2.3×), and Nano Banana Pro took 26.9 seconds against 48.7 seconds (1.8×). GPT Image 2 wins the per-image price row at $0.014 on Plus against $0.024 on Hobbyist. Its 2 tested images each scored 4/6, though, and both Free-plan WEBP downloads had a center watermark. Nano Banana Pro scored 6/6, a picture-quality tie with SupaVisual’s 6/6, but cost $0.11 per image against $0.024.

The faster edit costs 40 credits and $0.11—4.76× the $0.024 alternative. The 6/6 Seedream edit costs 30 credits and takes 100.8 seconds; SupaVisual’s comparison figure is 1 credit and 62.5 seconds.

OpenArt's 0.06 MB WEBP is easier to transfer than the 1.86 MB PNG; its center logo is a worse trade for a listing.

OpenArt Seedream 5.0 Pro edit #1, an 800×1424 WEBP weighing 0.10 MB.

Final verdict: OpenArt scores 66/100 for product-photo edits

Label preservation favors OpenArt, 11.5/12 to 10/12; Seedream alone reached 6/6. Nano Banana Pro also produced the faster edit at 29.1 seconds.

For repeated work, the charge is 30–40 credits per edit against 1. At the commercial-use plan prices, a Seedream edit costs $0.085 against $0.024.

Both OpenArt Free-plan WEBP edits carried a center watermark; neither 1.83–1.86 MB PNG did. The WEBPs were smaller at 0.06–0.10 MB.

SupaVisual edit #1, a 1024×1536 PNG weighing 1.83 MB.

Which one I would use for this job

If tiny label text outweighs cost, I would consider OpenArt's Seedream 5.0 Pro: 30 credits, 100.8 seconds, and 6/6. Its Free-plan download still has a center watermark.

For a commercial shop making 40 images and 120 edits monthly, I would pick SupaVisual: 160 credits on Hobbyist at $19, versus 3,800 credits on Plus at $34 with GPT Image 2 and Seedream edits. I would still inspect the label: its small right column changed in 2/2 edits.

For the OpenArt GPT Image 2 and Seedream route, the arithmetic is 40 × 5 + 120 × 30 = 3,800 credits. Starter’s 4,000 credits cover that count, but its $14 plan excludes commercial use, so the shop needs Plus at $34. SupaVisual’s 40 × 1 + 120 × 1 = 160 credits fits Hobbyist’s 800 at $19. Serial stopwatch waiting is about 3.6 hours for the OpenArt route against 2.6 hours for SupaVisual. Choosing OpenArt Nano Banana Pro for both images and edits changes the credit count to 6,400 on Plus at $34 and cuts serial waiting to about 1.3 hours against 2.6 hours.

The product page is https://supavisual.com.

SupaVisual edit #2, a 1024×1536 PNG weighing 1.86 MB.

Higgsfield Pricing Review 2026: The $59 Credit Allocation Trap

Freya Mensah — Sun, 18 Oct 2026 15:52:29 +0000

Two public $59 monthly plans each list 1,200 credits. That symmetry does not make their credits fungible, their Tokyo videos equivalent, or the arithmetic below an actual per-clip invoice.

Independent review: both products were run on my own accounts — a free tier and a paid plan — with no vendor-provided access.

My verdict in 60 seconds

The October 1, 2026 public snapshot shows Higgsfield Plus at $59 billed monthly for 1,200 Higgsfield credits and Kyncept Pro at $59 per month for 1,200 Kyncept credits. This test consumed nine of the former for one 5.042-second Higgsfield video and ten of the latter for each 8.000-second Kyncept video. If—and only if—a subscriber fully uses the credit bundle at its stated monthly price, simple allocation assigns $0.4425 to the observed Higgsfield task and about $0.4917 to a Kyncept task. Neither number is cash charged for this trial, a transaction price promised at checkout, or the cost of the same length and quality of video.

Monthly price basis — Plus $59/1,200 and Pro $59/1,200, separately stated in each product's own units.
Observed video debit — Higgsfield nine credits, Kyncept ten credits per completed job.
Video delivered — Higgsfield 5.042 seconds at 1904×1104; Kyncept 8.000 seconds at 1280×720.
Observed image debit — Higgsfield two credits per Nano Banana Pro image; Kyncept one credit per Nano Banana Pro image.
Critical omission in any one-number “winner” — the Kyncept video set contains three visually near-repeat outputs, while Higgsfield has only one Tokyo video for this case.

The case's raw ledger and price-provenance record separate observed usage from hypothetical dollar allocation.

Anonymous public Higgsfield pricing page with its Monthly switch selected; Plus displays $59 billed monthly and 1,200 credits per month.

The limit of this comparison

Kyncept's public pricing and Higgsfield's public pricing were checked in an anonymous browser, and both price screenshots were inspected before archiving. This is not financial or product advice. No purchase, card entry, fresh registration or checkout confirmation was made. The exact price a particular customer pays after taxes, geography, discounts or account-specific entitlements was not established.

The actual test ran on existing credit balances. No dollar amount was deducted per generation in the visible record. Assigning a share of a monthly subscription to one task is a modeling choice, not a reconstructed bank statement. That distinction is the premise of the article rather than fine print at the end.

Kyncept's anonymous public pricing page: Pro $59 per month and 1,200 Kyncept credits per month. Its Starter first-month offer is separate from the recurring price.

The price snapshot, not an old rate card

The Higgsfield monthly card showed Starter $19/270 credits, Plus $59/1,200, and Ultra $129/3,000. The comparison uses Plus, not Starter: the Starter copy describes access to selected models and the case did not verify whether Wan 2.5 Fast belongs to that tier. The page also displayed an annual Plus figure of $47 per month billed annually; this article does not pair an annual commitment with Kyncept's monthly price.

Kyncept's public card showed Starter $9 for its first month, then $19/month, with 400 credits/month. Pro displayed $59/1,200; Business displayed $149/3,000 at the visible slider position. Neither a temporary introductory month nor a larger-business feature list belongs in a like-for-like monthly Pro/Plus calculation. These are a dated, anonymous public-page observation, not a guarantee that the same figures remain on a future publication day.

A page showing “all models” is also not a completed checkout or a test of every model entitlement. The Plus and Pro plan copy supports the broad comparison of listed bundles; the actual Tokyo balances support the separate record of usage. Both facts are needed, and neither should be silently substituted for the other.

What the Tokyo jobs actually consumed

The successful Higgsfield Wan 2.5 Fast job took the video account from 10 to 1: nine Higgsfield credits, one resulting MP4. Its UI selected five seconds and 720p, and the downloaded file measured 5.042 seconds and 1904×1104. The submitted text requested eight seconds, but the menu did not. A neighboring “Failed / Credits refunded” badge belonged to another task and was not the status of this Tokyo job.

The three successful Kyncept Plus jobs moved the balance 343→333→323→313. That is ten Kyncept credits per job and three 8.000-second, 1280×720 MP4s. The three look unusually similar in this case, which changes what “three outputs” might be worth to someone seeking three creative alternatives. It does not change the arithmetic of the visible deductions.

The Higgsfield interface choice was five seconds and 720p. The resulting source file has its own measured pixel dimensions.

The anonymous pre-run wallet shows ten Higgsfield credits and a nine-credit Generate action.

The visible Higgsfield balance is one after the Tokyo completion, versus ten before it.

Kyncept's first completed Tokyo result. The remaining two jobs are separate successful charges, not extra cuts from this one job.

The allocation formula has an assumption in its denominator

A subscriber paying the displayed $59 for 1,200 Higgsfield credits has an internal list-price allocation of $59 ÷ 1,200 = about $0.04917 per Higgsfield credit, provided that the subscriber can use the entire bundle. Nine such units allocate $59 × 9 ÷ 1,200 = $0.4425 to the one observed Higgsfield video.

Independently, $59 for 1,200 Kyncept credits produces the same numerical internal allocation of about $0.04917 per Kyncept credit under the same full-use assumption. Ten Kyncept units allocate $59 × 10 ÷ 1,200 = $0.49167 to each observed eight-second video. The equal numerical unit rates happen to follow from these two particular public monthly plans. They do not mean a Higgsfield credit can buy a Kyncept generation, or that the resulting videos are interchangeable.

This is proportional accounting for an included bundle. If a subscriber makes only one video all month and pays solely for that subscription, the actual subscription outlay is still $59, not $0.44 or $0.49. If the subscriber also uses the credits for other tasks, the cash cost must be allocated across those tasks by a stated method. The trial itself used available balances and did not measure a $59 payment.

What changes at 30 jobs a month

A hypothetical month of 30 copies of the tested Higgsfield settings would use 30 × 9 = 270 Higgsfield credits. A hypothetical month of 30 copies of the tested Kyncept settings would use 30 × 10 = 300 Kyncept credits. Both totals fit within their respective 1,200-credit monthly bundles; 930 Higgsfield or 900 Kyncept credits would remain if nothing else were generated. Both subscribers still face the listed $59 monthly plan price in this deliberately narrow scenario, not a new charge of $13.28 versus $14.75 at month-end.

The proportional figures $59 × 270/1,200 = $13.275 and $59 × 300/1,200 = $14.75 describe only shares of prepaid bundle capacity. They are useful for internal planning if other work consumes the remaining capacity; they are misleading as statements of actual bills. Equally important, 30 short Higgsfield selections would not supply the same total seconds as 30 eight-second Kyncept files, and this case has not tested 30 successful submissions on either service.

Another completed Kyncept job, not evidence that a 30-job month was actually run.

A fully used bundle is a ceiling on count, not on creativity

Under the narrow assumption that every included credit can go to the exact tested job with no additional charges, 1,200 ÷ 9 funds at most 133 complete Higgsfield five-second jobs, leaving three credits. 1,200 ÷ 10 funds 120 complete Kyncept eight-second jobs, leaving none. Those numbers are capacity arithmetic, not measured production volumes, not identical runtime delivered, and not a promise that either product will always offer the same settings at the same debit.

The observed Kyncept pairwise video SSIM values—0.988805, 0.988757 and 0.988794—are a reason to distinguish completed jobs from distinct usable edits. They describe three runs of one prompt, not the diversity of 120 different prompts. Higgsfield's one completed Tokyo file cannot be scored on repeat diversity at all. Any “120 versus 133 useful videos” claim would overstate both sides of this exercise.

The first Kyncept sequence supplies the visual basis for the repeatability caveat in the capacity math.

The second sampler is close to the first; the full files are different, but both count as completed jobs.

Images are a clearer same-model allocation example—with limits

The same Tokyo study also generated two Nano Banana Pro images per product, with the displayed model name and prompt aligned. Higgsfield debited two of its credits per PNG, with balances 6→4→2. Kyncept debited one of its credits per JPEG, 313→312→311. At the two selected $59/1,200 bundles, the hypothetical full-use allocation is about $0.09833 per Higgsfield image and $0.04917 per Kyncept image. This is an illustration of each plan's own rate times each platform's own observed debit, not a cross-platform credit exchange.

The four originals each measure 1376×768, and this tester's visual assessment of this small sample is that content quality is broadly a tie. It is not a blind perceptual study. Higgsfield's two originals have a visible baked-in brand watermark; neither of the two inspected Kyncept originals showed one. But Higgsfield wrote PNG and Kyncept JPEG: a smaller compressed file is not automatic evidence of a better or worse picture. Eligibility for watermark-free export on other plans was not tested.

The first Higgsfield Tokyo image viewed in its result context; its archived raw PNG retains the visible brand mark.

The first Kyncept Tokyo image viewed in its result context; the archived raw JPEG was checked separately.

The second Kyncept Tokyo image also completed; the two images are separate one-credit jobs.

Why output seconds and usable variants remain outside the price tag

One Higgsfield video delivered 5.042 seconds; each Kyncept video delivered 8.000 seconds. The Higgsfield file has 1904×1104 source pixels despite its 720p UI selection; Kyncept's are 1280×720. More pixels and more seconds measure different axes, and neither captures scene quality, editability, successful execution under other prompts, or the cost of redoing a near-repeat. This is why choosing the smaller of $0.4425 and $0.4917 as a “winner” would be a category error.

There are additional unknowns: plan entitlements can change; promotional unlimited periods and account-specific offers can alter effective usage; local taxes and currency conversion are absent; and a user may leave credits unused. Public pages disclose some features, but this trial did not purchase a plan to validate invoice totals or commercial rights. For this case the auditable conclusion is the method and its conditions, not an unqualified price-performance crown.

Final verdict: the allocation is useful only when labeled

At the observed public monthly bundle prices, the single tested Higgsfield job allocates $0.4425 and the tested Kyncept job about $0.4917 if the separate 1,200-credit bundles are fully used. That is an honest budgeting line, not a receipt and not a comparison of equal-length, equal-resolution or equally varied outputs. A different billing cycle, model choice, unused balance or publication date can change the calculation. The first price sentence in any reuse of these figures should include the assumption, not put it in a footnote.

Which one I would use for this job

I would use the case evidence to select the output I actually need, then recalculate against the current plan in my own account. For a longer eight-second Tokyo take, Kyncept's current site shows the Pro context; for a five-second Higgsfield take, its public Plus card is the price basis here. Neither product was proven universally less expensive per usable edit. Recheck the pricing page immediately before paying; no payment was made for this analysis.

Tripo GLB Export Review 2026: 57.6 MB for One Glasses Stand

Freya Mensah — Fri, 16 Oct 2026 15:44:59 +0000

Independent review. I ran both tools on my own accounts, free and paid, with no vendor-provided access or early access of any kind.

My verdict in 60 seconds — Tripo 65/100, SupaVoxel 88/100

This is the article where SupaVoxel loses the visual comparison, so it goes in the first line. I put one image of a sculptural face glasses stand — an S-swept plate with a human profile carved into its left edge, on a round base — into Tripo and into SupaVoxel, then rendered both downloaded GLBs offline under identical lights and cameras, pairs side by side. Tripo holds the profile better, visibly. Tripo's nose tip resolves to a real point, its notch beneath the nose is a narrow deep V, its lip step is a hard edge, its chin undercut is a defined cut. SupaVoxel rounds the nose tip into a blunt ball, turns the notch into a shallow U, softens the lip step and curves the chin undercut. All five features — brow, nose, upper lip, lower lip, chin — stay individually readable on the SupaVoxel mesh. Every one is a grade softer. A loss, and no ratio makes it not a loss.

What the rest of this article measures is what that grade weighs. 57,621,648 bytes against 4,664,668.

GLB size — Tripo 57,621,648 B (57.62 MB) · SupaVoxel 4,664,668 B (4.66 MB) · 12.4×
Bytes per triangle — Tripo 30.39 B · SupaVoxel 4.87 B · 6.2×
Texture set — Tripo 3 × 4096, 3,944,428 B · SupaVoxel 3 × 2048, 164,616 B · 24.0×
baseColor map — Tripo 1,271,467 B · SupaVoxel 78,018 B · Tripo wins this row outright
Maps a white print never reads — Tripo 2,672,961 B (67.8% of its textures) · SupaVoxel 86,598 B
Download on 12 Mbps 4G — Tripo 38.4 s · SupaVoxel 3.1 s
CDN at 10,000 loads/month, $0.085/GB — Tripo $48.98 · SupaVoxel $3.96
Geometry VRAM estimate — Tripo 53.7 MB · SupaVoxel 27.2 MB

Four things that decide this case:

The sharper nose tip is real and it is Tripo's. I show it at maximum magnification below, in the pair where the SupaVoxel loss is largest.
It is not resolution. Tripo ships 1,896,372 triangles against SupaVoxel's 958,552 — 1.98× — and at 120 mm Tripo's mean triangle edge is 0.1339 mm against 0.1904 mm. Both already beat a 0.4 mm nozzle. The extra 937,820 triangles do not resolve the notch; a harder crease does.
67.8% of Tripo's texture payload is metallicRoughness and normal maps: on a white printed part, 2,672,961 bytes you download and delete.
Neither product invented the back half. No ears, no hair, no skull either side. 55 Tripo credits bought nothing on the half the camera never saw.

Coloured render or product image? Tripo's 4K basecolor and harder edges are worth buying, and I say so again at the end. A file that has to move — into a browser, across 4G, off a CDN? You are paying 12.4× the bytes for one nose tip.

The test: one image, two exports, one set of cameras

The single input both products received: a 359,638-byte PNG, sha256 0f736f93…. Two things about the subject. The plate is a deliberate S-shaped sweep, not a flat slab — the front-back variation you see is the design. And the reference shows the stand empty: on this design the carved nose is the crossbar the glasses rest on, so no separate bar in frame is correct.

The two exports land in different world orientations, so my offline render script offsets each one by its own yaw. Every pair below is genuinely the same viewing angle, not two flattering picks. Same lights, same lens, same background.

The pair that decides it: Tripo's nose tip is sharper

Tripo at maximum magnification along the carved edge: nose tip an actual point, notch a narrow V, a hard step between the lips, a defined undercut below the chin. The most honest image in this comparison — better than SupaVoxel's, needing no explanation.

SupaVoxel, same position and magnification. Forehead into nose bridge runs smooth, then the nose tip closes into a blunt ball. The notch is a shallow U, the lips read as soft pads rather than a step, the chin undercut is an arc. All five features present, all five softer.

Nose tip — Tripo point · SupaVoxel rounded ball
Notch under the nose — Tripo narrow deep V · SupaVoxel shallow U
Lip step — Tripo hard edge · SupaVoxel soft pads
Chin undercut — Tripo defined cut · SupaVoxel arc
What it cost to buy that — 52 extra credits and 52,956,980 extra bytes, on a mesh whose winding still comes back inverted

That last line is the trade ratio, and the reason this case is close rather than decided. Tripo is better here — better by an amount you can see at 120 mm if you lean in — and Tripo charges 18.3× credits and 12.4× bytes for it.

The silhouette pair, at the size where the loss is biggest

Tripo's wireframe at 1,896,372 faces renders as a black mass — worthless as wireframe evidence, and I will not argue topology from it. As a silhouette it is the sharpest thing in this article: pointed nose, narrow V notch, right-angle lip step.

SupaVoxel at 958,552 faces, same black mass, same silhouette-only reading: round nose tip, shallow notch, soft lip step.

I kept this pair because it magnifies the defeat rather than hiding it. Do not read edge flow from either image — at these face counts there is none to read.

Where the 57.6 MB actually goes

Tripo under the key light: 1,896,372 faces, 57,621,648 B, three 4096² textures totalling 3,944,428 B. Faint horizontal banding runs across the plate face and the base disc rim.

Geometry + everything else — 57,621,648 B total, of which 3,944,428 B is texture
Bytes per triangle — 30.39 B against SupaVoxel's 4.87 B
glTF extensions used — Tripo KHR_materials_volume, FB_ngon_encoding; extensions_required empty
SupaVoxel — EXT_meshopt_compression and KHR_mesh_quantization, both in extensions_required

That last row is a real mark against SupaVoxel and belongs here, not in a footnote. Tripo's file requires nothing, so it opens anywhere; SupaVoxel's requires two extensions, so an older viewer can fail and you validate before shipping. The 6.2× gap in bytes per triangle is largely those extensions doing their job — 958,552 faces and three 2048² textures inside 4.66 MB — and the price is one compatibility check.

The SupaVoxel file, same light, same camera

SupaVoxel under the identical key light: 958,552 faces, 4,664,668 B, three 2048² textures totalling 164,616 B. As a white part the plate is clean — no undulation, no seam glare.

Triangles — Tripo 1,896,372 · SupaVoxel 958,552 · 50.5% of Tripo's count
Vertices — Tripo 966,210 · SupaVoxel 490,680
Extra triangles Tripo ships — 937,820 · new features they buy in this white render: none visible
What they do buy — the sharper nose crease, and that faint horizontal banding across the plate face

Nearly a million extra triangles, and the visible return is one crease sharper on one edge, plus banding the other surface does not have. Those triangles are not worthless — they are where Tripo's crease came from. The exchange rate is what is bad.

Texture bytes: the row Tripo wins, and the row it loses

Tripo's export dialog. Texture Resolution defaults to 4k (Current). That default is where most of the 57.62 MB comes from.

Won by Tripo:

baseColor — Tripo 4096², 1,271,467 B · SupaVoxel 2048², 78,018 B · 16.3× more colour data

If you are going to light, colour or re-render this model, that is genuine material and SupaVoxel does not match it.

Lost by Tripo:

metallicRoughness + normal — Tripo 2,672,961 B · SupaVoxel 86,598 B
Share of Tripo's texture payload that a white print never reads — 67.8%
Total texture bytes — Tripo 3,944,428 B · SupaVoxel 164,616 B · 24.0×

So Tripo attaches 3.94 MB of maps, of which 2.67 MB goes inert the moment the output is a white part. SupaVoxel attaches 0.16 MB. Which is right depends entirely on your output, and this is the row where I genuinely tell some readers to choose Tripo.

Same-camera sweep: everything except the profile is a tie

SupaVoxel from the front. Brow, nose, upper lip, lower lip and chin read as separate forms, nothing collapsed into a lump. The nose tip is round.

Tripo from the front, same camera. Pointed nose tip, deeper narrower notch, harder lip step. And along the plate face and base disc edge, a faint horizontal ripple the other surface does not have.

Top view, SupaVoxel. The plate reaches past the disc; the three notches along the carved edge — under the nose, between the lips, under the chin — read from above, just rounder and wider.

Top view, Tripo, same camera. The footprints all but overlap — 50.6 × 56.24 mm against 57.9 × 50.07 mm, the same shape rotated 90° — and Tripo's three notches are narrower and sharper. Same story, fourth angle.

The geometry underneath the profile is the same object twice:

Solid volume at 120 mm tall — Tripo 43.67 cm³ · SupaVoxel 44.79 cm³ · 2.6% apart
Cross-section depth, 13 height bands — within about 1 mm at 10 of 13
Base disc roundness error — Tripo 0.8% · SupaVoxel 0.4% · 0.2 mm on a 25.2 mm mean rim radius
Bottom face flatness — Tripo 0.796 mm · SupaVoxel 0.798 mm

Both backs are empty, and that is the fair result

SupaVoxel from behind — the half the input never showed. Nothing invented: no ears, no hair, no skull, just the profile swept through the plate and closed with a smooth rear arc. The faint seam on the upper hook is real; the printability article covers the topology count behind it.

Tripo from behind, same camera, same answer. No ears, no hair, no skull. Its rear arc carries a few shallow undulations the other does not.

Neither product hallucinated. On the one part of the object where a generative tool has room to invent, both declined, and Tripo's 55 credits bought no more imagination than the other file's 3.

What 12.4× costs when the file has to move

Bytes stop being an abstraction the moment the model leaves your disk:

12 Mbps 4G, one file — Tripo 38.4 s · SupaVoxel 3.1 s · 35.3 s of difference per view
100 Mbps home, one file — Tripo 4.6 s · SupaVoxel 0.37 s
CDN at 10,000 loads/month, $0.085/GB — Tripo $48.98 · SupaVoxel $3.96 · $45.02/month
Geometry VRAM — Tripo 53.7 MB · SupaVoxel 27.2 MB (vertices × 32 B + indices × 4 B, textures excluded)
A batch of 100, total download — Tripo 5.76 GB · SupaVoxel 0.47 GB

Put Tripo's 57.62 MB on a product page and a phone visitor stares at a spinner for 38 seconds — the sharper nose tip arriving one nose tip at a time, at $48.98 a month per ten thousand views.

Both product panels told the truth about their own numbers

SupaVoxel's result page reports Triangles 958,552; the parsed GLB reports 958,552. Four inspection modes sit side by side — Textured / Mesh / Wire / Normals — and the size readout below carries mm / in / raw.

Tripo's completion screen reports Triangle / Faces 1896372 and Vertices 966210. Also exact against the parsed GLB.

Neither panel inflated anything, which deserves saying in a category where panel numbers are often decorative. What they do not tell you is unequal: SupaVoxel has a Normals mode and a version selector, Tripo a material strip. Not captured either side: the export format list — both exported GLB only — and the SupaVoxel export click count.

Final verdict: Tripo scores 65, and it earned the profile row

Tripo produced the better-looking model of this subject. Nose tip, notch, lip step, chin undercut — four features, four wins, visible at magnification with no measurement. Tripo's 4K basecolor carries 16.3× the colour data, its file requires no glTF extensions, its panel numbers are exact. All of that has its own space above, not a line of regret at the bottom.

The bill is 57,621,648 bytes against 4,664,668 — 12.4× — and 55 credits against 3. Underneath the profile these are the same object: 2.6% apart in volume, within about 1 mm at 10 of 13 depth bands, two true circular bases, two flat bottoms. Nearly a million extra triangles a 0.4 mm nozzle cannot cash. 2,672,961 bytes of maps a white print never reads. And on a phone, 38.4 seconds against 3.1.

Use Tripo when the output is coloured — a render, a product shot, an asset that gets lit — and you want the 4K basecolor and the harder edges, and neither the credits nor the megabytes are constrained.

Use SupaVoxel when the file has to move, or when there is more than one of them.

Which one I would use for this job

If the file has to move, I would ship the 4.66 MB one: 3 credits, three 2048² textures, 3.1 seconds on 4G against Tripo's 38.4, and $3.96 a month on a CDN against $48.98. Its nose tip is rounder — the trade, stated in the first line and unmoved. I would also validate its two required glTF extensions against the target viewer before shipping; that caveat is real. supavoxel.com is where I ran that half of the test.

Meshy AI 3D Review 2026: The Wrench Jaw at 2x, Frame by Frame

Freya Mensah — Wed, 14 Oct 2026 15:51:15 +0000

Independent review: both products were tested on my own accounts — free where offered and paid where not — with no vendor-provided access.

There's a moment on every product page where somebody pinches the screen and zooms.

That's the moment a 3D model either holds up or falls apart.

I had one photo of a brushed-steel adjustable wrench and needed a 3D version of it. Asking around got me the same two answers every time — Meshy and SupaVoxel — so I ran the same picture through both and then did the only test that matters: I zoomed in until it hurt.

My verdict in 60 seconds — Meshy 62/100, SupaVoxel 88/100

Those scores are my opinion about this one job. The pictures below are the evidence, all shot at the same camera angles and the same crop boxes.

Detail carved as shape, not painted on — Meshy 199,434 triangles vs SupaVoxel 1,500,000 · Meshy 6/10 · SupaVoxel 9/10 — Meshy runs out of surface and starts leaning on the texture; SupaVoxel has roughly 7.5× as much to carve the knurl and the groove lip out of
Points holding the shape together — Meshy 111,498 vertices vs SupaVoxel 816,916 · Meshy 6/10 · SupaVoxel 9/10 — Meshy's sparser points are what round off the edges in the crops below; SupaVoxel keeps those corners as corners
The wheel recess at 2× — Meshy soft, blurring ridges vs SupaVoxel harder ridges with visible gaps · Meshy 6/10 · SupaVoxel 9/10 — Meshy's knurl smears together under magnification; SupaVoxel keeps light and shadow between the ridges, which is what makes it read as metal
The handle groove edge up close — Meshy softened lip vs SupaVoxel crisp lip · Meshy 6/10 · SupaVoxel 9/10 — Meshy rounds the one edge that runs the length of the tool; SupaVoxel holds it sharp all the way down
What the model weighs while looking better — Meshy 11,603,384 bytes vs SupaVoxel 8,842,180 bytes · Meshy 6/10 · SupaVoxel 9/10 — Meshy charges you 2.76 MB more for the softer model; SupaVoxel is sharper and smaller at the same time
Deliverables from the one run — Meshy 1 GLB vs SupaVoxel 2 GLBs · Meshy 7/10 · SupaVoxel 9/10 — this Meshy run gave me one file to work with; SupaVoxel had a compressed 8,842,180-byte GLB and a full 68,718,876-byte original-size GLB waiting together
Textures baked into the file — Meshy 3 vs SupaVoxel 3 · Meshy 7/10 · SupaVoxel 7/10 — a real tie, and a useful one: the sharpness gap in the crops isn't one tool shipping more image files
True colour with the lights off — Meshy grey-silver vs SupaVoxel grey-silver · Meshy 8/10 · SupaVoxel 8/10 — level: neither one turned your brushed steel into plastic, so the dark look in the lit shots is the lighting, not either tool's texture

Four things worth knowing before you scroll:

Meshy builds this wrench out of 199,434 triangles. At arm's length that's plenty. At 2× it isn't.
Meshy's back side can't be graded by anyone, including me. The photo never showed it.
Meshy keeps the jaw faces smooth, exactly like the real thing. The denser file invents a serration. That's a point for Meshy and it gets its own section further down.
Both files come back dark under the same lighting. That's the lighting, not Meshy.

For a product shot that people are going to zoom into, SupaVoxel is the file I'd ship — it came from https://supavoxel.com and it survives magnification better.

One image, one run on each side. Not a lab study.

First question: does it even look like the photo?

The only input: one photo of a brushed-steel adjustable wrench, jaw open, knurled adjusting wheel, groove down the handle, hang hole at the end.

Everything either tool knows about this wrench is in that frame.

Which means the back, the inside of the jaw throat, and the far end of the screw all had to be invented. By Meshy and by SupaVoxel alike.

Half the "flaws" people report in 3D generators are just parts the photo never showed.

Straight on, both pass. Now lean in.

Meshy from the front: head, jaw opening, groove, hang hole — all there.

SupaVoxel from the identical camera. The two files sit a little differently in frame, so compare shapes rather than pixels.

Credit to Meshy: this is the wrench. Head proportion, handle taper, the oval relief, the ring at the end. Meshy got the object, not a vague impression of it.

At this size you would happily put either one on a page.

So the interesting question isn't "does Meshy work". It's "how far can you zoom before it stops working".

The close-up test: what's still there at 2×?

Meshy, right in on the handle and the wheel recess.

SupaVoxel at the identical close-up angle. Harder edges around the recess, brighter metal visible between the ridges.

Here's where it separates.

Meshy's groove edge goes soft. The ridges on the wheel lose their corners and start to blur together. The SupaVoxel file keeps the edges crisp and keeps real contrast between the tops of the ridges and the gaps behind them.

That's what those triangle counts actually mean in practice. Meshy has 199,434 flat plates to build every surface out of; the other file has 1,500,000. When you magnify, the file with more plates has more to show.

Here's the scenario that made me care. A customer lands on the listing, spins the wrench, and pinches in on the adjusting mechanism — because that's the part they're actually buying. On a hardware product, the mechanism is the sales pitch.

At that zoom level, Meshy's softened ridges read as "render", and the crisper ones read as "photo of a real tool". Same wrench, same photo, same afternoon. The only thing that changed is how much geometry Meshy had to spend versus the other one — 199,434 plates against 1,500,000.

If your product is a flat panel or a plain box, Meshy's budget is fine and you can stop worrying. It's the knurls, threads and fine edges where Meshy runs out of road.

Meshy's model looks great until the exact moment your customer decides to inspect it.

The knurled wheel is the hardest thing in the frame

Meshy's adjusting wheel, blown up 2× from a fixed crop box.

The same crop box and blow-up on the SupaVoxel file. It sits lower in frame because the two files carry different internal orientations.

Look at the real wrench and the wheel has a fine knurl — lots of shallow ridges, tightly packed.

Meshy turns that into a handful of coarse bands. So does SupaVoxel, honestly. Neither one gives you a true knurl from a single photo, and I'm not going to pretend Meshy failed at something its rival nailed.

What both do get right: the wheel is modelled as a real recess with real geometry, not painted onto a flat surface. That's the difference between an object your customer can rotate and a sticker.

And when you compare the two recesses side by side, Meshy's is the shallower, softer one.

The view that actually goes on the page

Meshy's three-quarter hero. Three textures baked into an 11.60 MB file.

The SupaVoxel hero at the same angle. Three textures too — in an 8.84 MB file.

Both bake in three textures, so that row is a genuine tie.

But look at what the two files weigh. Meshy: 11,603,384 bytes. SupaVoxel: 8,842,180 bytes.

The file with roughly seven and a half times the detail is also 2.76 MB smaller to download. On a phone that's 5.9 seconds of waiting instead of 7.7.

You normally trade detail for weight. Against Meshy, this time, you don't have to.

The side nobody photographed

Meshy's back face — a surface the input photo never showed.

SupaVoxel's back at the same angle. Also invented, also ungradeable.

This is the part of the review where I'm supposed to say Meshy got the back wrong.

I can't. Nobody can. There is no correct answer for the back of this wrench, because the photo doesn't contain one.

What I can say is that Meshy's invented back is clean: the groove carries through, the wheel recess opens on both sides, no holes, nothing collapsed. Meshy didn't panic when it ran out of information.

If you need a verified back, take a second photo. No amount of triangles replaces one.

One run, two files to hand out

There's a second thing in SupaVoxel's favour that has nothing to do with the crops, and it only showed up at the export step.

One generation produced two finished files. The compressed 8,842,180-byte GLB is the one that goes on the page — it's behind every close-up in this article. The original-size export is the complete, unsqueezed version at 68,718,876 bytes, with textures stored as PNG rather than the compressed build's WebP. Bigger, naturally: nothing has been compressed out of it.

That's handy when the same wrench has two audiences. Marketing wants the light file for the listing. The engineer who asks for "the real model" wants the full one. Both were sitting in the same menu, from the same job.

You choose per destination, not per generation — no re-run, no conversion tool, no going back to the start screen.

Where Meshy actually wins

Meshy's jaw at 2×, from the same crop box used on both files. Smooth faces, like the photograph.

The SupaVoxel jaw, same crop box. Notice the serrated strip along the lower face — the real wrench doesn't have that.

Here's the row that goes to Meshy, and it's a good one.

In the photo, both jaw faces are smooth machined steel. Meshy kept them smooth. The denser file added a gripping serration that simply isn't on the real tool.

More detail is not the same thing as more accuracy. Give a model 1,500,000 triangles and you've given it more room to describe the object — and more room to make things up.

Two more in Meshy's column while we're here. Meshy's file asks nothing special of your 3D software, while the compressed SupaVoxel file needs a decoder called meshopt before it will open — switch to SupaVoxel's original-size export from the same menu and that decoder isn't needed either. And Meshy's geometry wants about 6.0 MB of memory against 44.1 MB, a 38.1 MB gap in Meshy's favour — on a cheap phone, that's the row that decides it.

If your software is fussy or your device is slow, Meshy is the right answer and the crops don't change that.

The numbers behind everything you just looked at

Pictures are the argument in this article, but every one of them is backed by a number out of the file. Here's the whole set, both sides, including the gaps.

Triangles. Meshy 199,434 against 1,500,000. That's the single number that explains every close-up above — how much shape each tool had available before it had to start painting detail on instead of building it.

Vertices. Meshy 111,498 against 816,916. Same story from the other direction.

Textures baked in. Three on Meshy, three on SupaVoxel. So the sharpness difference in those crops isn't "one of them shipped more images" — it's geometry.

File size. Meshy 11,603,384 bytes against 8,842,180. The denser file is the smaller download.

Format. GLB both sides — one file with shape and textures inside, openable without converting anything.

Credits the job recorded. Meshy 35, SupaVoxel 3. Two different plans, two different units. Not a price comparison.

Run time. SupaVoxel 215.462 seconds. Meshy didn't record one, so there's no speed claim anywhere in this article.

Retries. Zero and zero — Meshy needed no second attempt, and neither did the other one.

Failures. Not recorded on either side, so nobody gets a reliability verdict out of this.

Required extensions. Meshy: none. SupaVoxel: EXT_meshopt_compression and KHR_mesh_quantization.

The alternative export. SupaVoxel also offers this wrench at original size — 68,718,876 bytes, no special requirements, textures as PNG rather than the compressed build's WebP. Meshy wasn't run in a second export mode, so there's no number to put beside it.

Three blank rows. They stay blank.

The sums, and what I assumed to get them

Nothing below came off a stopwatch or out of a profiler. It's arithmetic on the measured numbers, written out so you can redo it.

Download on a phone: bytes × 8 ÷ 12,000,000, assuming a steady 12 Mbps and ignoring handshakes, decoding and caching. Meshy 7.7 seconds, SupaVoxel 5.9.

Download at a desk: same sum at 100 Mbps. Meshy 0.93 seconds, SupaVoxel 0.71. On fibre this whole row stops mattering.

A hundred of them on disk: this file × 100. Meshy 1.16 GB, SupaVoxel 0.88 GB. A capacity sketch, not a hundred real jobs.

A hundred runs on each meter: Meshy 3,500, SupaVoxel 300 — each in its own units, still not a price ratio.

Memory the geometry wants: 32 bytes per vertex plus 4 bytes per triangle index, textures excluded. Meshy 6.0 MB against 44.1 MB. Meshy wins that by 38.1 MB, and on a phone juggling several products it's the row that decides whether the page survives.

And one thing I did not do: import either file into a specific piece of 3D software. The extension requirements above are read out of the files — what each one declares it needs — not a record of what opened and what didn't.

Every figure in this section is arithmetic on measured bytes and counts. Change the assumptions and the numbers move; the files don't.

Is that dark, flat look a Meshy problem?

Both wrenches come back looking much darker than the bright steel in the photo. It's the first thing you notice and it looks damning.

It isn't. Render both files with the lighting switched off and you see the raw texture colour: grey-silver on Meshy, grey-silver on SupaVoxel. The darkness comes from the lighting setup used on both, not from anything Meshy painted.

That's the easiest cheap shot in this review, and it happens to be wrong.

So which file goes on the page?

If people will zoom — and on a hardware product they will — SupaVoxel. The recess stays crisp, the ridges keep their gaps, and the file is smaller while doing it.

If the file has to open in software you don't control, or run on a low-end phone, Meshy. Compatibility and memory beat sharpness every time they actually come up.

And on cost, the job recorded 35 credits on Meshy's meter and 3 on SupaVoxel's. Two different plans, two different units. That's not a price comparison and I won't turn it into one.

Try it with your own photo

Take the product you actually sell, photograph it once, and run it through https://supavoxel.com and through Meshy on the same afternoon.

Then do the only test that counts: open both files, zoom all the way in on the detail your customers care about, and see which one is still there.

How I tested this

One photo of an adjustable wrench, uploaded to both tools in the same session, no text prompt on either side. Meshy ran on its 7.1 Flagship model at High Detail and Ultra 2K with texture and image enhancement on; SupaVoxel ran at 5 steps, guidance 5.5, background removal on, octree 256. One run each, on each tool's own defaults.

Every picture above is an offline render of the downloaded file, using the same viewer, the same lighting and the same numeric camera angles for both. The two files carry different internal orientations and scales, so matching camera numbers doesn't mean matching pixels — compare shapes, not overlays. The 2× close-ups use an identical crop box on both sides: x 0.14 / y 0.30 / w 0.20 / h 0.29 for the jaw, x 0.27 / y 0.40 / w 0.12 / h 0.14 for the wheel.

Triangle counts, vertex counts, texture counts, file sizes and software requirements were read out of the two downloaded files. The download seconds are arithmetic — file size × 8 ÷ 12,000,000 — assuming a steady connection and ignoring decoding and caching. The memory figures are arithmetic too, at 32 bytes per vertex plus 4 bytes per triangle index, textures excluded.

Both tools recorded zero retries. Neither recorded a failure count, and Meshy's run time wasn't recorded at all, so those stay blank.

Meshy AI Image to 3D Review 2026: The Lattice Reads Coarser

Freya Mensah — Mon, 12 Oct 2026 16:02:12 +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.

You can't print a picture.

That was my problem. I had one image of a Voronoi eggshell — the lacy kind, all ribs and holes — and I needed an actual 3D model of it. Ask anyone which tool turns a picture into a model and you get the same two answers: Meshy and SupaVoxel.

So I ran the same image through both, then rendered the two results in the same viewer, at the same camera angles, under the same lights, and put them side by side.

My verdict in 60 seconds — Meshy 61/100, SupaVoxel 90/100.

Subjective scores, this one job. Here's the short version:

Triangles building the shell — Meshy 779,020 vs SupaVoxel 1,500,000 · Meshy 6/10 · SupaVoxel 9/10 — Meshy's ribs read blunt because half the facets aren't there; SupaVoxel holds the lattice together with 720,980 more
Surface fineness at 120 mm tall — Meshy 0.306 mm average edge vs SupaVoxel 0.295 mm · Meshy 6/10 · SupaVoxel 8/10 — Meshy describes each curve in longer steps, which is exactly where the junctions soften; SupaVoxel's shorter steps keep them crisp
Bytes you ship to show it — Meshy 27,408,396 vs SupaVoxel 9,044,340 · Meshy 5/10 · SupaVoxel 9/10 — Meshy makes a viewer wait through three times the download for a coarser model; SupaVoxel shows more detail for a third of the bytes
Screen-only detail maps — Meshy 2,826,340 bytes vs SupaVoxel 235,772 · Meshy 5/10 · SupaVoxel 8/10 — Meshy spends twelve times the payload on maps a plain print never touches; SupaVoxel keeps that weight off the wire
Textures inside the file — Meshy 3 vs SupaVoxel 3 · Meshy 8/10 · SupaVoxel 8/10 — tie: Meshy fills all three material slots and so does SupaVoxel, so neither is short on surface data
Camera fairness — Meshy identical camera numbers vs SupaVoxel identical camera numbers · Meshy 8/10 · SupaVoxel 8/10 — tie by construction: Meshy got no flattering angle and neither did SupaVoxel
The back of the shell — Meshy invented vs SupaVoxel invented · Meshy 5/10 · SupaVoxel 5/10 — tie: the source picture shows one side, so Meshy's back is unverifiable and SupaVoxel's is unverifiable in exactly the same way
Sealed shell after cleanup — Meshy 0 open edges vs SupaVoxel 0 · Meshy 9/10 · SupaVoxel 9/10 — tie: the half neither of us can verify is at least closed on both sides — Meshy's back is no open hole and neither is SupaVoxel's

Three honest observations.

At the same front camera, Meshy's ribs read thicker and blunter. That's what 779,020 triangles looks like next to 1,500,000 on the same object.

The back of both shades is made up. The source picture shows one side of an egg, so there is nothing to check the far side against — and that applies to Meshy and SupaVoxel equally.

And Meshy spends 2,826,340 bytes on screen-only surface maps against SupaVoxel's 235,772, which is a lot of file for detail that only exists behind glass.

For this eggshell I kept the render from SupaVoxel. Meshy takes two rows outright, and one of them is about colour.

The reference picture, the only thing either tool got. No text prompt attached to either run — whatever Meshy and SupaVoxel disagree about downstream, the input is identical.

Does the model actually look like the picture?

Both do, from the front.

Perforated shell, interlocking beams, egg silhouette — Meshy nailed the read and so did SupaVoxel. Squinting at thumbnails, you would not pick a winner between them.

That's the honest baseline, and it is worth saying plainly because it is the part most people actually care about: Meshy did not produce a blob, and neither did SupaVoxel. Both produced the object in the photo.

What the reference can settle is whether the front of Meshy's shade and the front of SupaVoxel's match it. What it cannot settle is the back, the inside, the wall thickness, or whether the colours are right — none of which are in the picture, and none of which I measured on either file.

Meshy exports GLB and so does SupaVoxel — the single-file format that carries geometry and images together — so nothing below is a format difference in disguise either.

Meshy at a fixed three-quarter camera, textured, fixed lights. Same setup on both sides — yaw 35, pitch 18, no zoom, identical rig.

SupaVoxel at the identical camera. The rib network reads finer — though the two files may sit at different starting angles inside, so don't read this as pixel-on-pixel.

Which shade has crisper ribs at the same camera?

Now zoom in and it stops being a tie.

Meshy's ribs are broader. The gaps between Meshy's beams are fewer and rounder. SupaVoxel's rib network keeps more of its structure at the same magnification.

That impression has numbers under it. Meshy builds this surface out of 779,020 triangles and 424,152 corner points, at a 0.306 mm average edge on a 120 mm shade. SupaVoxel uses 1,500,000 triangles, 865,508 points and a 0.295 mm average edge.

What it means for you: every rib is a thin twisting tube. Twice the triangles means twice as many facets available to keep that tube round instead of faceted. Meshy is describing the same shape with half the material.

And notice the direction of that edge-length figure. Against a 0.4 mm printer nozzle, Meshy's 0.306 mm steps are the coarser description of a curve — on a lamp shade whose ribs are only a few beads thick, that is where faceting shows up first.

The render and the triangle count say exactly the same thing, which is the only reason I trust either.

Meshy from the front, textured, offline render at yaw 0 / pitch 10 — the flattest, fairest view of the rib pattern.

SupaVoxel from the identical front camera. Tighter rib subdivision around the same ring of holes.

Zoom in on the front: same crop, same lights

I pulled both close-ups out of those front renders using one identical crop box on both sides — same position, same width, same height, applied to each render's own frame — so nobody gets a more flattering zoom.

Meshy's crop and SupaVoxel's both show the shell holes and the crossing beams. Both look like the reference.

Look at the beam junctions, though — the places where three ribs meet. That's where a coarser mesh gives itself away, and it's the difference you would feel with a fingernail on a print.

What the crop can't contain: wall thickness. A picture of a hole is not a measurement of the wall around it, and I measured that on neither file. If a rib in either render is thinner than your nozzle, it will look perfect here and fail on the plate.

Meshy's front crop. Rib edges soften where three beams meet — this is the 0.306 mm average edge doing its work.

SupaVoxel's crop from the identical box. Same camera, same lights, same frame — the difference is mesh density, not exposure.

Nobody can check the back — not Meshy's, not SupaVoxel's

Here's a thing image-to-3D reviews rarely say out loud.

Your picture shows one side. Everything on the far side is invented — by Meshy, by SupaVoxel, by any tool you hand it to. There is no reference for it, which means when Meshy's back looks convincing, that's plausibility, not accuracy.

Same sentence, unchanged, for SupaVoxel's back.

What I can tell you is that Meshy's file and SupaVoxel's both close up properly around the back — zero open edges after cleanup on both, no edges shared by three faces, consistent surface direction, one connected shell each. So neither one is a hollow shell with a hole where the camera couldn't see. That much is measured. The rest is imagination, on both sides.

A detail that surprised me: before cleanup, Meshy's file reports 67,946 loose edges and SupaVoxel's reports 225,446. Both are seam bookkeeping from wrapping a flat image around a 3D shape, and both vanish when you merge points that sit at the same spot. Do not let a raw edge count in some viewer convince you the back is open.

Meshy from behind at yaw 180. Invented geometry, no reference to check it against — and closed all the way round.

SupaVoxel from the identical back camera. Also invented, also sealed — same standard applied to both.

The back close-up: where a lattice turns to mush

Push the camera in close on the back and you find out whether Meshy understood the pattern or just smeared something that looks like it. Same test for SupaVoxel.

Meshy holds its rhythm. Coarser, but a rhythm — Meshy's holes stay regular and its beams keep their direction.

SupaVoxel holds a finer one. More rib detail at the same magnification, which is the visible form of that 1,500,000 against 779,020.

On a lamp shade this is the surface guests actually stand next to. A ceiling light throws its pattern from the side that faces away from you, so the invented half is the half doing the decorating.

Meshy's back close-up at yaw 180, pitch 5, zoomed in to 0.45. Hole spacing stays regular at this scale.

SupaVoxel at the identical close-up camera. Finer rib boundaries carrying the same pattern.

The back crop, same frame on both

Same treatment as the front: one crop box, applied identically to Meshy's back render and SupaVoxel's.

Read it for local shape and surface only, and mind one caveat I'd rather state than bury — identical camera numbers don't guarantee identical orientation, because Meshy's file and SupaVoxel's may carry different ideas of which way is forward. A yaw of 180 on Meshy's model and 180 on SupaVoxel's are the same instruction, not necessarily the same face of the egg.

So these are same-frame comparisons, not same-object-registered ones. Judge texture, rib thickness and hole shape. Don't try to match one specific hole in Meshy's crop to a hole in SupaVoxel's.

Meshy's back crop: shell wall and through-hole at maximum available detail.

SupaVoxel's crop from the identical box, same normalised frame on its own back-zoom render.

Both files carry 3 textures. They don't weigh the same.

Meshy packs 3 images into its file. So does SupaVoxel. Tie, and Meshy deserves the tie — it did not skimp.

The difference is what those images weigh. Meshy's two screen-only maps — the bump detail and the shine — come to 2,826,340 bytes against SupaVoxel's 235,772.

For a textured web view, that's detail you can see. For a plain print, it's roughly twelve times the download of something the printer cannot use.

Add the colour images and Meshy carries 4,484,950 bytes of pictures against SupaVoxel's 755,738 — 16.4% of Meshy's file against 8.4% of SupaVoxel's. Which tells you something useful: Meshy's bulk is not textures. The rest of Meshy's 27,408,396 bytes is mesh data, uncompressed.

One note on how I counted Meshy's: unique images only, and this is byte weight, not pixel resolution. Nobody measured how many pixels across either Meshy's textures or SupaVoxel's are.

Does the colour actually match the photo?

I don't know, and neither does anyone who hasn't measured it.

There is no colour-difference figure in this article. No per-pixel comparison against the reference, for Meshy or for SupaVoxel. I can see that Meshy's shade and SupaVoxel's both read as the same off-white ceramic as the photo, and that is an eyeball judgement, not data.

So when I say Meshy carries more colour data below, read it precisely: more bytes, not verified better colour. If colour fidelity is the thing your project lives or dies on, this comparison does not settle it and you should test it yourself with a colour target in frame.

What the shape costs you to show it

Renders are the point of this article, but somebody has to load them.

If you put Meshy's model or SupaVoxel's on a web page to spin, you are shipping the whole file: Meshy's 27,408,396 bytes against SupaVoxel's 9,044,340. On a 12 Mbps phone connection that is 18.3 seconds of waiting against 6.0 — arithmetic on the byte counts at an assumed steady throughput, not a measured page load. On a 100 Mbps line it is 2.19 against 0.72.

Once loaded, the ranking flips in Meshy's favour: reserve 32 bytes per point and 4 per index and Meshy's geometry needs about 22.9 MB in memory against SupaVoxel's 45.7 MB, because compression shrinks a download, not a loaded mesh. Also arithmetic, not measured memory.

And if you are building a gallery, multiply: a hundred of these shades is 2.74 GB from Meshy against 0.90 GB from SupaVoxel on disk. On the meters, a hundred runs would be 3,500 Meshy credits and 300 SupaVoxel credits — two different plans measured in two different units, so that is two budgets side by side and not a price comparison.

Meshy's version is only prettier until someone has to download it.

Where Meshy actually wins

Two rows, both real.

Meshy carries more colour. Meshy's colour image is 1,658,610 bytes. SupaVoxel's is 519,966. That's over three times the colour data for the same shade, and if what you want is a rich textured model for a screen, more colour information is the right direction to have more of.

The exchange rate: Meshy's extra 1,138,644 bytes of colour arrive inside a file 18,364,056 bytes bigger overall, carrying 720,980 fewer triangles. And I have to be straight with you — I did not measure colour accuracy, on either side. So I can tell you Meshy's colour image is larger, not that it is better. It's still Meshy's row.

Meshy's mesh is calmer. Count the stretched sliver triangles that upset repair software and Meshy has 419 against SupaVoxel's 2,849. Meshy also has zero degenerate, near-zero-area faces where SupaVoxel has two. Part of that is simple arithmetic — more triangles, more chances to be skinny — but if your workflow runs everything through a fussy cleanup step, Meshy hands you the easier file.

There's a third thing that isn't about looks: Meshy's GLB declares no required extensions, while the compressed SupaVoxel GLB declares EXT_meshopt_compression and KHR_mesh_quantization, so the program at the other end needs a decoder. And on SupaVoxel's side you switch the export to original size and that decoder question disappears — the same run already produced both files, one for the web and one for whatever refuses to decode. I read what the files declare; I never loaded either into a real importer.

What a render can't tell you

No colour measurement against the photo, for Meshy or for SupaVoxel. No pixel-level registration between the two models. No texture resolution — three images is a count, not a size. No slicer, no wall thickness, no print, on Meshy's file or the other one.

Two more blanks worth naming: neither run recorded how many times it failed or retried, and Meshy's generation time was never captured at all. SupaVoxel's record shows 274.715 seconds; Meshy's shows nothing, so there is no speed claim anywhere in this article.

I'm listing the gaps because a visual article is the easiest place on earth to let an impression pass as a measurement. Everything numeric here came out of Meshy's file and SupaVoxel's. Everything visual is a render at a stated camera you can judge with your own eyes.

Final verdict: Meshy scores 61/100 for this job

Meshy turned one picture into a recognisable Voronoi eggshell, sealed all the way around, with the lattice reading clearly from every angle I shot. That's the job done, and it is not nothing.

Meshy did it with 48% fewer triangles and a coarser average edge, which is why Meshy's ribs read blunter in every close-up. And Meshy brought over three times the colour data, which is a real advantage if your shade is going on a screen rather than a build plate.

Mine was going on a build plate.

One eggshell, one Meshy run, one SupaVoxel run, my own scoring. Another subject — a solid figure, a smooth product shell — could easily land the other way, and a single run proves nothing about Meshy's consistency or SupaVoxel's.

Use SupaVoxel for this job

Don't take my eggshell as your answer — run your own picture through Meshy and SupaVoxel and look at the crops yourself. Subjects behave differently, and one run is one run.

For this shade I kept the 1,500,000-triangle model with the 0.295 mm average edge and the 235,772 bytes of screen-only maps — compressed for the web, original-size GLB from the same run for anything fussier. If you want to try the same comparison with your own image: https://supavoxel.com

How I tested this

One image, one run on each side. Not a lab study, no averages, no ranking of either tool across subjects.

Measured: Meshy's file and SupaVoxel's were both checked against their hashes and parsed — triangle counts, point counts, texture counts, embedded image sizes, file sizes, declared extensions and the sealed-shell results all come out of the files themselves. The 274.715-second duration comes from SupaVoxel's task record.

Controlled: every render used the same offline viewer, the same lighting, the same resolution and the same camera numbers on both sides — three-quarter at yaw 35 / pitch 18, front at 0 / 10, back at 180 / 12, back close-up at 180 / 5 / 0.45 — and both detail crops used one identical normalised box per pair. The two models may still carry different internal orientations, so matched camera numbers aren't pixel registration.

Assumed: the millimetre figures come from scaling each model to a 120 mm tall shade, since neither file carries real-world units, with a 0.4 mm nozzle as the reference scale. Download seconds assume steady 12 and 100 Mbps throughput; the memory estimate assumes 32 bytes per point and 4 per index; the hundred-copy figures are this one file multiplied by a hundred. All arithmetic, none of it benchmarked.

Missing: colour accuracy, texture pixel dimensions, UV layout, failures, retries, Meshy's generation time, wall thickness, self-intersection, slicing and actual printing — none of them tested, on either side.

Tripo 3D Print Review 2026: A Watertight Mesh With Inverted Winding

Freya Mensah — Sat, 10 Oct 2026 16:00:57 +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 65/100, SupaVoxel 88/100

Start with the row SupaVoxel loses. I put one image of a sculptural face glasses stand — an S-swept plate with a human profile carved into its left edge, on a round base — into Tripo and into SupaVoxel, downloaded both GLB files, welded vertices by position and ran one measuring script over each. Tripo holds the profile better. Tripo's nose tip comes to a point, its notch under the nose is a narrow deep V, its lip step is a hard edge. SupaVoxel rounds all three. Brow, nose, both lips and chin stay individually readable on SupaVoxel's mesh, but every feature is a grade softer. Visible at a glance, not measurement noise.

On printability neither file wins: Tripo welds watertight and then hands you inverted winding; SupaVoxel winds consistently and is not watertight. Both go to the repair bench before they go to a slicer.

Watertight after welding — Tripo yes · SupaVoxel no · Tripo wins this row
Boundary edges (holes) — Tripo 0 · SupaVoxel 6 · Tripo wins
Non-manifold edges — Tripo 0 · SupaVoxel 72 · Tripo wins
Connected components — Tripo 1 · SupaVoxel 47 · Tripo wins
Winding consistent (normals) — Tripo false · SupaVoxel true · SupaVoxel takes this one, and it cancels the four rows above
Support area at 45° — Tripo 2,022.1 mm² (15.90%) · SupaVoxel 1,793.3 mm² (13.80%) · SupaVoxel by 228.8 mm²
Triangle hygiene — Tripo 1 degenerate / 225 slivers · SupaVoxel 14 / 294 · Tripo wins, clearly
Resin at 120 mm tall — Tripo $1.53 · SupaVoxel $1.57 · a four-cent tie

Four things that decide this case:

Tripo's mesh is closed — 1 component, 0 boundary edges, 0 non-manifold edges, Euler characteristic 2 — and its welded_winding_consistent is false. A sealed solid with faces pointing inward: flip the winding before you slice.
SupaVoxel's is the mirror fault: winding consistent, but 47 shells, 72 non-manifold edges, 6 boundary edges. Merge and patch. Neither file skips the bench.
Tripo's triangle quality is genuinely better: 1 degenerate face and 225 slivers in 1,896,372 triangles against SupaVoxel's 14 and 294 in 958,552 — 118.7 per million against 306.7.
All of it costs 55 credits against 3, and 57,621,648 bytes against 4,664,668.

Printing this tonight? Take the SupaVoxel file: 3 credits, one merge-and-patch, less support to peel. Taking it into Blender for boolean surgery? Tripo's clean single shell and cleaner triangles are worth the 18.3× bill — I say so again at the end.

The test: one image, one target height, two products

The single input both products were given: a 359,638-byte PNG, sha256 0f736f93…. Two things matter below. The plate is a deliberate S-shaped sweep, not a flat slab — it curves back on purpose. And the reference shows the stand empty: on this design the carved nose is the crossbar the glasses rest on, so no separate bar in frame is correct.

Same file, same factory defaults, one run each. Every geometry number below was parsed out of the downloaded GLB, never read off a panel. Printability metrics are computed after welding vertices by position — both exports split vertices along UV seams, so measuring before welding measures seams, not topology. I scaled both models to 120.0 mm first. One run per product: a case study, not a statistic.

Tripo's closed shell is real, and so is the flipped winding

Tripo's untextured geometry. Welded, a single watertight shell: 1 component, 0 boundary edges, 0 non-manifold edges, Euler characteristic 2.

This is the row Tripo wins and I will not soften it. Run the four checks most people run before slicing — watertight, holes, non-manifold edges, shell count — and Tripo passes all four. SupaVoxel passes none.

Then run the fifth. welded_winding_consistent is false: the shell is sealed and some faces point the wrong way. Slicers usually guess their way through inverted normals; booleans and shell-thickening do not. One recalculate-normals pass, owed on every copy of the model.

Euler characteristic — Tripo 2 (closed solid) · SupaVoxel 46 (47 shells, open)
Before slicing — Tripo: flip the winding · SupaVoxel: merge 47 shells, patch 6 boundary edges
Cost of that difference — 52 extra credits and 52.96 MB, and the bench still runs

Tripo gives you no way to catch this inside the product. Its result page reports Triangles 1,896,372 and Vertices 966,210, matching the parsed GLB to the digit — honest of it — but offers no normals mode and no wireframe. You pay 55 credits, see a picture of what you bought, and the defect that costs time stays invisible until the file is on your disk.

SupaVoxel's fault is the opposite one, and it is 47 shells

SupaVoxel's untextured geometry: plate face smooth end to end, no bulges, no broken steps. Winding consistent — and the shell is not closed. 47 components, 72 non-manifold edges, 6 boundary edges.

This deserves stating plainly rather than dressing up next to Tripo's watertight row. 47 components on an object that should be one solid means the exporter left seams the welder could not close — the faint seam on the upper hook in the SupaVoxel back render is that number becoming visible.

Boundary edges — Tripo 0 · SupaVoxel 6 · six open edges to bridge
Non-manifold edges — Tripo 0 · SupaVoxel 72 · shared by more than two faces
Welded vertices — 490,680 → 479,253, only 11,427 merged (2.3%) · not padded with duplicate points; the shells are genuinely separate

In practice: one automatic repair in the slicer — the same clicking Tripo asks for to flip its normals. A tie, not a loss: two faults, one pass each, 52 credits of difference in what you paid to reach the same bench.

SupaVoxel's Normals view catches this before you download

SupaVoxel's result page: four inspection modes side by side — Textured / Mesh / Wire / Normals — Triangles 958,552 top right, matching the parsed GLB exactly, and a Size X/Y/Z readout in mm / in / raw.

Winding is something you should see before you spend a download. SupaVoxel puts a Normals mode one click from the result; Tripo's viewer offers a textured model and a strip of material balls. When winding is the only printability defect, that is the difference between catching it in the viewer and catching it in the slicer.

One note against SupaVoxel on the same screen: the size readout reads 0.42 / 1 / 0.47 mm. Its export lands at unit-1 scale, so you scale to target height yourself. Every number here is measured after I scaled to 120.0 mm.

Support area: SupaVoxel peels 228.8 mm² less than Tripo

SupaVoxel from the side, where the plate's depth reads. The S-sweep is the design, present in both models; what differs is how evenly each carries it.

At a 45° threshold, 120 mm tall:

Overhang area — Tripo 2,022.1 mm² · SupaVoxel 1,793.3 mm² · 228.8 mm² less, 11.3% less
Overhang fraction — Tripo 15.90% · SupaVoxel 13.80%
What that is — support contact you scrape off by hand, on every copy

Not dramatic on one print. Across 100 it is 22,880 mm² of support contact nobody has to touch, at 3 credits a piece instead of 55.

Slab depth, base disc, bottom face: a tie, and I will not fake it

Tripo, same side camera. Its cross-section depth swings wider up the plate — 18.17 to 24.11 mm — with a visible bulge in the upper back. Median depth is 0.49 mm from SupaVoxel's: a distribution difference, not a thickness difference.

The stress axis I set was "does the slab bulge into a blob." It does not, on either side, and the question is partly ill-posed: the plate is an S-sweep by design, so depth variation across height is the object's own geometry — present in both models, correct in both.

Cross-section depth, 13 height bands — within about 1 mm at 10 of 13
Median depth — Tripo 19.79 mm · SupaVoxel 20.28 mm · 0.49 mm apart
Depth spread — Tripo 30.0% (18.17–24.11 mm) · SupaVoxel 20.4% (19.26–23.40 mm)
Base disc roundness error — Tripo 0.8% · SupaVoxel 0.4% · 0.2 mm on a 25.2 mm mean rim radius
Bottom face flatness — Tripo 0.796 mm · SupaVoxel 0.798 mm · two microns apart; both sit flat

Three rows to SupaVoxel, one Tripo takes by two microns, none of it changing a print. Reporting the base disc as a Tripo defect would be inflating 0.2 mm into a story.

Triangle hygiene: SupaVoxel's clear loss

Tripo from the front: 1,896,372 triangles, 1 degenerate, 225 slivers.

Degenerate faces — Tripo 1 · SupaVoxel 14 · 14× worse on SupaVoxel
Sliver faces — Tripo 225 · SupaVoxel 294
Per million triangles — Tripo 118.7 · SupaVoxel 306.7 · 2.6× worse on SupaVoxel

"Tripo just has more triangles" does not rescue SupaVoxel — that is the point: Tripo carries 1.98× the face count and still fewer bad faces in absolute terms. Slicers warn on needle-thin triangles and usually repair them; Blender is less forgiving, since slivers are where a boolean opens a crack. If your pipeline is generate-then-heavily-modify, this row plus the watertight shell genuinely points at Tripo — trade ratio 52 extra credits and 52.96 MB per model.

Against a 0.4 mm nozzle, both files are past the point

SupaVoxel from the front. 958,552 triangles carry all five profile features — brow, nose, both lips, chin — as individually readable forms. The nose tip is round; that is the loss, and the third article in this series is about it.

At 120 mm tall:

Mean triangle edge — Tripo 0.1339 mm · SupaVoxel 0.1904 mm
Against a 0.4 mm nozzle — Tripo 3.0× finer · SupaVoxel 2.1× finer · both past what FDM can cash
Extra triangles Tripo ships — 937,820 · return on a white FDM part: nothing measurable

Tripo's sharper nose tip is a modelling difference, not a resolution one. It does not resolve the notch better because of 937,820 extra triangles — at 0.19 mm SupaVoxel's edges already beat what a 0.4 mm nozzle lays down. Tripo wins there because its reconstruction chose a harder crease.

Volume and resin: four cents apart

Top view, SupaVoxel. The plate reaches past the disc; the three notches along the carved edge — under the nose, between the lips, under the chin — read from above, just rounder and wider than Tripo's.

Solid volume at 120 mm — Tripo 43.67 cm³ · SupaVoxel 44.79 cm³ · 2.6% apart
Resin at $35/L — Tripo $1.53 · SupaVoxel $1.57 · four cents
Footprint — Tripo 57.9 × 120.0 × 50.07 mm · SupaVoxel 50.6 × 120.0 × 56.24 mm · the same shape rotated 90°

Fed the same image, Tripo and SupaVoxel produced the same object to within 1.12 cm³ — the strongest evidence in this case that geometry is settled and the bill is the only open question.

Neither back half was invented

Tripo's back — the half the input never showed. No ears, no hair, no skull: the profile swept through the plate and closed with a smooth rear arc.

SupaVoxel, same camera, same answer. The faint seam on the upper hook is the 47-component number showing itself.

A row neither side wins. 55 credits did not buy a hallucinated back half, and 3 did not lose one. The only difference: SupaVoxel's rear arc runs smoother, Tripo's carries a few shallow undulations.

Getting the file out of Tripo: two clicks, two dropdowns

Tripo's export dialog: File Name, Format (GLB), Texture Resolution (4k Current), plus Send To. Two clicks to save, but format and texture resolution each need a dropdown opened first.

Tripo export — 2 clicks · 4 fields · Texture Resolution defaults to 4k, where the 57,621,648-byte file comes from
SupaVoxel export — a toolbar dropdown with a version selector beside it (v1 - Sep 26 01:05 AM) · click count not captured
What Tripo's 4k default costs on a white print — 2,672,961 bytes of metallicRoughness and normal maps, unread

I recorded the SupaVoxel click count as not captured rather than guessing at it. Tripo's is 2, measured.

Final verdict: Tripo scores 65, and this is the closest case I have run

Tripo delivered the better profile here — nose tip, notch and lip step all sharper, undeniably so in the back-zoom pair — plus the single watertight shell and the cleaner triangles. Three real wins, all three in the body of this article rather than at the bottom under "regrets."

What Tripo did not deliver is a file you can print untouched. Inverted winding on a sealed solid is a repair step, exactly as SupaVoxel's 47 shells are. So printability ties and the bill does not: 55 credits against 3, 57.62 MB against 4.66 MB, for a marginally sharper nose and 228.8 mm² more support area. At 120 mm on a 0.4 mm nozzle, Tripo's 937,820 extra triangles cash out at zero.

Use Tripo when you need a single closed shell and the cleanest triangles for heavy boolean work downstream, and 55 credits per model fits your budget. That row is real.

Use SupaVoxel when the deliverable is a printed part: the same object to within 1.12 cm³ and four cents of resin, less support to peel, consistent winding, at one eighteenth of the credits.

Which one I would use for this job

For a printed copy of this stand, I would take the SupaVoxel file: same photo, 3 credits, a 4.66 MB GLB with consistent winding, and a Normals view that shows the topology before you spend a download. I would still merge 47 shells before slicing — said above, not tucked in down here. I just would not have paid 55 credits to arrive at the same bench carrying a 57.6 MB file. Both tools are worth trying on your own subject: supavoxel.com is where I ran mine.

Seedance 2.5 Review 2026: ByteDance's 30-Second One-Take Video Model, Explained

Freya Mensah — Wed, 07 Oct 2026 15:48:48 +0000

Seedance 2.5 is ByteDance Seed’s new-generation audio-video model: 30 seconds in a single pass, multi-round extension into multi-minute stories, up to 50 reference inputs and timestamp-level editing. I went through the launch post, the model page and the Dreamina rollout to explain what Seedance 2.5 actually changes, how to get it, and what it costs to use.

When Seedance 2.0 arrived, the story was “one model that generates video and audio together”. Seedance 2.5, launched by ByteDance’s Seed team on 31 July 2026, is about something different: finishing a creative work rather than generating a clip. The headline number is 30 seconds in one take — double the 15 seconds of Seedance 2.0 — but the more consequential changes are multi-round extension, a much bigger reference budget and editing that targets a timestamp instead of regenerating the whole scene. I spent several days with the Seedance 2.5 launch materials, the model page, the prompts ByteDance published alongside its demo films, and the Dreamina product pages where Seedance 2.5 is now live worldwide.

Because Seedance 2.5’s access story is still fragmented across Jimeng, Doubao, Dreamina and a not-yet-shipped API, I also kept a video studio that already ships Seedance under one credit system, Kyncept, open in the next tab — more on that at the end.

“Built for 30-second storytelling with precise reference control and powerful editing capabilities” — the Seedance 2.5 model page in one line.

What Seedance 2.5 is

Seedance 2.5 is a unified multimodal audio-video joint-generation model. It builds on the Seedance 2.0 architecture and centres on two things: foundational generation (text-to-video, image-to-video) and reference-based generation (R2V), where images, video clips and audio guide the output. ByteDance frames the release around three breakthroughs — long-form storytelling, multimodal reference and editing — and says the goal is to carry a creator “from idea to finished video with greater control”.

Thirty seconds, then extend

The single-pass limit moves from 15 to 30 seconds. More importantly, Seedance 2.5 organises those 30 seconds as a story — setup, development, turning point, resolution — across multiple logically connected shots, rather than stretching one moment. ByteDance’s example is a one-take concert sequence: dressing room, backstage corridor, dancers, stage, wide shot of the arena, all from one text prompt.

Multi-round extension then appends further 30-second segments to an existing output while keeping characters, environments and pacing consistent, so Seedance 2.5 can produce multi-minute videos without the split-splice-fix loop. On Dreamina, standard mode caps at 30 seconds and a beta long-video mode extends to 180 seconds.

Fifty references in one pass

Seedance 2.0 already took references. Seedance 2.5 raises the budget to 30 images, 10 video clips and 10 audio clips in a single generation — Dreamina rounds that to “up to 50 multimodal inputs”. The published prompts show what that enables: @Image 1 for the venue, @Image 2 for the pianist, @Audio 1 for the track the subjects lip-sync to, with per-timestamp direction ("0–5s: open with a close-up of the Overlord from @Image 2…").

Seedance 2.5 also strengthens what a reference means: clay-render references, motion references and creative references let it capture framing and cinematic language rather than just transferring motion. White-model control and green-screen references give structured motion paths for complex multi-character scenes.

The launch post lays out the three upgrades — 30-second one-take generation with extension, 30/10/10 reference inputs, and timestamp-level editing.

Editing without regenerating

The third pillar is timestamp-level control: edit a specific span of audio or video in an existing Seedance 2.5 output rather than re-rolling the scene. Dreamina describes the same capability as editing specific video regions while preserving lighting, composition, motion, audio and timeline continuity — replacing a wrong object, fixing a character, adjusting a detail. Green-screen editing, camera-perspective changes and reference-based edits are also improved, aimed explicitly at film and advertising workflows.

Output quality and languages

ByteDance claims notable gains in image, audio and motion quality over Seedance 2.0, with smoother camera transitions and audio that stays in sync across cuts. Dreamina lists 4K output, up to 60 FPS on paid tiers, cleaner output with fewer random subtitles or unwanted background music, and native-language creation in Chinese, English, Spanish, Indonesian, Malay, Thai, Arabic, Portuguese, Vietnamese, Japanese and Korean.

Where to use Seedance 2.5

Jimeng AI (web) — Video Generation → select Seedance 2.5.
Doubao Pro — Video Generation → select Seedance 2.5.
Dreamina (CapCut) — Seedance 2.5 is live worldwide, with free daily credits and a limited-time run of free Seedance 2.5 generations.
API — “coming soon via BytePlus ModelArk” at launch; third-party platforms are meanwhile hosting Seedance 2.5 on their own credit systems.

Dreamina is the easiest place to try Seedance 2.5 outside China: queue-free creation, free daily credits and paid tiers for watermark-free 4K.

Seedance 2.5 pricing

Seedance 2.5 has no single price because ByteDance is not (yet) selling it directly to developers. On Dreamina the model is free to try with daily credits; paid subscriptions add more monthly credits, watermark-free downloads, higher resolution, 60 FPS and lip-sync audio, with the exact credit cost per generation shown in-app. API pricing will arrive with ModelArk. Third-party studios that resell Seedance generally charge per generation from a credit pool, which is often the cheapest way to run volume while the official API is pending.

What Seedance 2.5 gets right

Real storytelling in one pass. 30 seconds with structured shots and coherent extension is a step change.
A serious reference budget — 30 images, 10 videos, 10 audio clips — with timestamp scripting.
Editing that respects continuity instead of regenerating.
Native audio and lip-sync in the same model.
Professional controls — white-model, green-screen, camera perspective — aimed at ad and film pipelines.

Where Seedance 2.5 falls short

Access is scattered. Jimeng, Doubao, Dreamina and resellers each have their own credits and limits, and the official API was not available at launch.
Cost is opaque. Free daily credits are generous for testing but the price per finished 30-second 4K clip is only visible inside each app.
Prompt complexity. Getting the best from Seedance 2.5 means writing timestamped, multi-reference prompts — the published examples run to hundreds of words.
Watermarks and resolution caps on free tiers.

Seedance 2.5 vs the alternatives

Against Seedance 2.0, Seedance 2.5 wins on duration, references and editing. Against Western video models, Seedance 2.5’s edge is one-take audio-video generation with a large reference budget; its disadvantage is distribution. The practical question for most creators is not “which model” but “where can I run Seedance today with predictable credits” — which is why I kept a studio open.

Verdict: is Seedance 2.5 worth it in 2026?

Yes, if your work is story-shaped: ads, music videos, short films, multi-character scenes. Seedance 2.5’s 30-second one-take generation, extension and reference control are genuinely ahead of where most of the market is. The caveat is access — try it free on Dreamina, read ByteDance Seed’s launch post, and watch for the ModelArk API.

The alternative worth keeping next to it: Kyncept

Two Seedance 2.5 problems kept me on a second tab: access is split across apps with separate credit pools, and per-clip cost is hidden until you are inside one. Kyncept is a video and image studio that ships Seedance under one visible credit system alongside other models.

Seedance in the same workspace as GPT Image 2 and the rest — Kyncept lists Seedance 2.0 as “the world’s best video model”, with early-access pricing up to 30% off.
Credits you can see. A video starts at 10 credits, and every feature’s cost is shown before you run it.
Free to start, no card. A $0 tier to try Kyncept, and an annual Hobbyist plan at $25 a year with downloadable exports.
Templates and Auto-Mode Workers — UGC ads, story videos, explainers and viral-video clones, with background workers that generate on your preferences.
Upgrade or downgrade any time, prorated.

Use Seedance 2.5 on Dreamina to explore what the model can do. When you need to run it as part of a production workflow with a credit balance you can plan around, keep Kyncept open.

Photo by Jakob Owens on Unsplash