If you came looking for hi3d, this independent Hyper3D Rodin review shows where a free-account preview stopped short of a download. It also compares the observed textured-file routes through Hyper3D Gen-1.5 and SupaVoxel, while flagging a cost the test could not isolate.
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 skeleton picture and a modest trial balance. The job was not to make the prettiest screenshot; it was to leave with a textured file a sculptor could open. I chose the newer-looking Hyper3D route, waited for the preview, confirmed the shape, picked GLB—and only then found out the free account could not download it. The account had already spent a credit fraction.
I repeated the same image on Hyper3D Gen-1.5 and ran it once through SupaVoxel. I kept the different ledgers separate. The surprisingly useful question became: which charge is attached to a file, and which charge buys only a look at one?
My verdict in 60 seconds — Hyper3D's Gen-2.5 free-account preview was a 0.5-credit detour, while Gen-1.5 did deliver a textured file; SupaVoxel delivered one in its measured 3-credit transaction. The complete Hyper3D Gen-1.5 PBR cost is unknown in this case, because Material Generate was not isolated. That prevents a credible cost winner, not a clear access recommendation: use SupaVoxel when you need a directly observed textured GLB and a legible segmented sculpt from this workflow; use Gen-1.5 if a free-account, lighter PBR export matters more and you can reconcile its material stage. Neither is a tested moving print.
Eight paired, evidence-led judgments for this one account and image, not numerical ratings; the proprietary credits cannot be converted into one another:
- First route — Hyper3D Gen-2.5: preview and 0.5 verified credit, but no free Download · SupaVoxel: one completed transaction and an exported GLB.
- Alternative route — Hyper3D Gen-1.5: a separate 0.5 geometry-confirm debit and an actual PBR export · SupaVoxel: one matched 3-credit debit tied to its actual export.
- Material debit — Hyper3D: Generate not isolated; Confirm stayed 2.5 → 2.5 · SupaVoxel: 3 credits tied to the completed request. No complete cross-service cost comparison.
- First available file — Hyper3D: 4.41 MB geometry-only GLB with zero textures · SupaVoxel: 35.28 MB tested Original size GLB containing three 2K maps.
- Finished textured file — Hyper3D: 13.27 MB PBR member inside a 21.05 MB browser ZIP · SupaVoxel: 35.28 MB direct UI GLB. Compare both textured files, not the bare geometry file.
- Complete workflow timing — Hyper3D: not recorded · SupaVoxel: not recorded. The observed 42.8-second partial phases and 124-second request lifecycle have different boundaries.
- Export formats observed — Hyper3D Gen-1.5: GLB, OBJ, FBX, USDZ, STL in the menu · SupaVoxel: GLB, OBJ, STL, USDZ, 3MF. Only each selected GLB was tested.
- Useful model for this brief — Hyper3D: cleaner closed static shell · SupaVoxel: more legible sculpted joint zones, but 321 nonmanifold edges. The missing repair work affects any all-in quote.
I started with the free-account interface. Its visible allowance is not a contract for unlimited future downloads or a price in dollars.
What did the first half-credit actually buy?
On Gen-2.5, the skeleton preview completed and the account's measured debit for this attempt was 0.5 Hyper3D credit. The generation phase recorded 48.1 seconds, then geometry confirmation 17.7 seconds. An information panel reported one million faces and 575,833 vertices and displayed Watertight and Print-Ready labels. I could inspect the screen but not the file.
Gen-2.5 produced an interface preview. The million-face figure was a panel claim, not an offline file count.
When did the download restriction appear?
Not at the point where I could still change course for free. I selected GLB in the Pack area and pressed Download; Hyper3D then displayed a subscription requirement for Gen-2.5 and noted that Gen-1.5 downloads stayed free. We did not obtain Gen-2.5's file through that account flow, and I have not smuggled any preview-only figure into the comparisons below.
If you have a five-credit starting allowance, a half-credit spent on a file you cannot take home is 10% of that assumed allowance. That is arithmetic on a described initial budget, not a claim about renewal or a paid subscription. The unpleasant part is the sequence: preview first, export decision after the resource was consumed. Somebody screening six concepts should establish export entitlement before they plan their six deliverables around previews.
The actual Download attempt surfaced the gate. The 0.5-credit debit cannot be converted into a Gen-2.5 GLB for this free account.
Was Gen-1.5 the same job with a different switch?
No. I uploaded the same picture again and started a new Gen-1.5 job. Hyper3D's automatic descriptions were not identical between the two versions, so it would be reckless to call this a controlled A/B test of model architecture. What is controlled is the input file. What matters for the buyer is the new outcome: Gen-1.5 permitted an export after geometry confirmation.
Its measured server-side generation phase was 27.5 seconds, then geometry confirmation 15.3. The independently attributable geometry debit was another 0.5 Hyper3D credit. Across my two Hyper3D attempts I spent 1.0 verified credit on geometry-related stages, and only the second route yielded a file. That's the real learning cost of my sequence, not a one-credit tariff for every subsequent Gen-1.5 skeleton.
The same input entered an independent Gen-1.5 attempt; it did not unlock the earlier Gen-2.5 preview.
Why isn't 42.8 seconds an end-to-end winner?
Add the two measured Gen-1.5 server phases: 27.5 + 15.3 = 42.8 seconds. That sum excludes image upload, navigation between steps, the material-generation interval, packaging, downloading and unpacking. SupaVoxel's 124 seconds is a different clock: the interval from request creation to request update, including queue time but not upload before submission or export afterward.
Put 42.8 next to 124 and you can make a dishonest speed headline in four words. Don't. I cannot say which service put a textured GLB in my hand sooner because neither complete upload-to-file interval was captured with the same boundaries. At most, these are two stage-specific observations from a single attempt each. The second-order consequence is a scheduling problem: if a client needs 100 files by Friday, 42.8 × 100 = 1.19 hours of known Hyper3D phases only, omitting material and operator work. It is not a production throughput forecast.
This confirmation is part of the 42.8-second partial compute sum. The later material workflow was not fully timed.
Was the first GLB already the textured deliverable?
It was a real, free-account Gen-1.5 export, but not the right comparison asset. The first geometry GLB measured 4,405,568 bytes and had zero embedded texture images. It would be absurd to line that bare figure up against a textured SupaVoxel GLB and announce a file-size or visual winner. I went through the separate Material Generate and Material Confirm path to get Hyper3D's PBR result with three 2048 × 2048 PNG maps.
The first GLB was a 4.41 MB untextured mesh. Its byte count is not substituted for the later PBR asset.
Which line is missing from Hyper3D's material ledger?
The Material Generate step happened, and later I found its generated preview waiting for confirmation. But I did not capture an isolated before-and-after balance specifically for this Material Generate. A balance observed much later on a shared account is not an invoice for this skeleton. An observation that Generate cost nothing on a different asset cannot be borrowed to fill this blank.
What I did isolate was Material Confirm: the balance was 2.5 credits before and 2.5 after. That step added zero in the observed window. It does not make the earlier Generate stage free. The full Gen-1.5 PBR cost is therefore unknown; the measured 0.5 is its geometry-confirm charge, not its proven complete-file price. This is a material limit to any financial recommendation, not a fussy accounting footnote.
The material step existed; its case-specific debit was not isolated, so the finished PBR price stays blank.
Material Confirm's 2.5 → 2.5 check applies to Confirm alone, not retroactively to Generate.
Did Hyper3D finally hand over a file?
Yes, and more than one inside the same download. The tested Pack button delivered a 21,048,356-byte ZIP containing a 13,269,360-byte PBR GLB and a 7,778,744-byte Shaded GLB. The PBR member is what I opened for the image and mesh tests. The browser did not transfer only 13.27 MB. It transferred 21.05 MB, after which I extracted the file I wanted.
The PBR file exists inside the real ZIP. That proves access, not a complete material-stage price.
How does the SupaVoxel ledger differ?
On the SupaVoxel side, the interface showed a 3-credit charge before this generation; one matched transaction for this specific skeleton recorded −3 SupaVoxel credits. We matched the source image and request, rather than subtracting two overall account balances while several projects were using that account. The UI's Original size GLB downloaded with three 2K PNG maps and measured 35,283,096 bytes. Its Compressed option was visible but not size-tested.
Do not write "0.5 versus 3, therefore six times the cost." One number is an incomplete Hyper3D geometry stage; the other is a complete SupaVoxel transaction. They also live on unrelated credit schedules. Even if the Hyper3D material debit were known, we would still need comparable paid dollar rates and entitlement terms before ranking actual prices. What I can honestly prefer here is cost traceability for this one finished file: SupaVoxel has an attributable completed-run transaction, whereas my Hyper3D PBR stage ledger is missing an entry.
The SupaVoxel submission showed its 3-credit charge; the case-linked transaction, not a busy account's aggregate balance, verifies it.
What would a hundred skeletons do to the spreadsheet?
Suppose every future run matched this one and nothing failed. 100 Hyper3D Gen-1.5 geometry confirms × 0.5 = 50 Hyper3D credits for geometry alone. The material-stage cost of 100 completed PBR files stays unknown, just as the cost of one stays unknown. Under an assumed five-credit initial allowance and no other debits, at most 10 geometry confirmations fit that starting budget—not 10 proven finished textured files and not evidence of replenishment.
The corresponding multiplication on SupaVoxel is 100 × 3 = 300 of its own credits for hypothetical completed transactions. This is not a 50-to-300 exchange rate. We did not actually run a batch or establish plan prices, free-account replenishment, commercial licensing, failure rates or throughput. A production quote cannot be built out of these two unlike units. For a buyer, the immediate next step is to close the material debit and entitlement questions, not to pick the numerically smaller credit number.
Original size was the tested SupaVoxel branch. Do not quietly attribute an unmeasured compressed size to this exported file.
Where does Hyper3D beat the alternative?
For a closed, single-piece ornament, the downloadable Hyper3D Gen-1.5 mesh is watertight after UV-seam welding, with zero nonmanifold edges. SupaVoxel's sculpt is visually better segmented but has 321 nonmanifold edges and is not watertight. That difference means real additional inspection and repair before any printing claim on SupaVoxel's side. Hyper3D's file is also smaller under the tested export selection. Those are strong, specific reasons to choose Hyper3D despite the blocked Gen-2.5 detour.
Hyper3D's compact, closed model is a legitimate static sculpt; a dark line is not a pivot.
SupaVoxel communicates the intended separate bones more clearly. Its mesh-health defect is real and disclosed, not waived by the render.
Final verdict: what would I buy for this particular job?
I would not spend another Hyper3D Gen-2.5 trial credit expecting a free downloadable file under the tested access path. I would use Gen-1.5 if a free-account PBR file for a static skeleton was the brief, while separately verifying Material Generate's missing debit. For an image-led segmented design reference with an attributable completed-run charge, I would begin with SupaVoxel and make repair and clearance testing explicit deliverables. No shared dollar winner, no speed winner, and no proven moving toy emerge from this run.
Use SupaVoxel when the handoff is a sculpt, not a promise
If you need a file you can actually inspect for the shape of elbows and knees, start a SupaVoxel image-to-3D run on your rights-cleared reference. The 3-credit transaction attached to this exact completed output is known. Its Original size GLB is 35.28 MB and its 321 nonmanifold edges need repair before fabrication. If a watertight static file or the smallest tested export is your actual deliverable, Hyper3D Gen-1.5 earned that job instead.
How I tested this—and what the invoice cannot say
One independently generated image was uploaded for one Hyper3D Gen-2.5 attempt, a separate Gen-1.5 attempt and one SupaVoxel run. The blocked Gen-2.5 file was never obtained; its million-face figure came only from the interface. Gen-1.5's geometry-only GLB and later ZIP/PBR member were inspected separately. SupaVoxel's case-specific debit came from a matched transaction; its 124-second request lifecycle and Hyper3D's 42.8-second partial phase sum do not share endpoints. I did not verify either vendor's published paid price, subscription renewal, customer-visible charge timing, full time-to-file or commercial licensing.
All MB and GB here are decimal; 12 Mbps transfer floors assume steady throughput and omit overhead. The hundred-unit exercise repeats this one observation by multiplication; no hundred-unit batch ran. The source image was independently generated using visual reference material whose publication rights remain unverified. These drafts are not authorization to publish it.
Originally published on Medium: Hyper3D Rodin Review 2026: 0.5 Credit Spent Before the Download Gate.