DEV Community: Mei Ferreira

Higgsfield AI Image Generator Review 2026: The Four-Image LUMA Test

Mei Ferreira — Tue, 20 Oct 2026 15:46:33 +0000

This is an independent hands-on comparison of two third-party tools; both were run on my own accounts — a free tier and a paid plan — with no vendor-provided access. The observations below come from four downloaded image originals and the recorded screens and balances for these particular runs.

My verdict in 60 seconds

Two images from Higgsfield and two from Kyncept tackled the same fictional LUMA phone package. Both interfaces displayed Nano Banana Pro and a 16:9 selection. Every delivered original measured 1376 × 768 pixels. All four made a legible package, but neither pair was reliably brand-clean: Kyncept's first handset acquired a physical Home button, and the second images on both platforms acquired an Apple mark nobody requested. Higgsfield's two original PNGs also carried a visible HIGGSFIELD AI mark in the lower-right corner. Its completed image cards appeared sooner in these two runs; Kyncept's paid-Pro-account JPEGs did not show a Kyncept watermark. That is an account-specific observation, not a promise about either site's other plans.

This is a creative-task tie, not a scored contest. Every output still needs inspection before a fictional-device launch, and four stochastic images cannot establish a universal image-quality winner.

Editorial comparison cover made from the two second-run LUMA images. Both depicted handsets have an unrequested Apple mark; this designed split is not an untouched original or a quality measurement.

One prompt, the same selected image model

The image instruction asked for a matte-black smartphone inside a larger, phone-shaped corrugated-cardboard box on a white table. It specified charcoal-and-teal geometric printing, a die-cut window, transparent biodegradable film, a removable paper pull tab, folded seams, visible cardboard thickness, LUMA on the side, a small recycling symbol, and a grounded shadow. It forbade extra products. The same text-only request ran twice per platform, without a reference image, with displayed Nano Banana Pro and 16:9 selected on both UIs.

The named model, prompt, attempt count and selected ratio match. Random seeds, account entitlements and encodings do not. The delivered 1376 × 768 pixels are slightly wider than mathematical 16:9. These judgments come from downloaded originals, not preview thumbnails.

Four originals, four specific problems to check

Kyncept image one looks like a plausible product photograph at first glance. LUMA appears on the package side; the die-cut opening, print, corrugated edge and pull tab are easy to find. Then the phone gives the game away: its screen has a round physical Home button. The prompt requested a matte-black smartphone, not an older handset style. For a packaging proposal, that detail changes the implied product even if the cardboard looks convincing.

Kyncept original one: readable LUMA box, window, tab and corrugated side, with an unrequested physical Home button on the handset.

Kyncept image two changes the camera angle and shows the handset back. The pull tab and package construction remain visible. But there is an Apple-shaped mark on the phone. A fictional LUMA concept cannot be handed off as a clean unbranded device image without addressing that mark.

Kyncept original two: the handset is viewed from the back, where an unrequested Apple mark appears.

Higgsfield image one puts a dark screen in the opening and keeps the teal geometry, LUMA wordmark and cardboard edge in frame. It avoids the conspicuous physical button in Kyncept's first draw, but the downloaded file includes HIGGSFIELD AI at bottom right. Higgsfield image two rotates the box and reveals the back of a phone bearing an Apple mark, alongside the same baked-in platform mark. Those are defects visible in the actual delivered pixels, not merely in a page overlay.

Higgsfield original one: dark screen and branded box, with the HIGGSFIELD AI mark embedded at lower right.

Higgsfield original two: the unrequested Apple mark is on the phone back; the HIGGSFIELD AI mark remains in the original file.

Prompt adherence is not the same as a materials test

Both pairs got the broad composition: one handset, a phone-shaped cardboard package, teal-and-charcoal print, a window, a pull tab and LUMA lettering. Shadows put the packages on their white tables rather than floating them in space. These are meaningful wins for concept exploration. The two second runs also show why a plausible image is not a cleared product asset. The instruction was for a fictional label, yet each showed somebody else's mark on the handset. Neither platform has earned a brand-safety claim from this experiment.

The film is an even clearer boundary between appearance and evidence. A transparent-looking window can depict film, but pixels cannot tell a packaging engineer whether that material biodegrades. Likewise, the printed recycling symbol is an image detail, not a certification of the package. I would use these frames to discuss shape and art direction, then replace the material claim with independently sourced specifications before advertising it. Treating a handsome render as proof of a physical property would be a category error.

The two creation panels: comparable choices, different layouts

Kyncept placed Nano Banana Pro, the reference-image slot, prompt, aspect selection and one-image generation control in a left panel. The captured setup shows the reference slot empty, the prompt entered and 16:9 selected. The account used for this side was paid Pro. The screenshot also shows an upgrade control; it does not establish what a free Kyncept account would export or whether that output would carry a watermark.

Kyncept's filled image panel: Nano Banana Pro, no reference image, 16:9 selection and the one-credit Generate control are visible.

Higgsfield condensed the same test prompt and model/aspect controls into a horizontal composer. The captured Generate button displayed two credits for the selected image job. Neither panel screenshot proves hidden defaults or general feature parity; it only documents the selections used here. Notice that a label saying 16:9 is a UI choice, while the measured file dimensions are the delivered result. Those should be recorded as separate facts whenever someone needs a specific crop.

Higgsfield's image composer: the LUMA prompt, Nano Banana Pro, 16:9 and a two-credit Generate button are shown together.

The waits: Higgsfield appeared first in these two runs

The first Higgsfield completion card was observed no later than 41.01 seconds after submission, and the second no later than 37.63 seconds. Kyncept's recorded UI completion waits were 55.7 and 54.0 seconds respectively. Thus the observed Higgsfield cards appeared at least 14.69 and 16.37 seconds earlier in these paired runs. “No later than” matters: a polling observation bounds the card's appearance; it is not a precision measurement of server execution or full-resolution download time.

Higgsfield's first completed UI card previews the first LUMA image; the recorded first sighting was no later than 41.01 seconds.

The second Higgsfield image's completed card was first observed no later than 37.63 seconds after submission; the original shown above also contains an unrequested Apple mark.

Kyncept's completed first image appears in History; that run's recorded UI wait was 55.7 seconds.

A quarter-minute matters to someone waiting on one concept. It cannot simply be multiplied across a batch: concurrency and queue behavior were not tested. The small sample says nothing reliable about platform-wide latency.

Credits are receipts, not interchangeable money

The Higgsfield free account's visible balance moved 6 → 4 → 2 over its two image jobs: two Higgsfield credits each. The Kyncept paid Pro account moved 269 → 268 → 267: one Kyncept credit per image. These balances verify within-site debits for the exact selected model and settings. They do not make one Kyncept credit equal to one Higgsfield credit in cash value, and this draft has no matched current plan prices with which to make a dollar comparison.

Higgsfield balance before the first image: six credits remain in the tested account.

Higgsfield balance after image one: four credits remain.

Higgsfield balance after image two: two credits remain, completing the observed 6 → 4 → 2 sequence.

Kyncept balance before its first image: 269 credits on the tested paid Pro account.

Kyncept History after image two shows both completed results and a balance of 267 credits, versus 269 before the pair.

At the observed debits, a hypothetical 20-image batch would require 40 Higgsfield credits or 20 Kyncept credits if nothing about model, setting or charging changed. That is useful for estimating a wallet inside each site, not for declaring one subscription cheaper. Even the displayed balances came from different account types. The comparison stops where the evidence stops.

A watermark visible in the downloaded original

A watermark on a preview and a mark embedded in an exported file are different production problems. Both Higgsfield original PNGs contain a visible HIGGSFIELD AI mark at lower right. If an art director wants to place an untouched render on a client slide, that corner becomes part of the slide. I am not inferring why it was applied or whether another entitlement would remove it. I am describing these two downloaded files from the tested free account.

Neither Kyncept JPEG original shows a visible Kyncept brand watermark. That is a practical difference in these four deliverables, but the tested Kyncept account was paid Pro. It would be dishonest to turn this into “Kyncept's free tier is watermark-free,” because no free Kyncept image was examined. Conversely, the Higgsfield mark does not erase its faster observed cards. Both properties can be true at once, and creators can decide which constraint matters for their intended handoff.

File size: 2.231× the transfer bytes, not 2.231× the quality

Kyncept's two originals were JPEGs of 569,660 and 643,178 bytes. Higgsfield's were RGBA PNGs of 1,362,297 and 1,343,707 bytes. Summed across each pair, that is 1,212,838 JPEG bytes against 2,706,004 PNG bytes, a 2.231× transfer-size ratio. PNG and JPEG use different compression and the PNGs include an alpha channel; this arithmetic cannot establish sharpness, aesthetic quality or which generator understood the prompt better.

At an ideal, uninterrupted 12 Mbps, the first Kyncept image's bytes alone represent about 0.380 seconds of transfer and the first Higgsfield image's about 0.908 seconds. Real users face connection setup, storage, retries and variable throughput, so these are illustrations of byte budgets rather than promised download timings. If bandwidth or slide-deck weight matters, test the actual destination format and process, not the assumption that a larger original contains a better picture.

A brief video aside, without a false like-for-like race

The same LUMA idea also had a text-to-video prompt, but it is not an image-quality tiebreaker. Higgsfield's tested Wan 2.5 Fast setting was 5 seconds / 720p in the UI and yielded a playable 5.042-second file. Kyncept yielded two 8.000-second clips from its video runs. The written request asked for eight seconds, so the Higgsfield clip under that selected setting fell 2.958 seconds short of the requested duration. The settings and delivered lengths differ; this is not an 8-second model-to-model speed or quality comparison. Higgsfield's video UI completion time was not captured precisely.

Four-frame contact sheet from Higgsfield's successful 5.042-second LUMA video: package, opening, film interaction and raised handset; still frames do not verify audio timing.

The video files had audio tracks, but nobody verified that paper tearing, hinge motion, film crinkling and tray clicks were synchronized by listening. A waveform peak would not prove which sound happened at which action. That question deserves its own viewed-and-heard test rather than being smuggled into a still-image verdict.

Final verdict: inspect the handset before choosing a winner

For the LUMA concept, the visual result is a practical tie with different cleanup. Higgsfield put completed cards on screen sooner in both observed image runs, but its two originals arrived with a platform mark baked in. Kyncept's paid Pro originals lacked a visible Kyncept watermark, but one phone had a Home button and the other borrowed an Apple mark. Higgsfield's second phone borrowed that mark as well. I cannot award a general quality crown from those four files or treat two currencies as one price. I can say exactly why none should go straight from generation to a fictional-brand launch.

Which one I would use for this job

For an early internal mood board where speed matters and the platform mark is tolerable, the first Higgsfield output is a credible starting point. For a handoff in which a visible generator mark is unacceptable, I would start with the unwatermarked files from the tested paid Pro Kyncept workflow at https://kyncept.com, then reject or revise the incorrect handset details. That is a conditional choice, not an assertion about either site's free-tier exports. Before shipping anything, I would independently verify the actual film specification and check the final device art for third-party marks.

Tripo AI 3D Review 2026: 62.89 MB and a 41.9-Second Download

Mei Ferreira — Sun, 18 Oct 2026 15:46:05 +0000

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

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

One photograph of a desktop robotic arm, run once through Tripo and once through SupaVoxel at stock defaults, then both results rendered offline from identical cameras under identical lighting. On likeness this is the closest case in my series: both products built the windows, both kept the cable, both kept the plates flat. Tripo won a real row here — it separated the three-colour servo loom into three distinguishable tubes where SupaVoxel welded them into one. It then handed me 62.89 MB to carry that win, against SupaVoxel's 5.63 MB.

Cable strands — Tripo three separable tubes with visible gaps · SupaVoxel one thicker two-tone band · Tripo wins, and it is the sharpest win in the case
Cable standoff from the body — Tripo max 4.158 mm · SupaVoxel max 10.337 mm · 2.49×, the SupaVoxel run genuinely bridges air
GLB on disk — Tripo 62,888,224 B · SupaVoxel 5,627,132 B · 11.18×
Bytes per triangle — Tripo 32.18 B · SupaVoxel 5.64 B · 5.70×
Texture set — Tripo 3 × 4096² = 6,773,618 B · SupaVoxel 3 × 2048² WebP = 586,638 B · 11.55×; Tripo's resolution is the better one for close-up material work
First load on 12 Mbps mobile — Tripo 41.93 s · SupaVoxel 3.75 s
CDN at 10,000 loads/month, $0.085/GB — Tripo $53.45 · SupaVoxel $4.78 · $584.06 a year apart
Geometry VRAM — Tripo 56.11 MB · SupaVoxel 28.71 MB · 1.95×

Three things before the detail. Tripo really does resolve the loom better, and if you need a wiring diagram or a multi-colour paint job, that row is not one anybody can talk away. On the back — a surface the photograph never shows — both products invented, and Tripo invented more, including a cable with no reference at all. And Tripo's 4096² texture set is 61.3% maps a printer never reads.

For putting this arm on a product page I would use the SupaVoxel file: 3.75 s to first paint against 41.93 s, and a CDN line one eleventh the size.

The single input, 1,403,490 bytes, one side only. Everything about the back of this object is invention on both sides, and the two sections below hold each product to that.

The hero shot: where Tripo's extra triangles actually landed

Both models are rendered from the same camera with the same lights. Above the shoulder, SupaVoxel's loom reads as two runs pressed together — effectively one two-tone tube. Tripo's reads as three: yellow, orange, red, each with its own highlight and a visible gap between them.

Further down over the lower link plate, SupaVoxel's becomes a single orange tube crossing the triangular window with nothing beneath it. That crossing is where the 10.337 mm standoff measurement comes from — it is genuinely airborne. Tripo's three runs stay parallel and close to the chassis, peaking at 4.158 mm.

Two sentences settle the case: Tripo wins on strand separation, SupaVoxel wins on span. Neither is a failure.

SupaVoxel, three-quarter hero. One two-tone tube above the shoulder, one orange tube bridging the triangular window unaided.

Tripo at the identical camera. Three strands above the shoulder with gaps between them, and three parallel runs along the lower plate. This is what 1.96× the triangles bought, and it is a genuine gain.

Top-down: two rings against one continuous band

From above, the wrap of cable around the shoulder cylinder is the clearest single comparison in the case. SupaVoxel's reads as one continuous orange band encircling the cylinder — no strands, no gaps. Tripo's is two separate rings, one orange and one slightly darker, with visible space between them.

Tripo also puts two small white dots on the wrist panel that the SupaVoxel version renders as one flat warm-white plane. The photograph is not conclusive at that scale, so I am not scoring it either way.

Second-order number: this separation cost 957,156 extra triangles and 57.26 MB.

SupaVoxel from above. The elbow wrap is one continuous orange band; the wrist panel is a single flat warm-white surface; one black connector at the centre of the base.

Tripo from above. Two separate rings with a gap, plus two extra white dots on the wrist panel. Tripo's clearest, most legitimate win in this test.

The back of the arm does not exist, and both products made one up

The input photograph shows one side. Everything on the far side of this object is invented by whichever product you paid.

SupaVoxel mirrored the front: a matching triangular window, a rounded-rectangle slot, a disc hub. Its slot is left as a plain dark recess with nothing inside it. Its loom on that face becomes one thicker orange-yellow tube running around the elbow onto a single black connector.

Tripo invented differently and invented more. Inside that same rectangular slot Tripo placed a segment of ridged orange cable — a cable, on a surface no reference image contains. Orange also shows through the inside of the triangular window.

Neither is right, because there is no right. But only one of them added a part that nothing supports.

SupaVoxel, rear. Mirrored window set, and the rectangular slot deliberately left as an empty dark recess.

Tripo, same camera. The same slot now contains a ridged orange cable run, and orange bleeds through the triangular window. More invention, on the same absence of evidence.

The zoom that pins it: three clean tubes against a welded band

At close range the split is unambiguous in both directions.

On the SupaVoxel rear zoom the red, orange and yellow runs are pressed into a single band with no visible seam between strands — and just before the connector there is a pale washed-out transition where colour bleeds off the cable. That is a defect, it is SupaVoxel's, and it is in the frame.

On Tripo's rear zoom the same bundle is three round tubes with hard boundaries, a clear dark gap between the red and the orange, and a yellow run tracking separately on the right. Tripo's rectangular slot holds its invented ridged cable; the SupaVoxel slot is empty and clean-bottomed.

Strand separation — Tripo 3 resolved tubes · SupaVoxel 1 welded band · Tripo wins
Colour bleed at the connector — Tripo none observed · SupaVoxel a pale washed transition · Tripo wins
Invented content in the rear slot — Tripo a ridged cable with no reference · SupaVoxel an empty recess · SupaVoxel wins
Max standoff from the chassis — Tripo 4.158 mm · SupaVoxel 10.337 mm · p90 1.670 mm against 4.551 mm

SupaVoxel, rear zoom. One band, no strand seams, and a pale colour-bleed transition before the connector — recorded, not cropped out.

Tripo, same crop. Three hard-edged tubes with a dark gap between red and orange, and the invented ridged cable lying in the slot the SupaVoxel version left empty.

32.18 bytes per triangle against 5.64

Here is where Tripo's win gets expensive. Tripo's file spends 32.18 bytes on every triangle; SupaVoxel's spends 5.64. That is 5.70× worse byte efficiency, and it is not geometry — it is texture policy plus shipping the mesh uncompressed.

The SupaVoxel GLB lists EXT_meshopt_compression and KHR_mesh_quantization as required extensions. Tripo's lists KHR_materials_volume and FB_ngon_encoding, neither of which saves a byte.

Triangles — Tripo 1,954,511 · SupaVoxel 997,355 · 1.96×
Vertices — Tripo 1,020,577 · SupaVoxel 523,138 · welded, 977,185 against 498,561
GLB bytes — Tripo 62,888,224 · SupaVoxel 5,627,132 · 11.18×
Bytes per triangle — Tripo 32.18 · SupaVoxel 5.64 · 5.70×
Geometry VRAM (verts × 32 B + indices × 4 B) — Tripo 56.11 MB · SupaVoxel 28.71 MB

SupaVoxel's result screen. The panel's Triangles reads 997,355 against my parsed 997,355, and Size 0.61 / 1 / 0.76 against a raw bounding box of 0.6088 / 1.0 / 0.7610. Four inspection modes plus X-Ray sit along the top of the viewport.

The texture set: Tripo's is sharper, and 61.3% of it is unprintable

Tripo gives you three 4096² maps totalling 6,773,618 bytes. SupaVoxel gives three 2048² WebP maps totalling 586,638 bytes. For close-up material rendering Tripo's resolution is better and SupaVoxel cannot match it — that row belongs to Tripo, at 7.59× on baseColor alone.

For anything that ends on a build plate, the split is unkind. baseColor is the only map a slicer might consult: Tripo 2,619,411 B, SupaVoxel 345,278 B. The rest — metallicRoughness and normal — is 4,154,207 B on Tripo's side against 241,360 B on SupaVoxel's. That is 61.3% of Tripo's texture payload going nowhere, and Tripo's normal map alone at 2,676,872 B is 4.56× the size of SupaVoxel's entire texture set.

Second-order number: on a white print, both baseColor maps are worth exactly zero, and one of them costs you 2.62 MB.

Download time and the CDN bill

Take the two files to a product page.

12 Mbps mobile, first load — Tripo 41.93 s · SupaVoxel 3.75 s
100 Mbps home, first load — Tripo 5.03 s · SupaVoxel 0.45 s
CDN at 10,000 loads/month, $0.085/GB — Tripo $53.45 · SupaVoxel $4.78
Same bill over a year — Tripo $641.46 · SupaVoxel $57.40 · $584.06 apart
Geometry VRAM on the device — Tripo 56.11 MB · SupaVoxel 28.71 MB

Forty-two seconds is not a slow load, it is an abandoned page. And 56.11 MB of geometry VRAM is where a low-end phone drops the tab entirely.

The exchange rate for Tripo's three separated cable strands: 38.18 extra seconds on mobile, $48.67 a month in delivery, and 27.4 MB more VRAM per visitor.

One place the SupaVoxel file is harder to open than Tripo's

SupaVoxel's compression has a cost and it is fair to name it. Because its GLB puts EXT_meshopt_compression and KHR_mesh_quantization in extensionsRequired, an older toolchain without a meshopt decoder cannot read it directly — it needs one pass through a converter first. Tripo's two extensions are both optional, so Tripo's file opens in more places out of the box.

The same thing tripped my own measuring rig: SupaVoxel's UVs are uint16-normalised and have to be divided by 65535 before any texture sampling, or every colour test silently returns nothing. The cable test nearly read as "no cable exists" because of it.

Wireframe close-ups are worthless at this density, on both sides

I rendered matched wireframe zooms for both models and they prove nothing, so here they are with that said out loud.

At 997,355 triangles the SupaVoxel wireframe fills the silhouette to near-black with a few white specks near the triangular window — a 44.7 KB PNG. Tripo's at 1,954,511 triangles is blacker and flatter and compresses to a smaller 32.6 KB PNG, because uniform noise compresses well.

That pair is the most honest picture of 1.96× the triangles that exists: to the eye it is only darker. The real difference shows up in the hero and top-down shots, on the strands.

SupaVoxel wireframe zoom, 44.7 KB PNG. Near-solid. No structure readable.

Tripo wireframe zoom at the same magnification, 32.6 KB PNG — darker, flatter, and smaller on disk. 1.96× the triangles, zero visible structural difference.

What 57.26 MB bought

Tripo's extra 57.26 MB and 957,156 triangles bought three separated cable strands, two rings instead of one band on the shoulder wrap, a 4096² texture set that is genuinely better for close-up rendering, and a cable invented on a face nobody photographed.

They did not buy a larger window opening (SupaVoxel's are ~15% larger in area), a cable that stands further off the chassis (SupaVoxel's reaches 2.49× further), a faster page, a smaller CDN bill, or any structure visible in a wireframe.

Final verdict: Tripo scores 62/100 on likeness and payload

Tripo earns its likeness score here. Three separable strands where SupaVoxel welded one band, no colour bleed at the connector, and a texture set at twice the resolution — those are Tripo's rows, cleanly. Tripo then charges 62.89 MB for them, of which 4,154,207 bytes of texture can never be printed, and turns a product page into a 41.93-second mobile wait and a $641.46 annual CDN line.

SupaVoxel scores 89/100: 5.63 MB, 3.75 s on mobile, $4.78 per 10,000 loads, half the VRAM, larger openings and a cable that genuinely spans air — against a welded loom, a colour bleed I left in frame, 2048² textures, and a file an old toolchain has to convert first. This is the case where both products pass, which puts the whole decision on what the win costs to deliver.

Which one I would use for this job

Same photograph, 3 credits, 5.63 MB, 3.75 s to first paint on mobile, $4.78 per 10,000 page loads, half the geometry VRAM — supavoxel.com. Bring your own reference, and pull both files onto a phone before you decide; that measurement takes under a minute and it is the one your visitors will feel.

Tripo AI Robotic Arm Review 2026: 55 Credits, Same Four Holes

Mei Ferreira — Fri, 16 Oct 2026 15:48:51 +0000

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

My verdict in 60 seconds — Tripo 64/100, SupaVoxel 89/100

One photograph of a small white desktop robotic arm — two flat link plates with cut-out windows, and a three-strand servo cable running from base to wrist — put once through Tripo and once through SupaVoxel at stock defaults, then both GLB files torn apart offline by the same script. I paid for both runs myself and I have no stake in either tool. This is the one test in my series where both products passed every part of the geometry stress axis. Tripo did not fake a hole, flatten the cable or fatten the plates. Neither did SupaVoxel. So the question is not who failed — it is what Tripo charges for a result that ties.

Through-holes — Tripo 4 fully enclosed openings from the front · SupaVoxel 4 · both real, neither faked with texture; SupaVoxel's are ~15% larger in area (149.56 / 149.50 mm² against 132.31 / 128.69 mm²)
Thin cable — Tripo raised geometry · SupaVoxel raised geometry · both still standing with every texture stripped off
Link plates — Tripo median 1.668 mm · SupaVoxel 1.721 mm · both flat, parallel-sided, ≈4 extrusion widths at 0.4 mm
Winding consistency — Tripo inconsistent · SupaVoxel consistent · the Tripo file has to be flipped before it slices
Non-manifold edges / shells — Tripo 8 / 8 · SupaVoxel 148 / 100 · Tripo wins both rows clearly; the SupaVoxel mesh needs a merge pass
Support area at 120 mm — Tripo 6,761.4 mm² (16.50%) · SupaVoxel 4,858.5 mm² (12.01%) · 28.1% less to cut off the SupaVoxel print
Mean edge at 120 mm — Tripo 0.2326 mm · SupaVoxel 0.3335 mm · Tripo 1.43× finer, and a 0.4 mm nozzle cannot use it
Resin at 120 mm — Tripo 250.53 cm³ / $8.77 · SupaVoxel 232.74 cm³ / $8.15 · $0.62 apart
Cost of the tie — Tripo 55 credits · SupaVoxel 3 credits · 18.3×

Three things before the detail. Tripo is genuinely good on this subject and I will not pretend otherwise — on a clean, evenly lit, hard-surface object, Tripo resolves what is in the photo. Tripo hands you inconsistent winding, so every Tripo file in a batch needs its normals flipped; SupaVoxel hands you 100 shells, so every SupaVoxel file needs a merge. Neither is drop-in. And Tripo spent 1,954,511 triangles and 62.89 MB to reach the same three verdicts SupaVoxel reached with 997,355 and 5.63 MB.

For printing this arm at 120 mm I would use the SupaVoxel file — not because Tripo failed, but because the repair I would rather own is the scriptable merge, on the file that costs 3 credits instead of 55.

The single input, 1,403,490 bytes, sha256 3a7af565…. Two flat link plates, a triangular window on the lower one, a rounded-rectangle window plus a narrow slot on the upper one, an orange/red/yellow servo loom climbing to the wrist. One side only. Both products got this file byte for byte.

The test: three things that kill a cheap pipeline

I picked this subject for three failure modes a weak image-to-3D pipeline gets wrong in three different ways: a hollow window painted on as a dark patch instead of drilled, a thin cable smeared into the body, a flat plate inflated into a lozenge with no parallel faces.

Every printability figure below is measured after merging vertices by position — both exports split vertices along UV seams, and unwelded you are measuring texture seams and calling them holes. I scaled both meshes to a target height of 120.0 mm and assumed a 0.4 mm nozzle.

Window test: Tripo drilled four real holes, and so did SupaVoxel

The method is a parallel ray grid at 0.25 mm per pixel, fired from eight horizontal directions, counting only "miss islands" completely surrounded by hit region. A window painted on as dark texture, or modelled as a blind recess, can never produce an island.

From the front, Tripo produces four fully enclosed openings. SupaVoxel produces four. Tripo's two largest measure 132.31 mm² and 128.69 mm²; SupaVoxel's measure 149.56 mm² and 149.50 mm². Tripo's windows are real, and Tripo's frames are thicker — its openings are roughly 15% smaller in area, a shade further from the reference photo, not a defect.

The welded topology of the SupaVoxel mesh corroborates the count independently: Euler characteristic +30, total genus 85, and only 2 boundary edges, so those islands are genuine tunnels rather than artefacts of an open surface. Second-order number: the four holes cost 55 credits on Tripo and 3 on SupaVoxel.

SupaVoxel, front. Both windows read as openings, not dark patches. The loom climbs from a black base connector to the elbow, reading here as one thicker tube.

Tripo at the identical camera. Composition matches almost exactly; Tripo's window frames sit visibly heavier, and Tripo baked a yellow transverse texture into the upper slot where SupaVoxel's is bare.

The side view is the cheapest proof either product could offer

Looking down the thin edge of the link plates, the rounded-rectangle window shows the dark cavity behind it on both models, with two cable runs passing vertically through the opening. Tripo's opening sits lower and narrower; both frames are continuous and closed. One difference nobody can grade: the base's top face carries four black connector posts on the SupaVoxel model and three on Tripo's, and the photograph does not show that surface.

SupaVoxel, side. The window is fully open to the cavity, the frame an unbroken white rim, two orange runs arching onto the base connectors.

Tripo, same camera. Also fully open, placed lower and narrower, cables crossing it orange-brown. Three base posts against SupaVoxel's four — both invented.

Strip the textures and Tripo's cable is still standing

This is the hardest evidence in the case and it goes to both products. With every texture removed, the windows on both meshes are still black holes and the cable on both is still a raised tube leaving the body. Neither Tripo nor SupaVoxel painted a feature it did not build.

The measurement behind that: sample vertex baseColor through the UVs, isolate the orange/red cluster, then measure each orange vertex's distance to the nearest non-orange vertex. A painted-on stripe scores near zero. Tripo's cable peaks at 4.158 mm of standoff (p90 1.670 mm); SupaVoxel's peaks at 10.337 mm (p90 4.551 mm), 2.49×. The SupaVoxel loom genuinely bridges open air over the triangular window; Tripo's hugs the body.

For a printer that is not automatically a SupaVoxel win. A 10.337 mm unsupported span of thin tube needs support or a bridge; Tripo's 4.158 mm is easier to lay down. Tripo wins the printability of the cable run.

SupaVoxel, textures off. Windows still black openings, cable still a tube standing off the chassis with a clearly airborne section.

Tripo, textures off, same camera. Windows and cable all present — no texture cheating on either side. Tripo's loom is several fine parallel ridges where SupaVoxel's is one thick ridge; at 0.4 mm neither survives.

Plate thickness: both flat, SupaVoxel more consistent

Face-to-face rays fired only at the link segment (the 45–118 mm band of the 120 mm model) give a bimodal thickness distribution — a thin-plate mode and a ~26 mm mode where the ray crosses the whole arm body. Only the sub-8 mm mode is the plate.

Tripo's plate median is 1.668 mm across 834 rays; SupaVoxel's is 1.721 mm across 866. The medians are effectively the same, and SupaVoxel's consistency is 1.51× better. At 0.4 mm that median is about 4.3 extrusion widths — two perimeters plus a little infill, the textbook printable plate. Neither product made a paper-thin fin, neither inflated it into a block.

Plate median — Tripo 1.668 mm · SupaVoxel 1.721 mm · tie
Plate IQR / std dev — Tripo 0.838 / 1.186 mm · SupaVoxel 0.554 / 0.763 mm · 1.51× more uniform

Where Tripo wins outright: 8 non-manifold edges against 148

This is the row SupaVoxel loses, and it loses it by a wide margin, so here it is unhedged. Welded, Tripo's mesh carries 8 non-manifold edges and 8 connected shells. SupaVoxel's carries 148 and 100 — 18.5× and 12.5×. The SupaVoxel file is assembled from many more fragments and needs one merge-and-clean pass before it slices as a solid: real work, scriptable for a batch, but not a checkbox.

What comes back the other way is consistent winding where Tripo is inconsistent, and 2 boundary edges where Tripo has 14 (unwelded, 48,367 against 85,447, 1.77×). Tripo's mesh has to be flipped and its open loops closed; SupaVoxel's has to be merged. Neither product ships something you can slice untouched. The exchange rate: that merge buys an 18.3× credit difference and an 11.18× file difference.

Non-manifold edges / shells — Tripo 8 / 8 · SupaVoxel 148 / 100 · Tripo wins both
Boundary edges (welded) — Tripo 14 · SupaVoxel 2 · SupaVoxel wins
Winding — Tripo inconsistent · SupaVoxel consistent · SupaVoxel wins
Euler characteristic — Tripo −73 · SupaVoxel +30 · watertight on neither

One row does go the other way. Slivers — the long, near-zero-area triangles that self-intersecting toolpaths come from — run 1,510 on Tripo's welded mesh against 233 on SupaVoxel's, 6.48×, with 0 degenerate faces on both. That does not cancel SupaVoxel's 148 non-manifold edges; they are different repairs, and on this subject Tripo's mesh hygiene is the better one overall.

Support area: 1,902.9 mm² less to cut off

At 120 mm and a 45° threshold, Tripo needs support on 6,761.4 mm² (16.50% of its surface) against SupaVoxel's 4,858.5 mm² (12.01%) — 1,902.9 mm² and 28.1% less, or 190,290 mm² less across a batch of 100.

Welded solid volume is 250.53 cm³ for Tripo against 232.74 cm³ for SupaVoxel, at $35/L $8.77 against $8.15 — $0.62 apart. Physically these are almost the same object, so whatever the extra 52 credits purchased, it did not become a millilitre of material on the build plate.

SupaVoxel's in-product X-Ray mode. Both windows stay empty in transparency and the frames read as closed loops — the same four openings the offline ray test counted, in one click.

Mean edge length: Tripo is 1.43× finer and your nozzle cannot tell

Tripo's mean triangle edge at target height is 0.2326 mm against SupaVoxel's 0.3335 mm. Tripo is 1.43× finer and that row belongs to Tripo — it just does not reach the part. A 0.4 mm nozzle sees Tripo's edge at 0.58× and SupaVoxel's at 0.83×, both already under the nozzle, so the slicer discards detail from both at the same rate. To cash it in you need SLA. On FDM the exchange rate is 1.43× edge fineness for 18.33× the credits and 11.18× the file.

Getting the file out: two clicks each, two dialogs to dismiss first

Click count ties: both products reach a file on disk in 2 steps. The path is not the same. SupaVoxel's Export is one toolbar dropdown opening onto everything at once — GLB, OBJ, STL, USDZ, 3MF, plus Copy URL, Fix Mesh, 3D Printing and Embed — on the same screen as the inspection modes, nothing to close first. Tripo's Export button sits in the bottom bar, and by the time you reach it you have dismissed two overlays: the View Your Model panel during generation, then a five-video Guide after completion.

Tripo's export dialog offers File Name, Format, and Texture Resolution pre-set to 4k (Current). I opened both dropdowns looking for more — there is nothing more. No triangle budget, no topology cleanup, no geometry-only option. That 4k default is where 62.89 MB comes from.

SupaVoxel's export dropdown: five formats plus Fix Mesh in one menu. With 148 non-manifold edges, that repair entry is not decoration.

Tripo after generation: close one overlay, get another. The Guide panel's lower edge overlaps the Export button in the bottom bar.

Tripo's export dialog. Three fields, Texture Resolution on 4k (Current), no warning that most of those bytes never reach the print.

The same Tripo dialog with both dropdowns engaged — identical fields. Format and texture resolution are the whole control surface.

Final verdict: Tripo scores 64/100 on this build

Tripo's extra 957,156 triangles bought a mean edge a 0.4 mm nozzle cannot use, a cable run that prints more easily, cleaner shell structure and 1,277 extra slivers. They did not buy a hole SupaVoxel failed to drill, a cable SupaVoxel failed to build, a millilitre of resin, or a square millimetre less support.

Tripo passes the stress axis outright and beats SupaVoxel on shell structure and on the cable's printability. That is a real result and I am scoring it as one. Tripo then asks 55 credits for it, ships inconsistent winding that must be flipped on every file, asks for 39.2% more support area, and puts 62.89 MB on your disk. SupaVoxel scores 89/100: the same three passes, larger openings, more uniform plates, consistent normals, 2 boundary edges, 28.1% less support, 3 credits — against one honest debt, a 100-shell mesh to merge.

The conclusion here is not a defeat for Tripo. It is that on an easy, well-lit, hard-surface subject the two products converge — so what separates them is price, and what happens on harder subjects.

Which one I would use for this job

Same photograph, 3 credits, 5.63 MB, consistent winding, 2 boundary edges, 12.01% support area, five export formats and a mesh repair entry in the same menu — supavoxel.com. Bring your own reference and look at the untextured mesh first; that is where this comparison was decided, and on this subject it decided in favour of both.

Meshy AI Review 2026: 35 Credits and 9.86 MB for One Table Lamp

Mei Ferreira — Wed, 14 Oct 2026 15:44:51 +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.

I had one picture of a sculptural ceramic table lamp and a room render that needed it.

Two names kept getting recommended to me for turning a picture into a 3D model: Meshy, and SupaVoxel (https://supavoxel.com).

So I ran the same picture through both, once each, and then went looking at the receipts — what came off the counter, what landed on disk, how long I sat there waiting, and what I still had to do afterwards.

Here's what one lamp actually costs.

My verdict in 60 seconds — Meshy 58/100, SupaVoxel 90/100. My own marks for this one job, nothing more.

What's inside the bytes you pay for — Meshy 9.86 MB holding 76,034 triangles vs SupaVoxel 9.60 MB holding 1,500,000 · Meshy 5/10 · SupaVoxel 9/10 — Meshy charges you the larger file for the coarser shape; SupaVoxel puts twenty times the detail in slightly less weight.
File size on its own — Meshy 9,858,280 bytes vs SupaVoxel 9,603,872 bytes · Meshy 8/10 · SupaVoxel 8/10 — tie: 254,408 bytes and 2.58% apart is noise, so neither Meshy nor SupaVoxel earns anything on this row and nobody should sell you one on it.
Mobile download at 12 Mbps — Meshy 6.57 s vs SupaVoxel 6.40 s · Meshy 8/10 · SupaVoxel 8/10 — tie, by arithmetic on those byte counts: a sixth of a second between Meshy and SupaVoxel is not a decision.
A hundred copies on disk — Meshy 0.99 GB vs SupaVoxel 0.96 GB · Meshy 8/10 · SupaVoxel 8/10 — tie again, arithmetic at ×100: Meshy's storage bill and SupaVoxel's are the same bill.
A time on the record — Meshy not captured vs SupaVoxel 255.102 s · Meshy 5/10 · SupaVoxel 8/10 — Meshy left me with no elapsed figure at all, so I can't plan around it; SupaVoxel logged a number you can schedule against.
Price shown before you click — Meshy 35 on the Generate button vs SupaVoxel 3 on its own button · Meshy 8/10 · SupaVoxel 8/10 — tie on transparency, and it has to stay a tie: two different plans, two different units, not a price ratio.
Did the run break — Meshy 0 failures vs SupaVoxel 0 failures · Meshy 9/10 · SupaVoxel 9/10 — tie, and the good kind: Meshy came back first try, SupaVoxel came back first try, and retry counts weren't captured on either side.
What the export menu gives you — Meshy one format dialog vs SupaVoxel five formats plus compressed and original-size GLB · Meshy 6/10 · SupaVoxel 9/10 — Meshy makes you come back and re-export for another format; SupaVoxel hands you the web version and the importer-safe version off one run.

One image, one run each. Not a study.

The picture that went into both tools, unchanged. Hooked waist, linen shade — the two things I was paying to get back.

So what does one lamp cost to make?

Meshy's run recorded 35 Meshy credits. The other run recorded 3 SupaVoxel credits.

Now stop. Do not do the division.

Meshy's counter and the other tool's counter are two separate plans with two separate units, and I never captured what a credit is worth on either one. 35 and 3 are two unrelated counters, not a price ratio. Anyone turning that into "11 times cheaper" is inventing the part that matters.

What you can take from it: go look at what a credit costs on your own plan, then multiply by this run's counter. That's a real number. Mine isn't.

Meshy's settings before I hit go — the Ultra 2K resolution preset, texture on, image enhancement on, multi-view off, split off, pose off. The 35 is sitting right there on the button.

Credit where it's due: both of them show you the price first

I like this about Meshy. Meshy prints the cost on the Generate button before you commit — right next to the resolution and texture switches.

The other panel does the same thing in its own units. Its button reads Generate (3 credits). Again: two different plans, two different units, not a price ratio — just two products being upfront.

Neither tool made me guess what a click would cost. That sounds like a low bar. Go use a few AI tools and you'll find out it isn't.

The other upload panel, same picture, price on the button.

I didn't tune anything, and neither should you for a first run

Defaults on both sides. I didn't touch Meshy's panel and I didn't touch the other one, whose advanced settings sat at 5 inference steps, guidance 5.5, background removal on, octree resolution 256.

Why does this matter to you? Because tuning is where people burn credits, on Meshy and everywhere else. Three runs at "let me just try one more setting" and you've spent your budget on experiments instead of props.

Start on defaults. Judge the defaults. Tune only if the defaults fail you.

There's a second reason. If you tune Meshy and not the other one, you no longer have a comparison — you have a story about your own settings. Meshy on defaults versus the other on defaults is the only fair version of this test I could run in an afternoon.

Untouched defaults on the other side: 5 steps, guidance 5.5, background removal on, octree 256.

Then you wait — and only one of them told me how long

The other tool's record says 255.102 seconds. Call it four and a half minutes.

Meshy's generation time was not captured on this run. I don't have it. I'm not going to estimate it from a progress bar and I'd be suspicious of anyone who does.

So there's no speed verdict in this article. If someone quotes you a Meshy timing from a comparison like this one, ask them where the number came from.

While we're being strict about unknowns: retry counts weren't captured on either side either. Whether Meshy quietly re-attempted anything internally, I can't say. Unknown stays unknown.

Meshy working through the job. A progress readout is a screenshot, not a stopwatch.

The bigger file is the one with less in it

This is the row that made me sit up.

Meshy's download: 9,858,280 bytes. The other: 9,603,872 bytes. Meshy's is the larger of the two.

And Meshy's larger file is carrying 76,034 triangles while the smaller one carries 1,500,000. Meshy charged you more bytes for less shape.

Underneath that: 43,446 vertices on Meshy's side against 815,486. Vertices are the corner points the triangles hang off, and they're what your scene actually has to hold in memory — so Meshy is asking your GPU for a lot less.

Same weight in your bucket. Twenty times the detail in one of them. If you're paying for storage and bandwidth either way, that's where the actual value gap sits — not in the byte count everyone quotes.

Meshy's finished panel, reporting Triangle topology and 76,034 faces. My own parse of the downloaded file agreed.

What does that mean when you put it on a website?

Let's price the wait, with the assumption stated up front.

At a steady 12 Mbps — think a decent phone connection — Meshy's file is about 6.57 seconds of pure download and the other is about 6.40. That's arithmetic on the byte counts, not a load test, and Meshy loses it by a rounding error.

The difference is roughly a sixth of a second in Meshy's favour or against it, depending which way you squint. Nobody has ever bounced off a page over a sixth of a second.

File size is not the reason to pick between these two. Stop optimising the row that doesn't move.

One caveat so you don't over-read even that: this is transfer time only. Decoding, texture upload, first frame and device performance are not in the number, and I didn't measure any of them.

Meshy's lamp at the shared hero camera. 9.86 MB of it, with 3 embedded textures.

And on a desktop connection?

Same arithmetic, different stated assumption — a steady 100 Mbps, no cache, no latency.

Meshy's file is 0.79 seconds of pure transfer. The other is 0.77.

Two hundredths of a second. On a desktop line, Meshy's file size is a non-issue, and I'm not going to pretend otherwise just to give Meshy a bad row.

If somebody is selling you one of these tools on download speed, they've run out of arguments.

Now multiply by a catalogue of 100

Say you're building a showroom library — a hundred fixtures, not one lamp.

Copy this run's output 100 times and Meshy takes 0.99 GB of disk. The other takes 0.96 GB. That's an arithmetic scenario assuming every file is the same size, not a hundred real runs, and it says nothing about how often either tool succeeds at scale.

Thirty-odd megabytes apart across a hundred props. Your object storage bill will not notice whether you used Meshy.

The other file at the same camera. 9.60 MB, also 3 embedded textures, 1,500,000 triangles underneath.

The counter that actually scales

Storage isn't your constraint. The counter is.

A hundred runs at this run's rate comes to 3,500 Meshy credits on one side and 300 SupaVoxel credits on the other. Same warning as before — different plans, different units, not a price ratio — and the same assumption, that every run charges what this one charged and nothing fails.

That's the multiplication worth doing with your own plan's numbers in front of you — Meshy's rate on Meshy's plan, the other's on its own — because it's the one that decides whether a catalogue is a weekend or a quarter.

Check the counter, not the disk.

What that 2.58% is not telling you

I keep seeing byte counts used as proof that one model is "more efficient". Here's why that's nonsense in this case.

The smaller file is the compressed export — a squeeze step that packs the geometry down. Meshy uses no such compression at all, so Meshy's bytes are raw where the other file's are squeezed.

So you're comparing a squeezed file to an unsqueezed one and calling it efficiency. The gap is 254,408 bytes, and it's a packaging artefact, not a verdict on Meshy.

Different packing, not different skill. Judge the two files on what's inside them, which is where the 76,034-versus-1,500,000 gap lives.

The other result view, reporting 1,500,000 triangles on the same lamp.

Did either run fail on me?

No. 0 failures on Meshy, 0 failures on the other side. First try, both of them.

Both downloads came out as GLB on both sides — that's the container format holding shape and textures in one file — so everything I measured came from two directly comparable files.

And one lamp through Meshy tells you nothing about how Meshy behaves on its hundredth job. That's not what a single run can measure, and I'd distrust any review that claims otherwise from this much evidence.

Meshy from behind: clean, closed, no holes. Whatever Meshy's run cost on its own plan, it didn't come back broken.

The line item nobody budgets for: a second version of the file

Here's a cost that never shows up on a counter — the day someone at the far end can't open what you sent.

The SupaVoxel export answers that before it happens. The same menu gives you a compressed GLB for anything going over the wire and an original-size GLB for a picky importer, a locked-down client pipeline or an older viewer. One run, both deliverables, no re-generation and no converter to go find.

Price that against your own hourly rate. An afternoon spent converting a file you already paid for costs more than every download-speed difference in this article put together.

From Meshy you get one format dialog per trip, so a second variant means going back through it. I didn't test either file in a specific importer, so treat this as what the two menus offer, not a failure I watched happen.

Same camera, other file — 2.58% fewer bytes, and 1,500,000 triangles inside them.

What neither invoice buys you

Meshy's file reports 0 emissive materials, and so does the other. Neither lamp emits light. Drop either one into a scene and you are placing that light yourself.

Nothing in this test touched real photometrics, wiring, light-transmitting materials, physical dimensions or whether this shape could be manufactured. Not tested on either side, so not claimed for either side.

If you need a lamp that behaves like a lamp, Meshy's output and the other one are both a starting mesh and a to-do list.

Where Meshy actually wins

Three of them, each with what it costs you.

Meshy's main file declares no required glTF extensions, so it opens wherever GLB opens with no decoder in the chain. Worth adding straight away: taking the original-size GLB on the SupaVoxel side drops that requirement too, so this is a default Meshy has rather than a wall the other tool runs into. Either way, the price of Meshy's version is 76,034 triangles instead of 1,500,000.
Meshy's download box lets you set a real height in centimetres and choose the origin point. Genuinely handy when props have to land at the right scale in a scene, and it saves you a rescale step downstream. The other panel didn't offer it. This one costs you nothing — Meshy just has it.
Meshy's geometry is far lighter to hold in memory — roughly 2.30 MB against 44.10 MB on a standard layout of 32 bytes per vertex and 4 bytes per index, three indices per triangle. That's arithmetic, not a benchmark, and it excludes textures and engine overhead. Filling a scene with dozens of props? That's Meshy's argument, and it's a good one.

Two of those three are the same trade in different clothes: Meshy gives you portability and lightness, and charges you detail for it.

So which one would I run again for this job?

For a hero lamp somebody's going to look at closely: the dense file, not Meshy's — compressed GLB for the web, original-size GLB for whoever needs it plain, both out of the same run.

For forty background props into software I don't control: Meshy, without hesitating.

The invoice is only half the decision. The other half is what you still have to fix after the file lands.

Meshy's shade from above — empty apart from a centre nub. Part of what those 76,034 triangles didn't get spent on.

How I tested this

One picture, one run per tool, defaults on both sides. Meshy ran on its Ultra 2K preset with texture and image enhancement on and multi-view, split and pose off; the other ran at 5 inference steps, guidance 5.5, background removal on, octree 256. Both outputs downloaded as GLB and parsed offline, then rendered in one viewer with fixed lights and identical numeric cameras, with Meshy's file handled exactly like the other.

Measured from the files and the task records, Meshy first in every pair: credits (35 / 3, in each product's own units), file size (9,858,280 / 9,603,872 bytes), triangles (76,034 / 1,500,000), vertices (43,446 / 815,486), embedded textures (3 / 3), download format (GLB / GLB), failures (0 / 0), required extensions (none / meshopt + quantization), emissive materials (0 / 0), elapsed (not captured / 255.102 seconds).

Calculated, not measured: download seconds at a stated 12 Mbps (6.57 / 6.40) and 100 Mbps (0.79 / 0.77), a hundred copies on disk (0.99 / 0.96 GB), a hundred runs on each product's own counter (3,500 / 300), and the memory estimate at 32 bytes per vertex and 4 per index (2.30 / 44.10 MB). Every one of those is arithmetic on the measured values with the assumption stated, not an extra run.

One conditional: if the importer at the far end has no meshopt support, Meshy's main file can be tried as-is and the SupaVoxel side answers it with the original-size GLB from the same menu — that case is exactly why the dual export is there. Untested in any real package.

Not captured: Meshy's elapsed time, retry counts on both sides, and what a credit is worth on either plan. Those stay blank, including in the Meshy column.

The other shade from above: a spoked fitter the reference picture never showed. Invented, and useful.

Try it with your own image

A single lamp is a single lamp. Your product isn't mine, and your plan isn't mine either.

Take the picture of the thing you actually need, run it through Meshy and through the other one, then open the files and look. That's an afternoon well spent. Meshy is easy to find, and the other one is at https://supavoxel.com

Hyper3D Credits Review 2026: 0.5 UI Price, Then a Download Wall

Mei Ferreira — Mon, 12 Oct 2026 15:53:46 +0000

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

I pressed Generate expecting to leave Hyper3D with a textured leaf-shaped cable clip. The Gen-2.5 result looked convincing on screen and its button said 0.5 Credits. Then I selected GLB, pressed Download and met a subscription gate. The downloadable result required a separate Gen-1.5 run and a separate material pass. This is why I now follow the file and the receipt, not the first number on a button.

My verdict in 60 seconds — SupaVoxel supplied the attributable, textured file; Hyper3D Free's attractive Gen-2.5 preview stopped at Download. The 0.5 Hyper3D credit advertised for Gen-2.5 is a UI tariff, not this leaf task's isolated debit. A different Gen-1.5 run used a verified 0.5 credit for geometry Confirm, but its material-stage charge remains unknown. The SupaVoxel Hobbyist run linked one successful textured result to a −3 transaction in its own credit units. These are different plans, currencies and stages: no sixfold price or dollar winner follows. Hyper3D wins file weight and offers FBX; for a budgetable full-color deliverable I would start in SupaVoxel.

Eight side-by-side checks, Hyper3D then SupaVoxel:

Usable textured result on tested access — Hyper3D Gen-1.5 worked but Gen-2.5 was blocked; the tested SupaVoxel Hobbyist result exported.
Complete-file debit attribution — Hyper3D material-stage cost is unknown; one complete SupaVoxel request has a linked −3 transaction.
Material workflow — Hyper3D needed a separate Generate and Confirm after geometry; SupaVoxel's completed request yielded textured output.
Format choice — Hyper3D lists FBX; the tested SupaVoxel menu did not.
Actual browser transfer — Hyper3D sent a 25.30 MB ZIP; SupaVoxel's chosen Original size GLB was 94.45 MB.
File availability after preview — Hyper3D Free required a separate Gen-1.5 job; SupaVoxel let this account export the generated result.
Timing scope — Hyper3D material time is missing; SupaVoxel recorded a 266.139-second request lifecycle, not a matched total job clock.
Repeat-job budgeting — Hyper3D's complete PBR debit remains blank; SupaVoxel's one-request transaction is attributable, not a 100-job guarantee.

A money comparison cannot be calculated from credits in two unrelated plans while one complete-file debit remains unknown.

What did both services actually receive?

The same 1,811,538-byte leaf PNG went into each product. It shows an open clip and screw hole, not a fully dimensioned drawing.

I tested one image, not ten variants and a cherry-picked winner. Hyper3D received it first on its Free account; SupaVoxel received the SHA-matched PNG on Hobbyist. Within Hyper3D I ran two distinct generations: Gen-2.5 for the newer preview, and Gen-1.5 to obtain a downloadable comparison file. SupaVoxel ran one full generation. Two Hyper3D tasks versus one SupaVoxel task is not a controlled same-operation cost test. The source image was AI-generated with a third-party product cover as visual inspiration; no publication-rights conclusion follows for that underlying reference. These two offline renders are the actual exported textured files, not the gated Gen-2.5 screen; they establish what the different billing paths delivered visually.

Hyper3D's downloadable Gen-1.5 PBR leaf: the material-confirmed result measured in the ZIP, not the undownloadable million-face preview.

SupaVoxel's textured Original size UI export from the matching input: this is the file attached to the request-specific −3-credit transaction.

Is the displayed 0.5 a receipt for this leaf?

Hyper3D Gen-2.5 / High advertises 0.5 Credits beside the Generate control; the Free account shows five credits at this point.

No. 0.5 Hyper3D credit is a UI tariff for that Gen-2.5 choice, not a debit isolated to this leaf task. The shared account's displayed balance moved 5 → 4 while another case was active on the same login. You cannot bill a full credit to my leaf, nor divide the difference in two and claim each model cost half. A separate pilot established how the button was intended to charge, but it does not replace this case's missing transaction attribution. Five was an observed balance, not proof that free credits renew daily, or at any other interval. When a plan has a shared meter, record a before/after per task before promising a unit cost.

Why was the most impressive result not my asset?

The Gen-2.5 information panel reports 1,000,000 faces / 578,198 vertices and shows a Print-Ready label. These are UI claims for an undownloaded preview.

The last-mile test: after selecting GLB, Download asks this Free account to subscribe for Gen-2.5 models.

I could rotate the Hyper3D preview and choose a format. Only on Download did the restriction become unmistakable: “Subscribe to download Rodin Gen-2.5 models. Gen-1.5 downloads stay free!” I bought nothing, so I have no Gen-2.5 GLB for this leaf. A million faces shown by an interface cannot be carried into an offline topology audit or priced as a free downloadable product. The practical consequence was to start again on Gen-1.5. That means the actual file discussed in the companion geometry review is not a low-cost export of the Gen-2.5 screen; it is a separate 120,000-face generation.

What charge can I really tie to the Gen-1.5 file?

I opened a new Hyper3D Gen-1.5 job with the same image to get a file the Free account could download.

Gen-1.5 geometry Confirm follows the free preview; adjacent case evidence isolates the 4 → 3.5 credit movement at this step.

The Gen-1.5 preview was free in the observed path. Its Geometry Confirm took the shared account from 4 to 3.5, checked with an adjacent authoritative balance read, so 0.5 Hyper3D credit is attributable to *this geometry confirmation. Stop the sentence there. The job was not yet the green textured object pictured in the article; its first geometry-only GLB measured **4,184,164 bytes and zero embedded textures*. I cannot add the separate Gen-2.5 button tariff to this charge. I cannot call 0.5 the final textured-file price. Precision about which click the half-credit belongs to matters more than a headline ratio against another product.

Why does material need its own blank invoice cell?

The material pane asks for a new Generate after geometry; color was not part of the first file.

The final successful Material Generate → Confirm produced the textured option; the shared-account balance does not isolate its charge.

There was an early material attempt that showed 0% and returned to Generate without a proven completed result. A later attempt succeeded. I counted the two successful material actions, then selected .glb and Download. During that window the shared header moved 3.5 → 3.0 while another run overlapped. That movement is not evidence that this leaf's material cost exactly 0.5, exactly zero, or any other number. Neither Material Generate nor Material Confirm has a full independent debit record for this case. The complete Hyper3D PBR-file price is therefore unknown. Anyone multiplying a known geometry charge by a hundred to claim the cost of a hundred green finished assets has silently skipped the material stage.

What makes the SupaVoxel receipt different?

SupaVoxel shows Generate (3 credits) before the request; only one image slot was used.

The finished textured leaf corresponds to one completed request with one request-linked −3 credit transaction.

SupaVoxel's record ties this input hash to a specific successful request and a −3 SupaVoxel-credit transaction. Its button also said 3; here the display and transaction agree. The exact instant of debit inside that request was not captured, and the later shared-account balance cannot isolate this job, but the request-linked debit can. This is a stronger budgeting line for one complete textured deliverable than a shared global balance snapshot. I will not claim SupaVoxel costs less in dollars than Hyper3D: the plans use unrelated credit denominations, and Hyper3D's finished-file debit is still missing. My preference for SupaVoxel is about traceability and a completed textured file, not a fictitious 6:1 bargain.

Does a faster geometry clock mean earlier file delivery?

Hyper3D Gen-1.5's measured preview and Geometry Confirm phases total 40.638 seconds; material and export are outside that window.

Hyper3D recorded 25.329 seconds for its Gen-1.5 preview and 15.309 for geometry confirmation. Summed, that is 40.638 seconds of known compute phases. Its Gen-2.5 preview and confirmation took 76.724 and 36.154 seconds on a different run. I did not capture the complete material-stage wall time. SupaVoxel's matched request row spans 266.139 seconds from creation to update, including its internal waiting but excluding earlier upload and later export. Those clocks start and stop at different places. Calling Hyper3D “225 seconds faster” would compare a partial geometry journey with a complete request lifecycle, while hiding the material actions that actually yielded a textured leaf.

What did I download instead of a price-card promise?

Hyper3D's 2K Shaded + PBR selection delivered a ZIP; the PBR member is not the whole website transfer.

Hyper3D's browser sent a 25,304,144-byte ZIP containing a 16,640,756-byte PBR GLB and an 8,663,136-byte Shaded GLB. I analyzed the extracted PBR member, but I had to receive the ZIP to get it. SupaVoxel's tested Export → GLB → Original size produced a 94,453,592-byte GLB. On a hypothetical clean 12 Mbps line, bytes × 8 ÷ bandwidth gives 16.87 versus 62.97 seconds of pure website-download transfer. Hyper3D wins that row decisively. SupaVoxel displayed a Compressed alternative, but I did not download it; the 94.45 MB number is not a claim about every SupaVoxel export.

Can five trial credits fund a hundred jobs?

No. The Hyper3D Free account showed five credits at one point. Divide that by the isolated 0.5-credit Gen-1.5 geometry Confirm and, only if there are no other debits or renewals, you get at most ten geometry confirmations from those observed credits. You do not get ten fully costed PBR leaves. Scaling the one known geometry charge to 100 confirmations gives 50 Hyper3D credits for geometry alone; material, access to additional credits and actual success rate remain unknown. Scaling SupaVoxel's single complete request to 100 identical successes gives 300 of its own credits, arithmetic rather than a tested batch. Different units, different stages. Neither 50/300 nor ten/100 tells a creator which cash plan to buy.

What export choices remain if my pipeline needs FBX?

The SupaVoxel GLB submenu shows Compressed and Original size; only the latter became a measured file.

Hyper3D lists FBX, OBJ, GLB, USDZ and STL; SupaVoxel's observed menu lists GLB, OBJ, STL, USDZ and 3MF, not FBX. If your next tool strictly demands FBX, that is a real Hyper3D advantage. For this textured GLB job, however, SupaVoxel needed Export → GLB → Original size, three selections. After Hyper3D geometry confirmation, comparable textured output required Material Generate → Confirm → .glb → Download, four successful operations and ZIP extraction if I wanted only PBR. Counts of selections are not timed labor, and a Free Gen-2.5 paywall cannot be solved by choosing a different format.

Final verdict: what can I honestly put on a budget line?

Hyper3D Gen-2.5 showed 0.5 as a tariff, but no task-isolated debit and no Free-tier download. Its separate Gen-1.5 geometry Confirm demonstrably used 0.5 Hyper3D credit, while the full material-confirmed PBR debit remains unknown. SupaVoxel yielded a finished textured file linked to one −3 transaction in SupaVoxel's own credits. Hyper3D's actual ZIP was much lighter and FBX may make it the correct tool for a different pipeline. For the one finished, attributable textured leaf in this test, I pick SupaVoxel; I do not convert either service's credits into money.

Use SupaVoxel when the deliverable needs an attributable receipt

If you need the file rather than an attractive gated preview, SupaVoxel gave me an attributable full-request debit and a direct GLB export. Budget bandwidth for the tested Original size branch, or separately measure its Compressed option before planning a web catalog. Hyper3D Gen-1.5 deserves consideration when you need FBX or a smaller observed browser transfer, but first run its entire material path with an isolated balance ledger to learn what the completed object actually costs.

How I checked these claims

One SHA-checked leaf image was reused. The Gen-2.5 Hyper3D tariff came from UI and a separate pilot rule, not a debit isolated to this leaf; shared balance differences during parallel tasks are deliberately not assigned. The Gen-1.5 geometry debit was isolated between adjacent balance observations; its two material actions were not. SupaVoxel's charge came from a transaction tied to the successful SHA-matched request. Browser-downloaded packages and GLB member sizes were measured directly. Transfer seconds, 100-job credits and ten-confirmation ceiling are arithmetic under ideal bandwidth/no other debits, not performance, replenishment or cash-plan findings. Neither a complete end-to-end timing comparison nor paid Hyper3D subscription pricing was measured.

Meshy AI 3D Review 2026: 76,034 Triangles for a Sculptural Lamp

Mei Ferreira — Sat, 10 Oct 2026 15:45:30 +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.

I needed one hero lamp for a living-room render. A sculptural ceramic thing with a hooked, off-centre waist and a linen drum shade.

I had a picture of it. I did not have a model of it.

So I asked around for an image-to-3D tool, and two names kept coming back at me: Meshy, and SupaVoxel (https://supavoxel.com). Fine. I uploaded the same picture to both, once each, left every setting on its default, and downloaded whatever came out.

Then I opened both files and took them apart.

My verdict in 60 seconds — Meshy 62/100, SupaVoxel 89/100. Those are my own subjective marks for this one job, not a lab result.

Triangles in the mesh — Meshy 76,034 vs SupaVoxel 1,500,000 · Meshy 5/10 · SupaVoxel 9/10 — Meshy describes a compound curve with a budget you can count by eye in a wireframe; SupaVoxel spends about twenty times as many plates on the same hooked waist.
Vertices — Meshy 43,446 vs SupaVoxel 815,486 · Meshy 5/10 · SupaVoxel 9/10 — Meshy's corner points run out exactly where the curve changes direction; SupaVoxel gives the surface enough points to keep turning.
Inside the shade — Meshy empty drum with a centre nub vs SupaVoxel spoked fitter, hub and bulb form · Meshy 5/10 · SupaVoxel 8/10 — Meshy leaves a hole the moment your camera rises above table height; SupaVoxel puts structure there for it to land on.
Which way it faces at yaw 0 — Meshy a smooth egg vs SupaVoxel the reference silhouette · Meshy 6/10 · SupaVoxel 9/10 — Meshy's model arrives rotated, so every asset needs a manual spin; SupaVoxel's lands facing the camera you already set up.
Getting the file out — Meshy a download dialog with a format dropdown vs SupaVoxel a five-format menu plus compressed and original-size GLB · Meshy 6/10 · SupaVoxel 9/10 — Meshy puts a dialog between you and the file; SupaVoxel hands you web-ready and importer-safe versions from the same click.
Download format — Meshy GLB vs SupaVoxel GLB · Meshy 8/10 · SupaVoxel 8/10 — dead tie: both delivered the same container, so everything below is measured on directly comparable files and neither tool gets a point here.
Embedded textures — Meshy 3 vs SupaVoxel 3 · Meshy 7/10 · SupaVoxel 7/10 — tie on the count, and it stays a tie because I never measured resolution; Meshy simply spent the same three maps on a shade that came back flat.
Emissive materials — Meshy 0 vs SupaVoxel 0 · Meshy 5/10 · SupaVoxel 5/10 — tie, and a poor one for both: Meshy's lamp emits no light and neither does SupaVoxel's, so you are placing that light yourself either way.

This is one image and one run on each side. Not a study.

The picture I started with. Note the hooked waist — that curve is the entire reason anyone would buy this lamp, and it's the thing I'm checking in every image below.

So what actually shows up when someone zooms in?

Meshy's file came back with 76,034 triangles. The other file came back with 1,500,000.

Here's what that means if you're not a graphics person. Triangles are the little flat plates a 3D shape is built out of. A curve isn't really a curve — it's a lot of tiny flat plates pretending to be one.

Meshy is describing that hooked waist with 76,034 plates. The other tool uses about twenty times as many. Same curve, very different number of plates pretending to be it.

At thumbnail size nobody can tell. The moment your camera walks up to the lamp, they can.

Where Meshy's number bites: a product page where the customer can pinch-zoom. A close-up in a moodboard. Anything where the lamp fills more than a third of the frame. That's the moment Meshy's plate count stops being an abstraction.

Meshy's raw mesh with the texture switched off, so you're looking at shape only. The silhouette is right. The question is how finely it's carved underneath.

Try the wireframe test — it takes ten seconds

Load the model, switch the viewer to wireframe, zoom to half. That's it. That's the whole test, and I'd run it on Meshy's file before I ran it on anything else.

On Meshy's lamp you can trace individual triangles with your finger. Across the shade, down the body, all of them readable. That is Meshy's whole detail budget, visible to the naked eye.

That's not a criticism of Meshy's art direction. That's just what 76,034 triangles look like on an object this size.

You'll also notice Meshy's triangulation is uneven — dense in some patches, stretched in others. That isn't automatically bad, and Meshy is far from alone in doing it. It does mean the detail isn't spread evenly over the shape, so the places Meshy decided were simple stay simple even if that's where your camera lands.

Meshy at wireframe zoom 0.5. Countable, and visibly irregular across the shade. If you can count them, so can a close-up camera.

Now run the same test on the file Meshy is up against

Same viewer. Same camera numbers. Same zoom.

It comes out solid black. The 1,500,000 edges overlap so heavily there's no wireframe left to look at — where Meshy gave me a diagram, this gives me a wall.

That's not a prettier picture — it's a denser one. And density is exactly what you want when the product you're selling is a curve.

One file gives you a shape you can inspect at arm's length. The other gives you one you can inspect with your nose against it.

Same numeric camera, same wireframe mode, other file. There's nothing to count — the edges fill in solid.

What about vertices? Does that number matter to you?

Meshy's file holds 43,446 vertices. The other holds 815,486.

Vertices are the corner points the triangles hang off. The reason to care: it's the vertex count, not the triangle count, that usually decides how much memory your scene spends holding the shape.

So 43,446 is Meshy being deliberately economical. That's a real engineering position, not laziness, and Meshy is consistent about it across the whole model.

It's also the reason Meshy's lamp will load into a crowded scene without anyone noticing, and the other one won't. I'll put actual megabytes on that in a minute.

Meshy from the side. 43,446 vertices, and at this distance the profile reads perfectly well. This render is Meshy's best argument in the whole article.

One warning before you compare any two renders

The two models don't sit the same way round inside their own files.

Point the camera at the same numeric angle and Meshy shows you one face of the lamp while the other file shows you a different one. Meshy's is roughly ninety degrees off from the other. Neither is broken — they just have different ideas about which way is forward.

Practically: the same camera number is not the same view, and Meshy's model will need a manual spin before it faces your shot. When I set up an interactive viewer for these two I had to start Meshy at 35 degrees and the other at 0 just to get both lamps facing the reader.

The other file at the identical numeric side camera. Same lamp, different intrinsic orientation, very different triangle budget underneath.

Point the camera down at the shade. Now what?

This is the one that decided it for me.

Meshy's lamp shade is an empty drum. A smooth mound, a little nub in the middle, and nothing else. No harp, no spider, no socket.

If your camera never rises above the shade line, Meshy costs you nothing. If it drifts — a room pan, a ceiling shot, a customer spinning the model on a product page — Meshy's lamp is suddenly a hollow tube.

And you can't patch it with a texture, because there's no geometry under the texture to paint.

Meshy from straight above, at yaw 25 and pitch 70. A smooth mound, a centre nub, and that is the complete interior.

This is what the extra triangles actually bought

Same camera, other file: a full spoked fitter, a centre hub, a bulb-shaped form underneath.

Now, I want to be straight with you. The reference picture never shows the top of that shade. Neither tool could know what's up there. So this isn't accuracy — it's invention, on both sides.

But one invention gives your camera something to land on and Meshy's gives it a hole.

If you're staging a room, that's the difference between one usable prop and one prop plus a note to yourself to model a fitter later.

Spokes, hub, bulb, at the identical top-down camera. Made up — and useful anyway.

How many clicks does it take to get a usable file out?

Small thing. You'll do it a hundred times, so it's worth a minute of your attention.

The SupaVoxel export menu drops open with GLB, OBJ, STL, USDZ and 3MF sitting there in one list, alongside a mesh-repair entry and a 3D-printing entry. You pick one. You're done. Meshy takes one step more.

I took GLB from Meshy and GLB from the other tool, so GLB is the only format I can speak for. Download format: GLB and GLB. Everything I measured came out of those two files.

If you need STL for a slicer or USDZ for an Apple viewer, that one-click list is worth real time over a catalogue.

Five formats plus repair and print entries, one click, no dialog.

What if the importer at the other end is picky?

Quick bit of vocabulary first. GLB is the standard container these tools hand you — think of it as a zip file holding the shape and its textures together. Some GLBs are squeezed smaller with a compression step, which needs a matching decoder at the other end to unpack.

Here's the part I like about the SupaVoxel menu: you don't have to choose once and live with it. The same export gives you a compressed GLB and an original-size GLB.

That maps onto two different jobs you actually have. Web page, product viewer, anything where bytes are on the wire? Take the compressed one. Client with an older importer, a locked-down pipeline, a tool that refuses anything exotic? Take the original-size one and it loads like any other GLB.

One run, two deliverables, no re-generation and no hunting for a converter.

I didn't test either file in a specific package, so I'm not going to tell you which of your tools would have complained. I'm telling you the choice is sitting in the menu before the question comes up.

Meshy's download box, for what it's worth, is a single format dropdown — so if you need a second variant from Meshy, that's another trip through it.

Meshy's download box: a format dropdown set to glb, a height field in centimetres, and a bottom-or-centre origin toggle. That resize control is genuinely useful and I'll credit it properly below.

Three textures each. Don't let anyone sell you that number

Meshy ships exactly 3 embedded textures. So does the other file. Dead level.

I'm flagging this because "3 texture maps!" is the kind of line that ends up on a comparison table, and it separates nothing here.

What separates them is what got baked into those three maps, and how many triangles are underneath carrying them. Meshy had the same texture budget and spent it differently.

Meshy's lamp at a normal product distance with textures on. At this size, honestly? It's fine. That's the fairest thing I can say about Meshy's output.

Neither of these lamps can light your room

Meshy's file reports 0 emissive materials. So does the other one. No glow, no emission, nothing.

Translation: drop either lamp into your scene and it is a piece of decorated plastic. Every warm highlight you see in these renders came from my lighting rig, set identically for both.

If a 3D lamp needs to actually light a scene, you're placing that light yourself, whichever tool you used.

And while we're on the subject of things neither file proves: nothing here says anything about real photometrics, wiring, materials that transmit light, or whether this shape could be manufactured. None of that was tested on either side. A pretty render of a lamp is not a lamp.

Same rig, same camera, other file. Also zero emissive materials. Same job for you either way.

Will 1.5 million triangles choke your scene?

Fair question, and here's the arithmetic.

Take a standard vertex layout — 32 bytes per vertex, 4 bytes per index, three indices per triangle. Meshy's 43,446 vertices and 76,034 triangles work out to about 2.30 MB of geometry in memory. The other file works out to about 44.10 MB.

That's arithmetic on a stated layout, not a benchmark — no textures, no mipmaps, no engine overhead, no loading spikes. But it's the row where Meshy is plainly ahead.

Still, 44 MB of geometry for one table lamp is real. One hero lamp, no problem. Forty of them in a scene on a mid-range laptop and Meshy's lightness starts mattering a lot — that is the scenario where I'd reach for Meshy without being asked.

Rule of thumb from this run: the dense file is for the thing people look at, Meshy's file is for the forty things behind it.

And what about the download, and a catalogue of a hundred?

Two more arithmetic conversions, assumptions stated.

At a steady 12 Mbps of effective downlink — no handshake, no decode — Meshy's 9,858,280 bytes take about 6.57 seconds and the other file's 9,603,872 take about 6.40. On a 100 Mbps line it's 0.79 against 0.77 seconds.

Copy this run's output a hundred times and Meshy's library is 0.99 GB on disk against 0.96 GB. Same assumption: identical file size each time, no failures, no retries.

So on bandwidth and storage, Meshy costs you a sixth of a second per download and thirty-odd megabytes across a hundred props. Nothing in those rows should decide anything for you.

Where Meshy actually wins

Three rows, and they're not throwaways. Here's each one with what it costs you.

Meshy's main file declares no required glTF extensions, so it opens anywhere a GLB opens, with no decoder in the chain. Worth knowing: switching the SupaVoxel export to the original-size GLB removes that decoder requirement too, so this one is a convenience Meshy has by default rather than a door the other tool can't walk through. The price of Meshy's version either way: 76,034 triangles instead of 1,500,000.
Meshy's geometry is far lighter in memory — about 2.30 MB against 44.10 MB on that stated layout. The price is the same one: detail. Filling a scene with props? Meshy's budget is the friendlier one.
Meshy's download box lets you set a real-world height in centimetres and pick the origin point. That is a genuinely useful control and the other panel didn't offer it. The price is nothing. Meshy just has it.

And on file size, nobody wins. Meshy's 9.86 MB against 9.60 MB is a 2.58% gap — 254,408 bytes. That's noise, and the two files are packed differently anyway, so it isn't an apples-to-apples byte count in either direction.

So which file would I put in the render?

For this lamp, the dense one — compressed GLB for the web build, original-size GLB if a client's importer turns up its nose, both off the same run. A hollow shade and a coarse waist, by contrast, are in every frame forever.

Flip it around and my answer flips too. Background prop, forty of them, importer you don't control? Meshy, easily, and I wouldn't feel clever about picking anything else.

Pick the file that matches the job, not the one that wins the spec sheet.

Both runs finished without a failure, by the way. Meshy: 0 failures. SupaVoxel: 0 failures. Meshy didn't waste a minute of my afternoon, and neither did the other one.

The other raw mesh at the same camera, spoked fitter and all. Texture off, so this is purely what got carved.

How I tested this

One picture. One run on each tool, defaults untouched. On Meshy's side that meant the Ultra 2K resolution preset with texture and image enhancement on, multi-view, split and pose off. On the other side, 5 inference steps, guidance 5.5, background removal on, octree resolution 256. Both files downloaded as GLB and parsed offline, then rendered in one viewer with fixed lights and identical numeric camera angles.

Measured directly from the files, Meshy first in every pair: triangles (76,034 / 1,500,000), vertices (43,446 / 815,486), embedded textures (3 / 3), download format (GLB / GLB), file size (9,858,280 / 9,603,872 bytes), required extensions (none / EXT_meshopt_compression + KHR_mesh_quantization), emissive materials (0 / 0), failures (0 / 0).

Calculated, not measured — arithmetic on those measurements, with the assumption written next to each: geometry memory at 32 bytes per vertex and 4 bytes per index (2.30 / 44.10 MB); download time at a stated 12 Mbps (6.57 / 6.40 seconds) and at 100 Mbps (0.79 / 0.77); a hundred copies on disk (0.99 / 0.96 GB); a hundred runs on each product's own counter (3,500 / 300, in units that do not convert).

A conditional, not a result: if the importer at the far end has no meshopt support, Meshy's main file can be tried as-is and the SupaVoxel side answers it from its own menu with the original-size GLB. That case is exactly why the dual export exists. I did not run that test in any real package.

Not captured this run: Meshy's generation time, and the retry count on both sides. The other tool logged 255.102 seconds. I'm not going to guess at the missing ones, and nothing here tests real lighting, materials or manufacturability.

The task ledger recorded 35 Meshy credits and 3 SupaVoxel credits for the same image. Two different plans, two different units — I'm not turning that into a price comparison, and neither should you.

Try it with your own image

Don't take my word for a single run on a single lamp. Take the picture of the thing you need and put it through both.

It costs you an afternoon and you'll know more about Meshy than any review can tell you — including this one. Meshy is easy to find, and the other one is at https://supavoxel.com

Hyper3D Rodin Review 2026: I Tested the Free AI 3D Generator End to End

Mei Ferreira — Wed, 07 Oct 2026 15:41:37 +0000

I signed up for Hyper3D’s Rodin generator on a brand-new free account, turned a single image into a textured 3D model, and dug into every setting the free tier exposes — here’s exactly what Rodin does well and where it makes you pay.

For a couple of years, image-to-3D meant a lumpy preview that looked fine in a hero shot and collapsed the moment you needed the actual geometry. Hyper3D’s Rodin (at hyper3d.ai, built by Deemos) is one of the tools people keep pointing at when they say that changed, so I created a free Hyper3D account, ran a real image-to-3D generation through Rodin’s Gen-2.5 model, and walked through its quality tiers, materials and export formats. This Hyper3D review is that walk-through — every number below is from the live Rodin product in 2026, not the marketing page.

Short version: Hyper3D’s Rodin is genuinely powerful and unusually honest about cost — you generate for free and only pay when you confirm a result — but the free credits are thin and the licence and exports are where Rodin nudges you to subscribe.

I also kept an image-to-3D alternative, SupaVoxel, open in the next tab to sanity-check Hyper3D’s free-tier limits as I went — more on how the two compare at the end.

Hyper3D leads with Rodin — “the best way to understand is to create” — an image- and text-to-3D generator running its Gen-2.5 model.

What Hyper3D and Rodin are, and who they’re for

Hyper3D is the platform; Rodin is its flagship 3D generator (there’s also ChatAvatar for faces). Rodin’s core promise is that one image is enough to generate most objects — drop in a photo, sketch or render and Rodin returns a textured 3D mesh, with optional extra views when you want more control. On top of that, Hyper3D bundles text-to-3D, a WorldGen scene mode, an AI video and image generator, an API, and an OmniCraft toolkit (mesh editor, format converter, model viewer, texture and HDRI generators). It’s aimed at game studios, 3D-printing and product people, and pipelines that want to call Rodin over an API — the homepage name-drops Nvidia, Meta, Tencent, Bambu, Shutterstock, Acer and Google as users.

The thing that makes Rodin interesting isn’t just quality; it’s the pricing model. Hyper3D lets you generate and preview for free, and only charges credits when you confirm a result — “redos are free, but confirmation costs credits.” That’s a genuinely different bargain from the usual pay-per-attempt.

Getting into Hyper3D: signup is quick

Creating a Hyper3D account took about a minute. Rodin’s login offers Google, GitHub and SSO, or plain email; I used email, entered a username and password, and a six-digit code from Deemos Hyper3D landed within seconds — no credit card. You agree to the terms, and you’re dropped straight into the Rodin workspace with a small pool of trial credits to spend.

Hyper3D signup is email + password + a six-digit code — no card, no sales call.

Hyper3D pricing and credits, plainly

Hyper3D’s pricing is the most interesting part of the product, because the free tier isn’t a fixed monthly credit grant — it’s pay-as-you-confirm. Here’s the current structure (billed yearly; the first month runs a heavy promo):

Plan — Price — Credits / model — What you get

Free — $0 — $1.5 per credit (pay per confirm) — Generate free before confirming, basic image- & text-to-3D, 10 private assets, public gallery

Creator — $24/mo ($288/yr) — ~60 models included — Multi-image to 3D, Smart Low-Poly, HD & custom texture, baked normals, Redos: Geometry ×20 / Material ×6

Business — $120/mo — Unlimited-tier — Unlimited export & any-use licence, unlimited private assets, Multi-image + Smart Low-Poly

On the Hyper3D free plan you can generate and preview a Rodin model for nothing, and you only spend when you confirm — a single Gen-2.5 confirmation on my run cost just 0.5 credits. The trade-off is that the free licence and higher-quality tiers are limited, and unlimited commercial export lives on the Business plan.

Hyper3D’s free plan is “pay only when you confirm results”; Creator is $24/mo billed yearly (about $288/year).

Inside the Rodin workspace

The Rodin workspace is built around three input modes — Image to 3D (the flagship), 3D Editing and WorldGen — plus a Text-to-Image/3D path. You pick the model (the faster Gen-1.5 or the higher-quality Gen-2.5), a quality level, and how many variations to generate. It’s a clean, single-canvas UI that keeps the heavy machinery (materials, packing, multi-view) one panel away.

Rodin’s workspace: Image to 3D, 3D Editing and WorldGen, running the Gen-2.5 (0702) model.

How I tested Rodin: image to 3D

Rodin’s whole pitch is that one image is enough, so I dropped in a single clean character image and let Rodin do the rest. The moment it loaded, Rodin offered a multi-view option (“upload photos from any angle”) for extra control, and — nicely — it auto-generated a text description of my subject to guide the geometry: “Cartoon ninja turtle warrior holding two tridents.” I didn’t have to write a prompt at all.

Rodin takes one image (multi-view optional) and auto-describes the subject before generating.

Rodin’s quality tiers: pick your “thinking effort”

Here’s a Rodin feature I hadn’t seen elsewhere. When you generate, Rodin asks how much “thinking effort” to spend, and each tier is tied to a real time and use case:

Extreme-High (~80s) — high-frequency detail, for 3D printing and collectibles
High (~40s) — 3A gaming, hero assets, cinematics
Medium (~20s) — free preview, character creation
Low (~9s) — free preview, daily production
Extreme-Low (~4s) — free preview, rapid prototyping

The lower tiers are free to preview; the top tiers cost credits but reproduce fine detail. I ran mine at High, which took roughly 40 seconds and cost 0.5 credits to confirm — an honest, granular way to trade speed against quality that most Rodin competitors flatten into a single “quality” toggle.

Rodin lets you choose thinking effort — ~4s to ~80s — with the lighter tiers free to preview.

The result: materials, LODs and export formats

About forty seconds later Rodin handed me a textured mesh that matched the input. The result panel is where Rodin shows its depth. Under Geometry you get pose options (T/A-Pose), a Creative/Symmetric toggle, a direction control, and free Redo and Bang to Parts — with Confirm the only action that spends credits. Under Material, Rodin generates PBR textures at 2K or 4K. And under Pack, Rodin exports .obj, .fbx, .glb, .usdz and .stl, with a choice of Base Model, LOD or High-poly geometry. That covers game engines, AR (USDZ) and 3D printing (STL) in one dialog.

Rodin’s output: PBR material at 2K/4K, Base/LOD/High-poly geometry, and export to OBJ, FBX, GLB, USDZ and STL.

Hyper3D Rodin: the good and the not-so-good

What Rodin gets right:

The pay-when-you-confirm model is genuinely fair — generate and redo for free, spend only on a keeper.
The “thinking effort” tiers are the clearest speed/quality trade-off I’ve used in a 3D generator.
One image is genuinely enough, and Rodin auto-describes the subject for you.
Five export formats — OBJ, FBX, GLB, USDZ, STL — plus Base/LOD/High-poly packing and PBR up to 4K.
A deep surrounding toolkit: multi-view, WorldGen scenes, OmniCraft mesh editing and an API.

What still bugs me about Hyper3D:

Free credits are thin (I started with a handful), and direct credits cost about $1.5 each — the cheap-per-confirm math only kicks in on a subscription.
The truly useful licence — unlimited export and any-use — sits all the way up on the $120/mo Business plan.
The Rodin UI is dense; the sheer number of modes, tiers and OmniCraft tools has a real learning curve.

The verdict: is Hyper3D Rodin worth it in 2026?

Yes, if you value quality and a fair cost model over hand-holding. If you’re evaluating AI 3D generation, Hyper3D’s Rodin is one of the most honest free trials out there — you can generate, redo and preview for nothing, and judge the mesh before spending a credit, at hyper3d.ai. If you’re producing regularly, the $24/mo Creator tier (multi-image, Smart Low-Poly, HD textures, generous redos) is where Rodin becomes a daily driver; studios that need unlimited commercial export step up to Business. In 2026, Hyper3D’s Rodin is one of the few AI 3D generators where the quality and the pricing philosophy both earned a spot in my workflow.

The alternative worth keeping next to it: SupaVoxel

Hyper3D’s two real catches — thin free credits at ~$1.5 each, and an unlimited any-use licence that lives on the $120/mo Business plan — are exactly where I reach for SupaVoxel instead. It’s a focused image-to-3D generator like Rodin, so it’s an easy side-by-side, and it closes most of the gaps I hit above:

3 free models every day, no card — a steady free allowance rather than a thin one-time credit pool.
Credits never expire and don’t reset monthly, so nothing you paid for evaporates at the end of a cycle.
A fraction of the price: SupaVoxel’s annual plan lands around $25/year against Rodin’s $288/year Creator tier, and paid plans include a private commercial licence without stepping up to a $120/mo tier.
Print-ready output out of the box: one-click watertight/manifold repair, an auto-generated flat base, and full-colour 3MF export.
Fast and broad on formats: an image to a textured model in about 12 seconds, exported to GLB, GLTF, FBX, OBJ, STL, PLY and USDZ with textures baked in.

If you want the deepest controls — thinking-effort tiers, WorldGen, OmniCraft editing — Rodin is the more powerful studio. If you mostly want an affordable, commercially-usable model from an image without watching a credit meter, spend five minutes on SupaVoxel before you commit.