Glb Viewer: Hyper3D 3D Hand Review and ZIP Download

If you are choosing a 3D hand asset for a glb viewer, this review compares Hyper3D and SupaVoxel exports on visible detail, topology, and file size. It also separates Hyper3D’s ZIP download from the GLB a site would host.

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 was trying to put a hand-and-rock sculpture in an interactive product concept. I needed the fingers to look convincing up close and a file I could actually hand to a viewer developer. Two numbers on my drive almost made me tell the wrong story: 20.39 MB and 13.10 MB. They both came from Hyper3D, but they do not describe the same thing.

The site sent me a 20,394,412-byte ZIP containing a shaded GLB and a textured PBR GLB. Only the PBR member, at 13,098,572 bytes, is the single asset I would hypothetically host. SupaVoxel sent me one tested 31,770,112-byte Original-size GLB. Compare ZIP to GLB if you mean what the websites transferred; compare PBR GLB to GLB if you mean files you put on a site. Do not quietly replace one with the other to win a bandwidth argument.

My 60-second verdict — SupaVoxel keeps more hand-and-rock relief for a close-up viewer; Hyper3D wins the tested payload and welded-solid trade. I would choose SupaVoxel when fingers and rock relief are the point of the viewer: its 952,876-triangle export retains more local form than Hyper3D’s downloadable 120,000-triangle file. Hyper3D wins on measured transfer bytes and welded solid topology. SupaVoxel’s 213 nonmanifold edges rule out calling it ready to print; no actual controller fit was checked on either.

Eight-line paired decision card — each row records the observation and the practical consequence:

Palm and rock relief at close range — Hyper3D smoother, SupaVoxel more articulated — I would spend the heavier download where viewers actually zoom.
Complete model triangles — 120,000 vs 952,876 — the extra geometry gives an editor more sampled form, not a guarantee of better anatomy.
Actual browser transfer — 20.39 MB ZIP vs 31.77 MB GLB — budget the package users really obtain from each UI.
Individual textured model for hosting — 13.10 vs 31.77 MB GLB — the smaller standalone tested model costs less model-only egress.
Map resolution and count — three 204⁸² PNG maps on each side — tied on count; do not call this an accuracy test.
Non-base-color map bytes — 6,124,811 vs 2,185,016 — SupaVoxel’s normal/metallic pair is lighter despite its larger overall file.
Unrepaired print-solid check — Hyper3D passed after seam welding; SupaVoxel 213 nonmanifold edges — a beautiful viewer asset may still require repair.
Unseen back and actual controller fit — no reference back or physical fit test · Hyper3D unscored · SupaVoxel unscored — pixels cannot establish the rear anatomy or load-bearing function.

These rows are not summed: for a close-up digital viewer, I weight the visible hand more than print topology.

What is the picture actually asking the model to make?

The common 1,572,056-byte image depicts a raised-finger hand, a splayed thumb and a wrist emerging through angular rock. It does not provide the back of the hand, a measured gap for a controller, or a CAD sketch. I supplied the same checked source file to the two tools, but neither company’s private preprocessing was measured. The source image was independently generated with a visual reference in its history; that is not publication-rights clearance for the reference. This review is about the observable exports, not a permission to publish the source or to sell a functional device holder. Keeping that scope in view stops a convincing dark-rock render from becoming a fictitious engineering drawing.

One checked input shows the pose and rocky base, not measured cradle clearance; image-rights review remains open.

Which Hyper3D file is even in this comparison?

Gen-1.5. A separate Gen-2.5 Hyper3D preview ended at a Free-account GLB Download subscription gate, leaving no model to measure. The later Gen-1.5 attempt produced a gray geometry-only file, then a textured PBR ZIP after Material Generate and Confirm. Comparing that inaccessible Gen-2.5 preview with SupaVoxel’s real GLB would grade an imagined file against one on my drive.

Hyper3D’s Gen-2.5 Free-account Download gate: preview visible, inspected GLB unavailable.

What exactly did Hyper3D send down the wire?

Hyper3D sent a 20,394,412-byte ZIP containing a 13,098,572-byte textured PBR GLB plus a shaded model. Its earlier 4,392,672-byte gray GLB had no textures and cannot stand in for the PBR asset. SupaVoxel’s chosen Export → GLB → Original size branch sent an actual 31,770,112-byte textured GLB; its optional Compressed branch was not measured. A developer would extract and host Hyper3D’s PBR member, but a human downloading through its UI first transfers the whole ZIP. Two audiences, two honest denominators.

Hyper3D’s web Download delivered two GLBs in one 20.39 MB ZIP; the 13.10 MB PBR is one extracted member.

SupaVoxel offered Original size and Compressed; only the 31.77 MB Original size branch has a tested payload.

If visitors load a single model, how long is the transfer?

Under an ideal constant 12 Mbps connection, no handshake, cache, decoding or render delay, the separately hosted 13.10 MB Hyper3D PBR file implies 8.73 seconds of payload transfer; the tested 31.77 MB SupaVoxel GLB implies 21.18 seconds. On an ideal 100 Mbps link they imply 1.05 and 2.54 seconds. Those are bytes × 8 ÷ bandwidth, not measured first-frame times. If you are downloading the model from Hyper3D’s website, use its 20.39 MB ZIP: ideal 13.60 seconds at 12 Mbps, not 8.73. SupaVoxel’s selected UI file remains 21.18. The consequence is a real planning choice: for a mobile-first viewer, I might simplify or offer a click-to-load instead of automatically making every visitor download the denser sculpture.

The hosted-GLB calculation uses this extracted PBR member, not Hyper3D’s whole ZIP.

The chosen SupaVoxel Original-size GLB is heavier but gives a denser digital sculptural surface in this run.

Does more file buy more of the hand?

In this pair it does. Hyper3D Gen-1.5 has 120,000 triangles and 92,233 vertices; SupaVoxel has 952,876 and 490,760. Looking at the paired front and untextured renders, I see more palm creases and broken-rock relief on SupaVoxel, while Hyper3D retains the broad pose with smoother forms. I cannot prove every extra triangle was well placed from a global count, but I can point to local differences in the exported views. The yaw-calibrated views are not pixel-perfect overlays because the model files have different native orientations. If all I need is a small thumbnail, the Hyper3D model may already be enough. If the hand rotates in a hero viewer, the additional shapes become worth a serious look.

The downloadable Hyper3D Gen-1.5 front carries the main gesture with comparatively smoothed small forms.

SupaVoxel’s front preserves visibly more finger and rock relief, not demonstrated controller clearance.

Are those megabytes all geometry?

No. Each tested PBR GLB embeds three 2048 × 2048 PNGs for base color, normal and metallic-roughness. Hyper3D’s base color is 2,580,567 bytes and SupaVoxel’s 2,444,467. The two other maps together are 6,124,811 and 2,185,016 bytes, respectively. SupaVoxel’s non-color images are substantially lighter in bytes even while its complete GLB is much heavier. That does not make its material more accurate; a PNG’s size depends on image content, not just pixel dimensions. The 109.15 versus 33.34 full-file bytes per triangle include maps, not pure mesh encoding. SupaVoxel’s heavier file does not have more texture files.

Hyper3D’s completed material step yielded three 2K maps; these bytes belong to the PBR asset.

What happens to the picture when I turn paint off?

The raised fingers and surrounding rock still exist in both gray meshes. SupaVoxel keeps extra carved variation across small rock faces; Hyper3D’s surface reads cleaner and more regular. That is relevant to a product illustrator who may change lights: a normal map can create a highlight but cannot create a new silhouette where there is no mesh. A monochrome physical print will not carry the PBR colors, normal map or metallic-roughness image onto the object, so the 8.71 MB of Hyper3D maps and 4.63 MB of SupaVoxel maps serve a digital viewer, not a plain resin print. I am not calling those maps waste for a digital viewer; they are part of why the lit asset looks finished.

The untextured Hyper3D mesh shows the pose without its three PBR maps.

The untextured SupaVoxel mesh makes the denser sculptural relief apparent without claiming print readiness.

What about the side nobody photographed?

The picture shows a palm, not a rear reference. Hyper3D inferred smooth dorsal ridges; SupaVoxel added groove and nail-like detail. I prefer the latter in a rotating viewer, but both are guesses, not a reconstruction verified against an unseen original. If the back matters, supply a second image. Extra triangles can beautifully preserve an invented detail without making it correct.

Hyper3D’s inferred rear: smoother ridges, no supplied rear photograph for checking.

SupaVoxel’s inferred grooves and nails help the orbit view but cannot be graded as anatomical truth.

How expensive is the denser model to hold and serve?

At 32 bytes per vertex plus three 4-byte indices per triangle, geometry buffers estimate 4.39 MB for Hyper3D versus 27.14 MB for SupaVoxel, excluding textures and rendering overhead. This is not measured VRAM. At 10,000 full uncached hosted-model loads and a hypothetical $0.085/GB, model-only egress estimates $11.13 versus $27.00. The $15.87 difference is arithmetic, not an invoice; caching or a tested Compressed export could change it. An icon does not warrant the heavier file; a hero orbit might.

Where Hyper3D beats my preferred visual file

It gives me a smaller tested individual PBR and a cleaner welded solid. Its 120,000-triangle file is one watertight face-connected shell after seam welding, with zero boundary and nonmanifold edges. SupaVoxel has 213 nonmanifold edges and 143 face-connected regions despite zero boundary edges. That prevents a validated volume or print-cost comparison on SupaVoxel. The exchange rate is measurable: Hyper3D’s extracted hosted PBR is 18.67 MB smaller, with roughly an eighth the triangle count, and its ZIP is 11.38 MB smaller than the selected SupaVoxel UI transfer. I get bandwidth and an unrepaired solid candidate; I give up the richer close-up that made me prefer SupaVoxel for digital art. Neither file has been tested under a controller’s weight.

Which version goes on my concept page?

I would try SupaVoxel for the hero sculpture and measure the actual viewer on target phones before shipping its 31.77 MB Original-size GLB. If that cost dominates and the simpler palm still sells the concept, I would choose the extracted Hyper3D Gen-1.5 PBR instead. I would not swap in the 4.39 MB untextured geometry-only file and still call it an equivalent PBR comparison. Nor would I call the SupaVoxel sculpt a printable stand until its defects are repaired and a real controller has been fitted. A good digital model can be an excellent first deliverable without masquerading as a proven physical product.

Put your own close-up against the byte budget

Open SupaVoxel’s image-to-3D tool with your actual object, export a file and zoom where a viewer would zoom. Then write down three different numbers before choosing a delivery route: bytes the creation site transferred, bytes in the individual textured asset, and bytes a visitor will really fetch after whatever optimization you perform. For this hand, those first two numbers were different on Hyper3D by 7,295,840 bytes. If you care about a manufactured stand rather than a viewer, stop measuring file size as the deciding factor and start measuring the real controller, the mesh and the prototype.

How I measured it, and what I did not measure

One 1,572,056-byte source supplied to both, with a matching SupaVoxel saved-input fingerprint; internal preprocessing not measured. Actual Hyper3D Gen-1.5 Download yielded a 20,394,412-byte ZIP, whose PBR member was compared with an actual 31,770,112-byte SupaVoxel Original-size browser GLB. Gen-2.5’s blocked Download produced no file. Both PBRs embed three 2K PNGs. Paired renders use the same offline viewer, lighting, pitch and scale; Hyper3D uses yaw 0° and SupaVoxel yaw 90° to align the subject, despite different native orientations. Transfer time is arithmetic at fixed 12 or 100 Mbps; CDN math assumes 10,000 uncached full loads at $0.085/GB; geometry buffers assume 32 bytes per vertex and 4 per index, not measured VRAM. No SupaVoxel Compressed export, real network timing, albedo accuracy, slicer, print, fit test or image-rights clearance. The verdict expresses only this digital-visual preference.

Also in this series
Hyper3D Hand Stand Review 2026: A Watertight Mesh Isn’t a Fit Test
Hyper3D Rodin Review 2026: 0.5 Credit Spent, Gen-2.5 File Blocked

Originally published on Medium: Hyper3D 3D Hand Review 2026: The 20.39 MB Download Is a ZIP.