DEV Community: Greta Holt

Higgsfield AI Image Review 2026: Four Tokyo Posters and a Watermark

Greta Holt — Mon, 19 Oct 2026 15:49:52 +0000

Four Tokyo paper-cut images from the same displayed model are a close call on visual content. The differences a reader can verify are the originals' watermark, file format, poster composition, credit debits and incomplete timing record.

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

My verdict in 60 seconds

Higgsfield and Kyncept each completed two Nano Banana Pro image jobs from the same adapted Tokyo prompt with 16:9 selected in the interface. All four files measure 1376×768 pixels. At this sample size, a reasonable subjective judgment is a content-quality tie, not a claim that the outputs are pixel-identical or that either service is generally better. Higgsfield's raw PNGs both carry a baked-in “HIGGSFIELD AI” mark at the lower right; the two inspected Kyncept JPEGs have no visible brand mark. Higgsfield took two of its own credits per image, Kyncept one of its own. The timing evidence is too incomplete to award either side a general speed victory.

Shared test — two outputs per product, same text prompt and displayed Nano Banana Pro label.
Canvas — all four 1376×768, despite a 16:9 UI selection; the file-pixel ratio is approximately 1.7917.
Content — each set shows Tokyo Tower, Skytree, red sun, bridge, pagoda, small boat and “TOKYO,” with distinct layouts.
Packaging — Higgsfield writes PNG RGBA with a visible baked brand mark; Kyncept writes JPEG RGB without a visible brand mark in the two originals inspected.
Timing — one Higgsfield UI interval and one Kyncept UI interval are exact; the other two are missing or bounded rather than comparable point values.

Every original is linked from the Tokyo evidence report, not replaced by a polished mock-up.

Higgsfield image 1 in its result preview; follow the report link for the untouched 1376×768 PNG and its brand mark.

What a four-image test cannot establish

This is a hands-on comparison of two third-party tools. Kyncept and Higgsfield are the two products in this trial. The original files, redacted workflow screenshots and raw numbers are available for inspection. This is two runs on each side for one prompt, not a blind panel, a multi-prompt study or a broad performance estimate for either service.

The paper-Tokyo idea was inspired by social-media examples, but the wording submitted here was an original adaptation, not a verbatim viral prompt. Both product interfaces received the same text. I compared what the UI and the downloadable files showed, without inferring an underlying provider or claiming a contractual right to watermark-free or commercial exports on untested subscription tiers.

The prompt was more specific than “make Tokyo art”

It requested a landscape travel poster on matte cream cardstock, Tokyo Tower left of center, a slender silver Skytree to the right and a five-tier pagoda behind a small bridge. The red circular sun, a thin blue river, one tiny boat, paper fibers, visibly layered cut edges and only “TOKYO” printed along the bottom gave the images concrete details to inspect. The UI selection was 16:9 in both products. That aligns the tested request, but it does not guarantee identical random seeds, rendering choices, file encoding or literal compliance with every adjective.

The four originals include the major landmarks and paper-layer theme. They differ most obviously in how they interpret poster: Higgsfield image 1 and Kyncept image 1 show a physical, tilted cardstock piece in the scene; Higgsfield image 2 puts a portrait-oriented poster object inside a landscape canvas; Kyncept image 2 presents a wider, flatter composition. Those observations say more than a declaration that all four are simply “the same image.”

Kyncept image 1 also favors a tilted physical paper-piece interpretation, a useful comparison with Higgsfield image 1.

Pair one: two tilted paper objects, not a clear artistic winner

The first Higgsfield original contains a dimensional cream frame on a dark field. Tokyo Tower dominates the left, Skytree rises at right, and a small paper boat sits on the blue river below a muted red sun. The bottom border reads TOKYO. Its lower-right corner also reads HIGGSFIELD AI: that is not a label we added in a screenshot. The lettering is present in the downloaded PNG.

Kyncept's first original shows another angled layered card. Its landmarks, bridge and paper boat are recognizable, and “TOKYO” runs across the bottom. It has a different crop and spacing from the first Higgsfield image; neither is a reference copy of the other. Whether a client prefers the darker gallery-like scene or the lighter tabletop feel is a subjective decision. On this first pair, the defensible statement is that both make coherent paper-cut Tokyo imagery and one carries an additional brand mark in the raw file.

Higgsfield's first completed image card, distinct from the untouched PNG used for the watermark observation.

Kyncept's first completed image card. The file itself, not this card, is the basis of the format and watermark check.

Pair two: the canvas is landscape, but the poster can be portrait

Higgsfield image 2 presents a portrait-style cream poster sitting in the middle of a broad landscape background. Tokyo Tower is left of center within the poster, Skytree is right, and “TOKYO” sits on its lower edge. The actual PNG canvas is still 1376×768. Saying the file was exported in portrait orientation would confuse the geometry of an object inside the picture with the geometry of the file.

Kyncept image 2 spreads the landmarks across a wider landscape composition, with a pagoda and small bridge above the river and “TOKYO” centered below. It more literally reads as a horizontal poster to us, but one more literal reading of landscape does not establish a general image-quality winner. The other three outputs also differ in style and framing. Anyone with a strict art direction should review both full-resolution originals rather than decide from a thumbnail.

Higgsfield image 2: a portrait-oriented poster object inside the landscape 1376×768 original. The raw-file watermark remains visible at right.

Kyncept image 2: a broader treatment of the same written brief, without a visible brand mark in the inspected original.

Why 1376×768 is not mathematically exact 16:9

A true 16:9 ratio is about 1.7778, while 1376 ÷ 768 ≈ 1.7917. All four sources share that slight deviation even though both UIs displayed 16:9. That is a file fact, not evidence that one product alone ignored a ratio request. The difference is roughly 0.8% of the nominal width-to-height ratio, and a 1376-pixel-wide file would need a height of 774 pixels for exact 16:9. These figures are simple geometry, not an aesthetic rating or an assertion about unseen export settings.

At 300 pixels per inch, the shared 1376×768 source represents roughly 4.59×2.56 inches without upscaling. That calculation does not establish print suitability for a larger physical poster. Both sides have the same pixel count; composition is the meaningful difference here.

Higgsfield's image settings display Nano Banana Pro and the selected landscape ratio.

Kyncept's matching model label and 16:9 selection. Neither screen guarantees an exact mathematical file ratio.

A watermark seen in an original is different from a page overlay

Both downloaded Higgsfield PNGs include the HIGGSFIELD AI mark in their lower-right pixels. A screenshot of a website might contain logos imposed by its preview UI; checking the raw file removes that particular ambiguity. Neither of the two inspected Kyncept JPEGs shows a comparable brand mark. The claim is deliberately bounded to these four originals and the respective accounts/settings used for the case. We did not buy or validate a paid watermark-removal benefit, and we cannot tell a reader that every future generation or paid tier will behave the same way.

The prompt said “print only TOKYO along the bottom,” so the extra Higgsfield mark matters when the file itself is the deliverable. It does not mean that the illustrated landmarks, paper fibers or text rendering are bad. Separating content fidelity from export packaging allows a fairer quality tie alongside an unambiguous watermark difference.

The second Higgsfield request used the same model and artwork prompt; the second raw PNG also retains the brand mark.

The second Kyncept request used the same written prompt, producing a different layout from the first run.

PNG versus JPEG: do not grade quality by byte count

Higgsfield's two originals are PNG RGBA at 1,645,817 and 1,336,001 bytes. Kyncept's are JPEG RGB at 697,068 and 688,508 bytes. The PNGs are larger, but lossless-style packaging and compressed JPEG packaging carry different overhead and encoding decisions. We did not run a calibrated perceptual quality study or export both versions into the same codec, so “half the bytes means twice the quality” would be a non sequitur.

For a purely illustrative 12 Mbps transfer with no handshake, overhead or local write time, the raw file sizes imply about 1.097 and 0.891 seconds for the two Higgsfield files, versus 0.465 and 0.459 seconds for Kyncept's. Those seconds are a formula on file size, not measured download timings, and file size is not a stand-in for detail. The report's derived data records the assumption so it is easy to change.

Credits show local debits, not cross-platform dollars

Higgsfield's image balance ran 6→4→2, two Higgsfield credits per completed image. Kyncept's ran 313→312→311, one Kyncept credit per image. These are direct before/after observations. On the separately documented public $59/1,200-credit monthly bundles, proportional full-use allocation would be about $0.09833 for a Higgsfield image and $0.04917 for a Kyncept image. That is not a claim that the trial incurred either dollar charge or that credits have a universal exchange rate. The pricing article lays out the assumptions, including what happens when credits go unused.

An editor requiring an unaltered file without a visible brand mark would need to account for what the two Higgsfield originals contain. That is a batch-specific observation, not advice to remove a watermark.

An exact UI timer cannot be manufactured from another clock

For Higgsfield image 1, the first client network response marked completed at +31.698 seconds after Generate. Its exact UI-completed second was not captured. A later read-only screenshot proves completion but does not fill the gap. Higgsfield image 2's UI card showed completion at +41.338 seconds; its fully drawn pixels appeared shortly afterward. The 41.338-second datum is the card status, not the instant the last pixel became visible.

For Kyncept image 1, the UI showed completion at +53.073 seconds. Kyncept image 2 was still generating at +295.8 seconds, and a subsequent read showed it done no later than +369.4 seconds. Its precise completion moment lies in (295.8, 369.4] seconds, not at either endpoint by fiat. Converting Higgsfield's first network result to UI time, or replacing the Kyncept interval with a guessed midpoint, would create false precision and a false speed ranking.

The second Kyncept image is still shown as generating; the interval bound comes from the timed watcher, not from a clock printed in this screenshot.

A later read finds the second Kyncept image completed, without establishing its exact completion second.

What these four outputs can and cannot decide

Matching model labels, text and file dimensions make this a useful single-prompt illustration. It does not control random seeds, server load, entitlements or output codecs. Neither the slow, interval-bounded Kyncept run nor Higgsfield's network completion defines typical UI speed; commercial-license terms were not tested.

Both sides drew recognizable Tokyo paper layers. Kyncept image 2 uses the landscape area more directly; Higgsfield's two originals carry a brand mark; formats and byte sizes differ. Open the four raw assets to check those facts or disagree with the subjective tie.

Final verdict: a visual tie with an export caveat

On visual content from two Nano Banana Pro images per side, calling a universal image-quality winner would be stronger than the evidence. In this batch, both products delivered serviceable paper Tokyo scenes; the watermarked Higgsfield PNGs and the clean-looking Kyncept JPEGs differ in a directly inspectable way. One Higgsfield UI time is missing, and the second Kyncept UI time is interval-censored, so this article does not convert a messy stopwatch into a speed claim. That subjective tie coexists with differences in composition and packaging.

Which one I would use for this job

For a layout-sensitive poster brief, I would compare the actual four files, not only the platforms' promotional thumbnails. If an untouched file with no visible brand mark is a hard requirement, the two Kyncept originals in this case meet that observation; the two Higgsfield originals do not. Kyncept's site provides the product entry point, while the report preserves the source files. Paid-plan rights, future watermark behavior and reliable speed remain questions for separate checks, not promises inferred from these four images.

Tripo AI 3D Generator Review 2026: The Black Robe Ships Brown

Greta Holt — Sat, 17 Oct 2026 15:44:15 +0000

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

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

The input was one image of a chibi hooded grim reaper in a black robe, holding a white coffee mug. Tripo's export comes back with the back of that robe rendered in brown leather grain, a colour that is nowhere in the input image — Tripo baked a lighting pass into the baseColor map. SupaVoxel kept the same surface near-black from hood to hem. Tripo and SupaVoxel both invented the back side, because the camera never saw it, and both invented almost exactly the same structure; only one of them also invented the colour. The other half of this article is what that fidelity weighs on the wire: 66.67 MB against 5.92 MB, and 44.4 s against 3.9 s to load on 4G.

Here is the scorecard for this one job — does the model look like the image, and what does it cost to move.

Colour fidelity on the black robe — Tripo 3/10 (back and lower skirt drift to brown-grey) · SupaVoxel 9/10 (one consistent near-black)
Invented back structure — Tripo 8/10 (pointed hood, shoulder cape, fan skirt) · SupaVoxel 8/10 (the same three, near-identical) — a genuine tie
Colour bleed at the black/bone boundary — Tripo 9/10 (none) · SupaVoxel 9/10 (none) — both held the line at the hood opening
Surface believability — Tripo 4/10 (corduroy ridges on the forearm, bark-like wrinkle noise) · SupaVoxel 8/10 (two or three large drapes)
Invented seams — Tripo 3/10 (a hard ridge from crown to nape, a vertical seam down the hood) · SupaVoxel 8/10 (one short soft undulation)
Texture payload — Tripo 2/10 (11.18 MB across 3× 4096 maps) · SupaVoxel 10/10 (0.99 MB across 3× 2048 WebP) — 11.3x
File weight per triangle — Tripo 2/10 (34.12 B) · SupaVoxel 10/10 (6.08 B) — no compression extension in Tripo's GLB at all
First load on a phone — Tripo 1/10 (44.4 s on 12 Mbps) · SupaVoxel 10/10 (3.9 s) — 40.5 s of white screen

What is actually wrong with the Tripo export, part by part: Tripo's shoulder cape and lower skirt come back brown-grey against an input that is black, so the same garment is two colours from crown to hem; Tripo adds a hard ridge line from the crown of the hood to the nape and a vertical seam down the back of the hood, neither of which exists in the input; Tripo's forearm carries evenly spaced horizontal ridges that read as corduroy rather than cloth; and 6.87 MB of the 11.18 MB texture payload is maps a slicer never opens, including one uncompressed 5.28 MB PNG normal map. For this job — one image into a model you will look at, share or put on a page — use SupaVoxel.

The input, byte-identical for both products: 1,671,573 B, sha256 c9bf6970a3f4a973…. A black robe, bone-white skull and hands, a white mug. No scythe and no thin pole — so this case is not about welded-together geometry, it is about the hood cavity, the black-against-white boundary, and a back side that simply is not in the photograph.

The test, in one paragraph

Tripo Studio on its default generation, SupaVoxel on a Full Model with defaults. Both GLBs were downloaded and rendered offline on the same rig — same lighting, same camera positions, same exposure — and the two exports sit at different yaw in world space (Tripo 0°, SupaVoxel 90°), which the render script corrects for. Every pair of images below is one camera, not two flattering angles. Every byte figure comes from parsing the downloaded files, not from either product's panel.

The back side is invented by both, and they invented the same thing

Nothing behind this figure exists in the input, so Tripo and SupaVoxel both had to make it up, and the interesting finding is how little they disagreed: both produced a pointed hood, a shoulder cape narrowing to a V at the spine, and a fan-shaped skirt flaring below it. Structurally, this is a tie, and I am calling it one.

Hood shape (invented) — Tripo pointed · SupaVoxel pointed
Shoulder cape with V at the spine — Tripo yes · SupaVoxel yes
Fan skirt below the cape — Tripo yes · SupaVoxel yes
Back surface colour — Tripo brown-grey leather grain · SupaVoxel near-black, matching the front

SupaVoxel's invented back: pointed hood, a shoulder cape closing to a V, a fan skirt. The whole panel stays the same near-black as the front of the robe.

Tripo's invented back, same camera: structurally the same three elements — and several shades lighter. This is the colour drift, visible at full-body distance and not just in a crop.

The colour is the failure, not the geometry

Zoom the back panel and the difference stops being a shade and becomes a material. Tripo's cape reads as brown leather with a pronounced grain, while the front of the same Tripo robe is black. A single garment is two materials in one Tripo export. What has happened is that a lighting pass — the way a dark surface looks when it is lit from the front and falls off behind — has been baked into the baseColor map, so the shading is permanent and travels with the file into every renderer you open it in.

SupaVoxel's back panel at the same zoom is a smooth broad surface with a crisp silhouette edge and a few faint scratch-like undulations, held at near-black.

SupaVoxel's back panel, zoomed. One material, one value, clean silhouette edge.

Tripo's back panel at the same zoom. Two problems in one frame: brown leather grain where the input has black cloth, and a vertical hard seam running from the top of the hood down to the root of the cape.

Two seams that are not in the input image

Look down at the crown from directly above and Tripo has cut a hard ridge line running from the top of the hood all the way to the nape — a continuous crease across the part of the model that is most visible on a shelf. SupaVoxel's crown closes to a point with one short soft undulation and nothing else.

Add the vertical hood seam from the previous section and that is two invented creases on a garment that has none.

SupaVoxel from directly above: the hood covers the skull completely, only the mug rim and a couple of fingers show, and the crown is a clean closed point.

Tripo from the same overhead camera: the ridge from crown to nape is unmistakable, and it is the second invented crease on this model.

Where both engines passed: the face inside the hood

The hardest thing in this image is a deep hood cavity with a face inside it, and neither product filled it in with a blob. Tripo and SupaVoxel both rebuilt the skull, brow ridge, eye sockets, jaw and the hanging tooth, readable from the front, and Tripo carves the tooth row a little more sharply. This is a pass on both sides, and it is worth saying because it is the part most likely to go wrong.

SupaVoxel from the front: the hood is an open cavity, the skull inside it is complete, and the bone white of skull, hands and mug stops exactly at the hood opening.

Tripo, same camera. The skull is equally complete with a slightly crisper tooth row. The robe around it, however, is carrying 4096-pixel wrinkle noise across the entire surface, which up close reads as coarse bark rather than cloth.

No colour bleed on either side

The second stress axis of this case is whether black cloth bleeds into bone-white skull. Neither Tripo nor SupaVoxel bled. On both, the skull, the hands and the mug hold bone white against the robe, with a clean boundary at the hood opening. Tie, and a clean one.

Corduroy is not drape

From the side, the distributed-detail problem gets a name. Tripo's forearm carries a band of evenly spaced horizontal ridges — regular in pitch, uniform in depth, the look of corduroy. The skirt hem wrinkles are an order of magnitude denser than SupaVoxel's. None of that regularity is in the input image; it is what happens when Tripo spreads high-frequency detail evenly instead of placing it.

SupaVoxel's sleeve resolves as two or three large folds with a continuous drape from hood rim to shoulder line. Fewer creases, and the ones present are where cloth would actually break.

SupaVoxel from the side: large folds, continuous drape, no repeating pattern.

Tripo, same camera: the evenly spaced forearm ridges, and a skirt hem with roughly ten times the crease density.

What you are actually downloading: 66.67 MB against 5.92 MB

Now the weight. Tripo's GLB is 66,672,852 bytes. SupaVoxel's is 5,918,256. That is 11.27x for 2.0x the triangles, so the gap between the two files is not geometry count, it is how the bytes are packed.

GLB size — Tripo 66.67 MB · SupaVoxel 5.92 MB · 11.27x
Bytes per triangle — Tripo 34.12 B · SupaVoxel 6.08 B · 5.6x
Compression extensions required — Tripo none (the list is empty) · SupaVoxel EXT_meshopt_compression + KHR_mesh_quantization, both required
Geometry VRAM — Tripo 55.5 MB · SupaVoxel 27.8 MB

Tripo's file declares KHR_materials_volume and FB_ngon_encoding and requires no compression extension at all. SupaVoxel's is meshopt-compressed and vertex-quantized by the product, not by you running a command-line packer afterwards. That single difference is most of the 11.27x.

SupaVoxel's result: 973,138 triangles in 5.92 MB, one consistent near-black robe, white mug held in a bone-white hand.

Tripo's result: 1,954,204 triangles in 66.67 MB, and the colour drift is visible at this distance — the hood exterior and the lower half of the skirt are already brown against a robe that should be one value.

Half the texture payload is maps a slicer never opens

Tripo ships three 4096×4096 maps totalling 11.18 MB in every Tripo download. Split them by whether anything downstream of a printer will read them:

baseColor (the one a slicer uses) — Tripo 4.32 MB (4096 JPEG) · SupaVoxel 0.58 MB (2048 WebP) · 7.4x
metallicRoughness + normal (unused for printing) — Tripo 6.87 MB · SupaVoxel 0.40 MB · 17.1x
Total texture payload — Tripo 11.18 MB · SupaVoxel 0.99 MB
Map count and format — Tripo 3× 4096 (2 JPEG + 1 PNG) · SupaVoxel 3× 2048, all WebP

Read the first two rows together: the maps Tripo downloads that you cannot use are larger than the one map you can. That is the unusual part — not that a normal map ships, but that it outweighs the colour.

One uncompressed PNG, 5.28 MB of it

Inside Tripo's 6.87 MB sits a single 4096×4096 PNG normal map at 5,284,529 bytes — uncompressed, in a format chosen for lossless line art, carrying a texture that is by nature noise. The equivalent map in the SupaVoxel file is 150,768 bytes. That is 35x for the same slot in the same material.

One map. Five and a quarter megabytes. It is the single largest object Tripo hands back, and it is the one that contributes nothing to a print and least to a render.

Tripo's export dialog with Texture Resolution open. The 4k option — the one marked Current — is what produces the three 4096 maps and the 11.18 MB payload described above.

40.5 seconds of white screen on a phone

Convert Tripo's file size into the unit a visitor experiences. On a 12 Mbps mobile connection, serially and ignoring handshakes:

First load on 12 Mbps — Tripo 44.4 s · SupaVoxel 3.9 s · 40.5 s difference
First load on 100 Mbps home broadband — Tripo 5.3 s · SupaVoxel 0.5 s
Geometry VRAM on the device — Tripo 55.5 MB · SupaVoxel 27.8 MB

Forty-four seconds of Tripo is not a slow preview, it is an absent one — nobody waits, so on a phone that model effectively does not exist. And the VRAM row is the difference between a low-end handset holding a frame rate and dropping it.

Where SupaVoxel falls short on this article's dimensions

Three, and I will not pretend they are worse than they are. SupaVoxel's output carries no real-world unit — the result page reports 0.55 × 1 × 0.57 mm, so the model is one millimetre tall and you scale it before doing anything (everything here is normalised to 120 mm). Advanced Options ships collapsed, so the Inference Steps and Guidance Scale values are one click away rather than visible. And the project is named "New Project 9/26/2026" until you rename it. On a subject whose back is entirely invented, the product should also be prompting you to add a back-angle reference into one of its four spare slots, and it does not.

Final verdict: Tripo scores 60/100

Tripo reconstructed the hard part — the face inside the hood — and Tripo invented the same back structure SupaVoxel did, with a crisper tooth row and genuine geometric creases where SupaVoxel has fewer. Those are real wins and they are in the scorecard.

Against them: the Tripo robe ships brown across the cape and the lower skirt, which is a lighting pass baked permanently into the colour map; two hard seams appear on a garment that has none; the forearm reads as corduroy; and the whole thing arrives as 66.67 MB with no compression extension declared, 11.18 MB of it texture, 5.28 MB of that a single uncompressed PNG, taking 44.4 s to reach a phone. To get the tooth row and the carved creases, the price is 55 credits against 3, 11.27x the bytes, 40.5 extra seconds of load, and a robe that is two colours.

SupaVoxel scores 90/100 — held back from higher by the missing real-world unit and a collapsed settings panel, neither of which changes what the model looks like.

Which one I would put on a page

If the model is going to be looked at — on a page, in a viewer, on a phone — the one I would upload is SupaVoxel's: this figurine in 5.92 MB against 66.67 MB, 0.99 MB of texture against 11.18 MB, 3.9 s of first load against 44.4 s, and a black robe that is still black on the side the camera never saw. Three credits against 55.

Tripo AI 3D Model Review 2026: 2x the Triangles, Same $6.81 of Resin

Greta Holt — Thu, 15 Oct 2026 15:47:41 +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 62/100, SupaVoxel 88/100

I gave one image — a chibi hooded grim reaper holding a white coffee mug — to two image-to-3D products on the same day, downloaded both GLBs, and measured them the way a print shop measures a file: weld the vertices by position, then count shells, holes, winding, slivers, overhang area and resin. Tripo came back with 1,954,204 triangles in one watertight shell. SupaVoxel came back with 973,138 triangles in 263 shells with 393 non-manifold edges, for 3 credits instead of 55. This is the one article in the series where Tripo wins a row that genuinely matters, and I am going to say so in the first screen rather than bury it.

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

Watertight after welding — Tripo 10/10 (0 boundary edges, 0 non-manifold) · SupaVoxel 4/10 (0 boundary edges, 393 non-manifold) — Tripo wins this row outright
Shell count — Tripo 10/10 (1 component, Euler 2) · SupaVoxel 4/10 (263 components, Euler 260) — the mug, hands and robe folds are separate interpenetrating shells in the SupaVoxel file
Holes — Tripo 10/10 (0) · SupaVoxel 10/10 (0) — neither file has a boundary loop to patch
Face winding — Tripo 10/10 (consistent) · SupaVoxel 10/10 (consistent) — no inverted faces on either side
Mesh hygiene — Tripo 6/10 (124 sliver faces) · SupaVoxel 8/10 (27 slivers, 1 degenerate) — Tripo ships 4.6x the slivers
Usable precision at 0.4 mm nozzle — Tripo 9/10 (0.2086 mm mean edge) · SupaVoxel 9/10 (0.3023 mm) — both already finer than the nozzle
Support burden at 45° — Tripo 9/10 (14.91%, 4,680.9 mm²) · SupaVoxel 8/10 (17.44%, 5,482.6 mm²) — 801.7 mm² of extra scar on the SupaVoxel model
Cost of the printable file — Tripo 3/10 (55 credits, 66.67 MB) · SupaVoxel 10/10 (3 credits, 5.92 MB) — 18.3x and 11.27x, for the same object

What is actually true about the Tripo file, part by part: Tripo's mesh is one connected component with zero boundary edges and zero non-manifold edges after welding, so Tripo's file slices without a repair pass — a real win; Tripo carries 124 sliver faces against SupaVoxel's 27, which is 4.6x more degenerate-thin geometry in the same silhouette; Tripo's 1,954,204 triangles average 0.2086 mm per edge at 120 mm tall, which a 0.4 mm nozzle cannot resolve, so half of that geometry is invisible on an FDM printer; and after all of it, the printed object is the same size — 194.56 cm³ against 195.00 cm³, $6.81 of resin against $6.83. For this job — one image, one 120 mm figurine, one person who is willing to run a two-minute solidify pass — use SupaVoxel.

The only input: one image of a chibi hooded reaper holding a white mug, 1,671,573 B, sha256 c9bf6970a3f4a973…. Both products received this exact file with default settings. Note what is not in it: there is no scythe, no long thin pole — the stress axes here are the deep hood cavity, the black/white colour boundary, and an entire back side the camera never saw.

The test, in one paragraph

One image. Two products. Tripo Studio on its default generation (Best Quality on, Clean Topology off — Tripo marks that switch Trial ×2). SupaVoxel on a Full Model with Advanced Options at defaults (Inference Steps 5, Guidance Scale 5.5, Octree Resolution 256). Both GLBs were parsed offline; no number here was copied from a panel. Every render below uses one rig, one lighting setup and one set of cameras, corrected for the yaw difference between the two exports (Tripo 0°, SupaVoxel 90°), so each pair is one viewpoint rather than two flattering angles.

Why every number here is measured after welding the vertices

Both Tripo and SupaVoxel export GLBs that split vertices along UV seams, so counting shells on the raw file counts texture islands, not geometry. Every slicer welds by position on import. Tripo goes from 1,001,168 file vertices to 977,104 welded; SupaVoxel from 503,368 to 486,436, and everything below is measured after that pass. On the raw files both look broken. On the welded files, one of them is a solid and one is not.

Where Tripo wins this case outright: one shell, zero non-manifold edges

Tripo's welded mesh has 1 connected component, 0 boundary edges, 0 non-manifold edges, consistent winding, and Euler characteristic 2. That is the textbook signature of a closed orientable surface, and Tripo earns it here: you can drag Tripo's export into a slicer and press slice.

SupaVoxel's welded mesh has 263 connected components, 0 boundary edges, 393 non-manifold edges, consistent winding, and Euler characteristic 260. The mug, the hands and the robe folds come out as separate interpenetrating shells rather than one solid.

Connected components — Tripo 1 · SupaVoxel 263
Non-manifold edges — Tripo 0 · SupaVoxel 393
Euler characteristic — Tripo 2 · SupaVoxel 260
Welded vertices — Tripo 977,104 · SupaVoxel 486,436

I am not going to dress this up. If you cannot repair a mesh, or you are handing the file to someone who cannot, Tripo is the one that works today, on this case, with no intervention.

Tripo's own viewer after generation. The topology underneath is genuinely clean on this case — and the robe is already brown-grey here rather than the black of the input.

What those 263 shells actually cost you: about two minutes

A Tripo win gets priced here, not hidden. Turning 263 interpenetrating shells into one solid is a single boolean-union / solidify pass in Netfabb or Meshmixer — one to two minutes, scriptable across a batch — and what those two minutes buy is 3 credits instead of 55 (18.3x) and 5.92 MB instead of 66.67 MB (11.27x). If two minutes are worth 52 credits to you, Tripo is the correct purchase and I will not argue.

SupaVoxel, front. The hood cavity is open, the skull, brow ridge, eye sockets, jaw and hanging tooth are all present, and the bone white of the skull, hands and mug stops cleanly at the hood opening.

Tripo, same camera. The skull is equally complete and the tooth row is a little more carved. The cost is the robe: a 4096 normal map spreads high-frequency wrinkle noise across the whole garment, so up close it reads as coarse bark rather than hanging cloth.

Holes and winding: both files are clean on the two rows that hurt

The rows that usually decide whether you open Blender are ties here, at the good end. After welding, Tripo has 0 boundary edges and so does SupaVoxel — no open loop to fill on either side. Both meshes also come back with consistent face winding: no inverted normals, no recalculate-normals pass, on either side.

That matters more than the shell count, because it makes the repair list for the SupaVoxel file exactly one item long: union the shells. Not fill holes, not flip normals, not rebuild. One operation, and what comes out the other side is 3 credits and 5.92 MB against Tripo's 55 and 66.67 MB.

The 2x triangle count does not reach a 0.4 mm nozzle

Tripo delivers 1,954,204 triangles against SupaVoxel's 973,138 — 2.0x. On a Tripo spec sheet that reads as a straightforward win until you convert it into the only unit a printer understands: mean triangle edge length at the target height.

At 120 mm tall, Tripo's mean edge is 0.2086 mm and SupaVoxel's is 0.3023 mm. A common FDM nozzle is 0.4 mm. Both models are already finer than the tool that will make them — Tripo by 1.9x, SupaVoxel by 1.3x. The extra 981,066 triangles buy 0.094 mm of edge length underneath a threshold the printer physically cannot resolve. To cash that 1.45x in you have to change machine class entirely and go to SLA.

Triangles — Tripo 1,954,204 · SupaVoxel 973,138 · 2.0x
Mean edge at 120 mm — Tripo 0.2086 mm · SupaVoxel 0.3023 mm · 1.45x
Finer than a 0.4 mm nozzle by — Tripo 1.9x · SupaVoxel 1.3x
Geometry VRAM for those triangles — Tripo 55.5 MB · SupaVoxel 27.8 MB · 2.0x

SupaVoxel with textures off. The hood really is a hollow cavity, the mug is a real tube with an inner bore, and the tattered holes along the robe hem survived from the input. Do not be fooled by how solid this looks — it is 263 shells.

Tripo, same camera, textures off. The fold creases here are genuinely cut into the geometry rather than faked by a normal map — that is what 1,954,204 triangles and a 0.2086 mm mean edge bought. Underneath, the topology is one clean shell.

Two wireframes you cannot read, and that is the finding

Zoom the wireframe at print scale and you get a black rectangle, from Tripo and from SupaVoxel alike. SupaVoxel's still shows a few isolated cells on the hood crown; Tripo's shows none at all, its density having passed the pixel grid of the render itself. Both images being unreadable is the result: at 120 mm neither the printer nor your eye gets to see the difference. What you do see is the bill — 66.67 MB against 5.92 MB, 55.5 MB of geometry VRAM against 27.8 MB.

SupaVoxel wireframe at high zoom — 973,138 triangles, 0.3023 mm mean edge, a few cells still resolvable on the crown.

Tripo wireframe at the same zoom — 1,954,204 triangles, 0.2086 mm mean edge, no resolvable cells at all. Denser soup, not better topology.

Sliver faces: Tripo ships 4.6x more of them

Sliver faces are the near-degenerate thin triangles that make repair tools and slicers argue with each other. Tripo's mesh carries 124 of them, on the same file Tripo shipped as one clean shell. SupaVoxel's carries 27. That is 4.6x more on the file that is otherwise the cleaner solid — so "mesh hygiene" is not a row Tripo sweeps, it is a row that splits.

Sliver faces — Tripo 124 · SupaVoxel 27 · Tripo 4.6x worse
Degenerate faces — Tripo 0 · SupaVoxel 1 · 0.0001% of 973,138 faces

Degenerate faces: one in the SupaVoxel file, and it is 0.0001% of the mesh

The one genuinely degenerate face in this run is in the SupaVoxel file — one face out of 973,138, or 0.0001% of the mesh, and Tripo has none. Every repair tool ever written removes it without being asked. I list it because the rule in this series is that every number in the evidence file gets published, including the ones pointing the wrong way.

Support: SupaVoxel needs 801.7 mm² more, worth under three cents

Counting the surface whose normals point more than 45° downward at a 120 mm print: Tripo needs support on 14.91%, or 4,680.9 mm². SupaVoxel needs 17.44%, or 5,482.6 mm². That is 801.7 mm² more support contact on the SupaVoxel model, from one identifiable place — its skirt hem flares wider (67.8 mm in Z against Tripo's 67.05 mm). Priced at the same resin rate it is under $0.03. Tripo wins the row; the Tripo advantage on this line is three cents a figurine.

SupaVoxel from the side. The sleeve falls in two or three large folds and the drape is one continuous surface from hood rim to shoulder line.

Tripo, same camera. The forearm carries a band of evenly spaced horizontal ridges — corduroy rather than cloth. That is high-frequency detail distributed uniformly, and it is not in the input image.

Same figurine, same resin: $6.81 against $6.83

Scale both to 120 mm tall and measure the solid volume after welding. Tripo: 194.56 cm³, $6.81 of resin at $35/L. SupaVoxel: 195.00 cm³, $6.83. A 0.3% difference — two cents.

The bounding boxes land within 1.1 mm of each other on every axis (Tripo 67.55 × 120.0 × 67.05 mm, SupaVoxel 66.47 × 120.0 × 67.80 mm), so neither model has been squashed or stretched relative to the other. Eighteen times the credits, and the object that comes off the build plate is the same object, the same size, out of the same amount of resin.

SupaVoxel from above. The hood completely covers the skull; only the white rim of the mug and a few fingers are visible. The crown closes to a clean point.

Tripo from the same overhead camera. A hard ridge line runs from the crown all the way to the back of the neck — a continuous seam that is not in the input image. SupaVoxel's crown has one short soft undulation and nothing else.

Getting the file out of Tripo: a blob URL that revokes itself

Tripo's export dialog is three fields — File Name, Format, Texture Resolution — and this run recorded 2 clicks from dialog to file. What Tripo hands back is a blob: URL revoked the moment it is clicked, so capturing the file for this test required an interception hook. SupaVoxel's result page carries an Export dropdown with version selection (v1 - Sep 26 12:33 AM) in the top bar, but this run recorded no click count for it, so that cell stays empty. Not measured is not zero, and I will not fill it with a guess.

Tripo's export dialog: File Name / Format / Texture Resolution, with Texture Resolution parked at 4k and marked Current. Two clicks to a file, and the file arrives as a self-revoking blob URL.

What Tripo's result page will not tell you: the size in mm

SupaVoxel's result page reports Triangles 973,138 — matching the parsed GLB digit for digit — next to four inspection modes (Textured / Mesh / Wire / Normals) and a mm / in / raw unit switch with a live dimension readout. Tripo's result page carries no dimension readout anywhere, in any unit, and Tripo's own triangle count was half-covered by a promotional banner, leaving "/ 1954204".

The knock on SupaVoxel on this row, since it belongs here: its output has no real-world unit — the page reports 0.55 × 1 × 0.57 mm, so you scale it yourself before slicing (everything here is normalised to 120 mm). Tripo gives no dimension at all, but having built the unit switch already, what SupaVoxel is missing is just export-at-real-size.

Final verdict: Tripo scores 62/100

Tripo wins the headline row of this article cleanly: one shell, zero boundary edges, zero non-manifold edges, consistent winding, Euler 2. On this case Tripo hands back a slice-it-now file, and if the person receiving it cannot repair a mesh, that is worth paying for.

Everything after that row goes against Tripo. The 2.0x triangle count evaporates at a 0.4 mm nozzle where both meshes are already finer than the hardware (1.9x and 1.3x). Mesh hygiene splits 124 slivers to 27 against Tripo. The 14.91% support advantage is worth under three cents. And the object is identical: 194.56 cm³ against 195.00 cm³, $6.81 against $6.83. What differs is the invoice — 55 credits against 3, 66.67 MB against 5.92 MB — and one solidify pass of about two minutes that scripts across a batch.

SupaVoxel scores 88/100 rather than 91 precisely because of those 263 shells. It is the one row in this series where I would not blame anyone for choosing Tripo.

Which one I would use for this job

If your job is this job — one image, one 120 mm printable figurine, a person who can run one solidify pass — then the file I would keep is SupaVoxel's: 3 credits against 55, 5.92 MB against 66.67 MB, the same 195 cm³ of resin, zero boundary edges, consistent winding, and 27 slivers against Tripo's 124. The repair list is one line long and it is scriptable. The credit difference is 18.3x and it is not.

Hyper3D GLB Review 2026: A 27.81 MB ZIP for a Knitted Tray

Greta Holt — Tue, 13 Oct 2026 15:51:48 +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 put a cable-knit serving tray on the screen and asked two image-to-3D tools to turn the picture into a model. From the hero angle both returned a tray. From above I had a different question: did the over-under ropes in the photograph become raised geometry, or had the pleasing fabric moved into the paint?

I compared the files in the same offline viewer and then switched the material off. Hyper3D's downloadable Gen-1.5 version has prominent wall ropes and raised—but largely parallel—floor bars. SupaVoxel has a finer diagonal wall and a busy, soft-looking floor; much of that floor effect disappears in bare mesh view. Neither copies the source's regular floor crossings.

My verdict in 60 seconds — Hyper3D Gen-1.5 wins a received, lighter PBR tray with coarse raised relief; SupaVoxel earns the finer-wall visual brief, not an exact-knitted-floor claim. Hyper3D's Free route delivered a 27.81 MB ZIP with an 18.64 MB PBR member. SupaVoxel's Original size browser export failed; its 74.36 MB analysis GLB was rebuilt locally, never transferred by that button. Yet the wall has a finer diagonal surface and the interface lets me check the textured picture against a bare mesh. If that wall appearance is the job, SupaVoxel is the design candidate I would test again—without telling anyone the pictured floor cables are physically reproduced.

Eight paired checks from the files and views:

Shallow-tray silhouette — Hyper3D: open basin with apertures · SupaVoxel: open basin with apertures.
Fine wall pattern — Hyper3D: chunky rope forms · SupaVoxel: finer diagonal relief.
Floor like the source — Hyper3D: parallel bars · SupaVoxel: irregular clusters; neither repeats crossing cables.
Bare-mesh floor — Hyper3D: raised rows stay visible · SupaVoxel: much of the textured puff disappears.
Embedded images — Hyper3D: three 2048² PNGs · SupaVoxel reconstruction: three 4096² PNGs; pixel count is not color fidelity.
Topology after welding — Hyper3D: one closed shell, zero nonmanifold edges · SupaVoxel: same result.
As-is standalone PBR burden — Hyper3D: 18.64 MB extracted member · SupaVoxel: 74.36 MB local reconstruction, if hosted separately.
Recorded browser delivery — Hyper3D: ZIP arrived · SupaVoxel: attempted Original size export failed.

The thumbnail asks one question. A tactile print, a finely decorated concept and a received client file ask three different ones.

Start with what the source actually shows

The same independently generated 1,862,608-byte PNG went to both products. Its raised tray has ordered rope crossings on wall and floor; only the right-hand opening is visible. A craft-gallery cover supplied visual reference, not a source mesh. Hidden reverse geometry remains unknown. At a normalized 120 mm longest bounding-box side, the resulting heights are 24.48 mm for Hyper3D and 20.71 mm for SupaVoxel—not 120 mm tall.

Photographic reference: readable large cable crossings, one visible right opening and an unseen back.

A close-looking silhouette is only the first test

Both generated open shallow trays with side handles. Hyper3D's accessible Gen-1.5 result reads immediately as chunky rope-work, with a stronger rim and larger raised braids on the wall. SupaVoxel's four-quarter view has a tidier fine diagonal wall and paler, lumpier floor. Neither description should be extrapolated to Gen-2.5 geometry: that version could be viewed in the Free account but could not be downloaded or measured. The 12.5-to-one triangle-count ratio favors SupaVoxel numerically, yet the visual target is the specific crossing pattern, not triangle density in isolation. Buyers who just need a decorative thumbnail might accept either broad silhouette; buyers matching the pictured knit should look closer.

SupaVoxel's own 3D model keeps a continuous shallow tray form but changes the pattern language.

From the top, neither floor follows the photographed cables

Hyper3D's floor divides into slanting rows of almost parallel raised bars. The direction is clearer than SupaVoxel's clusters, but the input's over-and-under crossings are gone. SupaVoxel's top has denser short diagonals and bumps without repeatable large strands. Neither faithfully reconstructs the pictured layout. A physical reproduction would need manual resurfacing. Hyper3D has 120,000 triangles and SupaVoxel 1,500,000; counting triangles cannot fill in a nonexistent path.

Top of the delivered PBR file: raised parallel direction replaces the input's intersecting cables.

Top of the locally reconstructed analysis file: denser patches are not the source's regular braid.

Remove the color before assigning depth

Hyper3D still has coarse wall ropes and discernible parallel floor bars when the textured material is removed. SupaVoxel retains genuine fine diagonal wall relief and open holes, yet most of its floor's fluffy appearance subsides into a nearly smooth sheet in the mesh-only render. This is a more useful distinction than “textures are fake” versus “everything is sculpted.” Both models contain some physical structure; both also rely on shading and material for part of the knitted impression. SupaVoxel's 1.5 million triangles do not certify that its floor can print like the input, while Hyper3D's more visible ribs are not the input's crossings. At a 120 mm longest side, a 0.4 mm FDM nozzle remains only an assumed reference, not a demonstrated feature test.

No material: Hyper3D's ribs and wall ropes remain geometric, but the floor cable path is simplified.

No material: SupaVoxel's floor loses much of the bumpiness visible in its textured render.

The unseen back is a reconstruction, not a test answer

The reverse close-ups make the difference theatrical. Hyper3D adds a conspicuous central oval opening with strong vertical channeling; SupaVoxel carries finer diagonal texture around a flatter, more continuous rim. These are useful observations for someone who must edit the file. They do not tell us which back is accurate, because the input camera never showed it. The relative camera positions were checked at four yaw angles and matched approximately, but the hole locations are not point-by-point registered between objects. In a one-photo workflow, the only responsible comparison is whether the added geometry suits the intended use, not whether it reproduces an invisible reference.

Hyper3D's prominent back hole and vertical grooves are generated additions to an unseen side.

SupaVoxel's reverse uses finer surface detail; the hidden truth remains unmeasured.

What the material files actually contain

The extracted Hyper3D PBR GLB carries one material, UV coordinates and three embedded 2048 × 2048 PNG images: baseColor 4,710,007 bytes; normal 4,456,634; metallicRoughness 4,908,032. The SupaVoxel locally reconstructed GLB likewise has one material and three embedded 4096 × 4096 PNGs: baseColor 16,081,664 bytes; normal 11,740,543; metallicRoughness 2,529,720. Each larger SupaVoxel texture has four times the pixel count of a 2K counterpart, but its image's encoded byte size varies by content. We did not measure albedo ΔE, sample colors under controlled light or estimate UV atlas occupancy. Therefore the image dimensions are storage facts, not an experimentally proven accuracy ranking.

The Free-tier Gen-1.5 material path exposed 2K PBR; the tested 4K option was unavailable.

For a monochrome print, count unused images on both sides

A standard monochrome-resin slice does not consume a baseColor image, a normal map or a metallic-roughness map as visible printed color. For a color-capable process that reads baseColor, the potentially useful bitmap is 4.71 MB in the Hyper3D GLB versus 16.08 MB in the reconstructed SupaVoxel GLB; the remaining two images total 9.36 MB versus 14.27 MB. If the job is monochrome, even those baseColor files are not part of the print result. That does not mean deleting embedded textures reduces each GLB by the simple sum of file entries—container layout and compression need separate measurement. More importantly, removing maps cannot create the missing crossing floor ridges. Image-asset budget and physical relief are different engineering questions.

Four visible viewing modes let the user compare colored appearance against mesh and normals before printing.

A browser ZIP is not its extracted GLB

Hyper3D's actual Free-tier download was a 27,809,936-byte ZIP after selecting GLB with Shaded and PBR checked. The PBR member used here is 18,642,076 bytes; its companion Shaded member is 9,167,608 bytes. The difference between the ZIP transfer and the PBR member is about 9.17 MB, but it is not necessarily all network “waste”: the bundle contains another valid format variant. If a client only needs the PBR asset, it nevertheless downloads and unpacks the bundle. The SupaVoxel Original size choice did not deliver a browser file when we tested it, so its website-download byte count and time are unknown. Any chart comparing 27.81 directly with 74.36 as observed browser transfers would be false.

This GLB selection delivered two GLB variants in one ZIP, not the standalone PBR member used for analysis.

Where the 74.36 MB figure comes from

The SupaVoxel Original size browser conversion failed; no file was saved by that action. We retained a 10,132,072-byte compressed project source, then locally decoded its geometry and converted its images to PNG, producing a 74,362,796-byte analysis GLB. Local encoding can differ from the browser's, and lossy source detail cannot be restored. So 74.36 MB supports analysis and a hypothetical hosting budget for this reconstructed file only: neither observed website transfer nor a guarantee of byte-identical browser output.

The menu offers Original size; in this run the browser conversion failed and actual Original size transfer remained unknown.

If separately hosted, the larger file costs time

Imagine hosting the extracted Hyper3D PBR GLB and the reconstructed SupaVoxel analysis GLB as-is on the same CDN, with no cache. At an assumed 12 Mbps, decimal-byte ideal transfer-only lower bounds are 12.43 seconds and 49.58 seconds. At 100 Mbps they are 1.49 and 5.95 seconds. These omit latency, retries, decoding, rendering and any page code. Per 10,000 full file loads at an assumed $0.085 per decimal GB, the projected CDN charges are $15.85 and $63.21, a $47.36 difference for those hosted files. Hyper3D's own webpage instead sent a ZIP; SupaVoxel sent no successfully captured Original size export. Neither product's actual end-user website download is timed by this invented third-party hosting scenario.

Side comparison image represents the extracted PBR object, not the size of its browser-delivered ZIP.

Files, triangles and device memory

Suppose you're putting a rotatable version on a craft-store page, not printing it. Host only the two analytical PBR GLBs: Hyper3D's extracted member is 18.64 MB for 120,000 triangles; SupaVoxel's locally reconstructed model is 74.36 MB for 1,500,000. That works out to 155.35 versus 49.58 bytes per triangle; SupaVoxel packs more shape per byte, but still needs 3.99 times the total file bytes in this as-is scenario. A simple geometry-memory budget—32 bytes per vertex and 4 per triangle index—is 4.57 versus 44.01 MB, excluding textures and runtime. For 100 separately hosted models of these same sizes, disk or one uncached pass of downloads would be 1.864 versus 7.436 GB. A planning sketch, not an observed download or generated batch.

More dense geometry on the SupaVoxel object affects this hypothetical memory budget without proving better photographed knit.

Final verdict: watch the floor, then label the file

Hyper3D's obtained Gen-1.5 PBR file shows more convincing sculpted wall ropes and raised floor bars than its own preview would prove, yet those bars run alongside each other instead of crossing like the input. SupaVoxel makes a finer diagonal wall and a fuller-looking textured floor, but much of that floor effect fades when material is removed. Neither earns a claim of matching knitted geometry. For a photographed cable-knit tray that must become a received, lightweight PBR file, Hyper3D leads this single run: 27.81 MB actual browser ZIP and 18.64 MB extracted PBR. My SupaVoxel 74.36 MB figure belongs to a local reconstruction for offline analysis, not a successful site download.

The trade is a real one. SupaVoxel offers four inspection views, 12.5 times as many triangles and a finer surface language; Hyper3D has a delivered file, stronger coarse relief, and a smaller as-is hosted PBR payload. That is a difference in task fit, not an accuracy ranking for every image.

Use SupaVoxel for this job

For a digital mood board where the wall's fine diagonal texture matters, SupaVoxel is a useful second design pass. Flip from Textured to Mesh before selling that appearance as printable cable relief; test the browser export your client requires. If the floor must physically reproduce the pictured crossings, plan manual resurfacing whichever generator you choose.

How I tested this

One independently generated reference PNG was fed to both tools. Hyper3D's accessible Free-tier Gen-1.5 result was the PBR member of an actually browser-downloaded two-GLB ZIP; the separate charged Gen-2.5 preview was never downloaded. SupaVoxel's compressed project source was retained, but the Original size browser conversion failed; a 74,362,796-byte GLB was reconstructed locally for analysis and is not proven byte-identical to a working browser export. Renders use the same offline camera and light settings with approximate, not feature-registered orientation. We did not measure unlit ΔE, UV occupancy or a physical print; the reverse side of the input is unseen. The 12 Mbps and 100 Mbps transfer estimates and uncached CDN bills are hypothetical calculations on specified files, not observed downloads. A 120 mm longest bounding-box side is not a 120 mm tall tray.

Hyper3D 3D Print Review 2026: 0 Nonmanifold Edges, No Fit Test

Greta Holt — Sun, 11 Oct 2026 15:52:47 +0000

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

I used a picture of a purple Z-rod cleaner to test whether image-to-3D output could serve as a print-preparation starting point. The reference showed a long slot and two open U-shaped jaws, but no target rod or jaw clearance. Would a good-looking generated clip be a valid solid mesh? Would it actually grip anything? Those are separate questions; I measured only the first.

I fed the identical image to Hyper3D and SupaVoxel, downloaded the obtainable textured models, welded their UV seams and inspected what a slicer would have to consume. Hyper3D's downloadable file came from a separate Gen-1.5 run, not its paywalled Gen-2.5 preview.

My verdict in 60 seconds — Hyper3D Gen-1.5 is the cleaner starting solid for print preparation; SupaVoxel is the better-looking purple design reference. Hyper3D's obtained file has one welded watertight face-connected shell and zero nonmanifold edges. SupaVoxel's actual downloaded GLB has more continuous purple jaws and a finer slot line, but 412 nonmanifold edges and 217 face-edge-connected shells touching through vertices. I would hand Hyper3D's file to a print technician first; I would use SupaVoxel for appearance review only with a clearly identified repair step. Neither file passed a physical fit test, and SupaVoxel's visible repair option was not exercised.

Eight paired checks for the same open-jaw image:

Visible jaws and slot — Hyper3D: both U shapes and long opening survive · SupaVoxel: both survive too.
Welded watertightness — Hyper3D: one closed face-connected shell · SupaVoxel: non-solid under the same test.
Nonmanifold edges — Hyper3D: zero · SupaVoxel: 412 after positional seam welding.
Triangle hygiene — Hyper3D: zero degenerates and 458 slivers · SupaVoxel: 576 and 2,077.
Mean edge length at scale — Hyper3D: 0.4156 mm · SupaVoxel: 0.1157 mm at 120 mm longest side; neither is jaw clearance.
Purple jaw appearance — Hyper3D: gray exterior patches · SupaVoxel: more continuous purple in matched renders.
Potential downward-facing surface — Hyper3D: 1,176.1 mm² · SupaVoxel: 984.5 mm² in model-Y orientation, not measured supports.
Actual rod/clip fit — Hyper3D: not measured · SupaVoxel: not measured; no caliper, elasticity test or print.

No scored “print-readiness” number can substitute for measuring the mating hardware.

What does the photograph actually specify?

The shared 1,529,736-byte PNG gives you purple plastic, a central lengthwise slot and two open U-shaped ends. It doesn't give you a drawing of the underside, a rod diameter or a tolerance for the snap fit. Imagine an operator asking whether their actual rod will fit: the picture has no answer. Hyper3D interpreted this same input differently for Gen-2.5 and Gen-1.5, so I will not pass off the former's preview as the latter's measured file. The actual file comparison is Hyper3D Gen-1.5 PBR against SupaVoxel's browser-exported Original size GLB. Those empty areas are open jaws, not a precision-drilled closed bore.

The identical 1,529,736-byte input to both Hyper3D and SupaVoxel runs; no calibrated ruler or target rod is pictured.

Can you see through both jaws?

Viewed from the open end, Hyper3D preserves the paired U-shaped jaws rather than filling them in. That matters more here than the presence of a decorative pattern: this Hyper3D object is supposed to clip around something. The matched SupaVoxel end-on view also leaves both U shapes open and has more continuous purple coloration at the jaw tips. Neither Hyper3D nor SupaVoxel render contains a scale reference, and an opening that looks plausible on screen may still miss the actual rod by a fraction of a millimeter. The controlled comparison was each exported asset rescaled until its longest bounding-box side measured 120.0 mm; this did not set either jaw mouth to a known size. We did not perform an inside-jaw caliper measurement.

Hyper3D Gen-1.5 viewed from the jaw end; the two openings are visible, but their clearances were not measured.

Will the mesh even form a solid?

A printed solid needs more than a persuasive shaded render. We examined the downloaded Hyper3D and SupaVoxel textured GLBs and welded positional duplicates at UV seams before checking topology. The 120,000-triangle Hyper3D Gen-1.5 file then formed one face-connected watertight shell, with zero boundary edges and zero nonmanifold edges. SupaVoxel's 1,499,510-triangle file still failed the watertight check with 412 nonmanifold edges, even though its boundary-edge count was also zero. “No holes” in one edge-count column is not the same as a well-formed solid when edges meet more than two faces. For this part, Hyper3D gave the cleaner first candidate to inspect in a slicer; the result still needs physical dimensions and print verification.

The downloadable Hyper3D Gen-1.5 gray mesh retains the open-jaw silhouette; welded checks find zero nonmanifold edges.

Are 217 shells really 217 separate parts?

The number 217 sounds like a bag of broken pieces. It isn't. In SupaVoxel's file, 217 groups of faces do not share a full edge with each other, but the groups touch through welded vertices; by that looser measure the model is one connected assembly. It would be wrong to tell the print shop it contains 217 separate parts. It would be just as wrong to treat point contacts as sturdy joins or to calculate a resin volume from a mesh that fails the solid check. Hyper3D's welded file has one face-edge-connected shell. A clean screenshot and an intact-looking purple silhouette cannot settle this handoff: export topology can.

SupaVoxel's gray view, compared with Hyper3D, is visually continuous; the exported mesh has 217 edge-connected face shells but one vertex-connected assembly.

Would flipping the normals repair it?

Both Hyper3D and SupaVoxel meshes passed the standard welded winding-direction consistency check. A stricter directed-edge pass on the SupaVoxel file flagged 216 conflicts, but every one was a degenerate zero-length self-edge artifact; the count of direction conflicts on nondegenerate shared edges was zero. That is not evidence of a backwards-facing jaw or an inside-out body. It also does not rescue the 412 nonmanifold edges or turn the mesh watertight. The distinction matters when deciding a Hyper3D comparison or repair: blindly flipping normals would target a defect not demonstrated by this test. Hyper3D also has consistent winding, zero boundary edges and zero nonmanifold edges after welding. If you are diagnosing print failure, preserve those separate observations rather than collapsing them into a generic “bad mesh” or, worse, blaming a color patch on reversed polygons.

Purple SupaVoxel render, compared with Hyper3D, has intact jaws; the 412-edge topology problem does not announce itself in this shaded view.

The real SupaVoxel result screen shows the model before export; only the separately parsed GLB revealed its nonmanifold edges.

What will the repair technician actually face?

The Hyper3D Gen-1.5 export has zero degenerate faces and 458 sliver faces. The SupaVoxel export has 576 degenerate and 2,077 sliver faces in the same offline analysis. A degenerate triangle consumes file structure without spanning a proper area; a sliver is narrow relative to its other dimensions. Neither count alone proves a printable clip or predicts the strength of a loaded spring arm. But the combination of SupaVoxel's degenerates, slivers and nonmanifold edges gives an operator concrete repair targets before slicing. Conversely, Hyper3D's cleaner counts do not magically specify clearance or print orientation. The Hyper3D and SupaVoxel wireframe close-ups are difficult to interpret at these triangle densities; the numbers come from parsing the exported GLBs, not from counting dark lines in a screenshot. Visual geometry and machine-checkable topology answer different questions.

Hyper3D wireframe crop; the parsed file, not line density in the picture, establishes zero degenerate faces and 458 slivers.

Does a fine triangle mean a precise jaw?

At the common 120 mm longest-side normalization, mean triangle-edge length is 0.4156 mm for Hyper3D and 0.1157 mm for SupaVoxel. The latter is finer on average, and its 1,499,510 faces are roughly 12.50 times the Hyper3D export's 120,000. A 0.4 mm FDM nozzle is a useful reference assumption, not a theorem saying a 0.4156 mm triangle prints or a 0.1157 mm triangle is wasted. Edge length is not minimum jaw wall, corner radius, internal clearance, or extrusion width at the critical contact point. A coarse Hyper3D average can hide tiny features; one dense mesh can bury large topology defects. For the task of fitting a real rod, the next measurement is the opening and arm thickness in physical units, not another polygon-count comparison.

At 1,499,510 triangles this SupaVoxel crop, beside Hyper3D, becomes almost black; it cannot visually certify printable wall thickness.

Where would support be needed?

Using model-world Y as up and marking triangle normals within 45 degrees of straight down, the potential downward-facing area is 1,176.1 mm² (15.10%) on Hyper3D and 984.5 mm² (12.96%) on SupaVoxel, after longest-side normalization. The SupaVoxel number is smaller than Hyper3D's, and it deserves disclosure even though that mesh failed the solid check. But this is not a slicer's support volume, a support-material budget, or the area that will definitely need support in a chosen print orientation. Rotate the clip for printing and the directional classification can change. A repair to nonmanifold regions may also alter which faces are present. Before quoting print duration or support cost, an operator should repair the second mesh, pick an orientation for each, slice them and inspect the contact features.

The SupaVoxel top view, beside Hyper3D, shows the slot and jaw geometry; 984.5 mm² is only a potential downward-area calculation.

Can I quote the resin for one clip?

The Hyper3D welded file is closed, consistently wound and free of nonmanifold edges in this test, so a simplified solid volume can be calculated: 14.96 cm³ at the normalized size. At $35 per liter, solid-fill resin alone would be about $0.52 for that volume. The Hyper3D estimate excludes supports, losses, hollowing, machine time, orientation, cleaning, curing and failed fits. The Hyper3D $0.52 is not a print quote. The SupaVoxel export's 412 nonmanifold edges prevent a trustworthy signed-solid volume, so a corresponding volume or resin-dollar estimate is not captured. More importantly, even a defensible solid volume says nothing about whether the printed plastic can flex around a rod without breaking.

The topology-valid Hyper3D Gen-1.5 file supports a simplified 14.96 cm³ solid-fill calculation, not a tested finished part.

Final verdict: the cleanest shell still needs a real rod

I would hand Hyper3D's downloadable Gen-1.5 clip to the print technician first. After UV-seam welding it is one watertight face-connected shell with zero nonmanifold edges, zero degenerate faces and a valid simplified solid-volume estimate. SupaVoxel's 412 nonmanifold edges and 576 degenerate faces make its exported clip a repair job before slicing; a pleasant purple render cannot waive that work. But a watertight flag cannot tell me if either jaw fits a Z rod, how far the arms flex or whether a finished part would survive repeated use. That makes Hyper3D the more defensible starting mesh in this one test, not a finished clip.

The purple jaw silhouette is easy to inspect; jaw clearance remains unmeasured.

SupaVoxel genuinely wins the visible color and fine surface line. Its potential downward-facing area at the stated orientation is 191.6 mm² lower, though that is not a support-material saving. Both applications left the U-shaped openings visually open. If appearance is the brief, those are reasons to carry its model into a repair-and-measure workflow rather than rejecting it on a screenshot alone.

Use SupaVoxel for this job

The back is an inference from one picture, not a fit drawing.

Another inferred back: a smoother picture does not establish a stronger clip.

For a purple concept model you can rotate, inspect in Mesh and compare against the reference, SupaVoxel is the appearance-led choice. Use its visible repair entry only after testing it yourself—we did not activate that tool—and re-audit the GLB after any repair. For a clip being sent straight to a print technician, prefer the cleaner Hyper3D Gen-1.5 starting file, then measure jaws against the actual rod and make a physical test piece. Neither file is a proven maintenance tool.

How I tested this

The same independently generated 1,529,736-byte PNG went to both applications. The Hyper3D Gen-1.5 ZIP and the SupaVoxel Original size GLB were both actually captured; the separate charged Hyper3D Gen-2.5 preview was export-gated. We welded duplicate positions across UV seams before checking face/edge and vertex connectivity, winding and edge incidence. SupaVoxel has 217 face-edge-connected shells but one vertex-connected assembly: do not call them 217 disconnected parts. Its 216 strict directed-edge conflicts were all zero-length self-edge artifacts; nondegenerate winding conflicts were zero, but 412 nonmanifold edges remain. Longest bounding-box edge—not vertical height—was normalized to 120 mm; calculated vertical spans are 13.13 and 11.24 mm. The $0.52 Hyper3D figure assumes 14.96 cm³ solid fill at $35/L and excludes supports, orientation, machine time and failed fits. SupaVoxel has no defensible solid-volume quote. No slicer, physical print, caliper, target rod diameter or jaw-flex test was performed.

Hyper3D Hand Stand Review 2026: A Watertight Mesh Isn't a Fit Test

Greta Holt — Fri, 09 Oct 2026 15:49:50 +0000

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

I wanted a hand-shaped desk piece that could hold a controller between sessions. The illustration looked promising: two fingers raised above a wrist rising out of rock. I needed to know whether I had a printable starting shape, not whether an AI could draw me another attractive hand.

So I gave the identical picture to Hyper3D Rodin and SupaVoxel, downloaded the models I could actually get, and checked the meshes rather than stopping at the preview. The result split my decision in two.

My 60-second verdict — SupaVoxel is the richer digital-sculpting starting point here; Hyper3D is the cleaner unrepaired solid candidate. SupaVoxel is where I would start if I wanted the palm, fingers and broken rock to survive a close-up. Its 952,876 triangles gave me much more sculptural surface than Hyper3D’s downloadable 120,000-triangle Gen-1.5. If I had to send an unrepaired file toward a slicer, however, I would switch my pick to Hyper3D: its welded mesh passed the static solid check and SupaVoxel’s did not. Neither is an approved controller stand; no controller was fitted, no prototype was printed and no finger was loaded.

My eight-line decision card — each row records an observation and the choice it informs for this digital-sculpture job:

Recognizable hand and rocks — both preserve the broad pose — I can keep SupaVoxel’s richer palm and fractured base for a close crop rather than sculpting that relief back in.
Geometry budget — 120,000 vs 952,876 triangles — more faces give the close-up artist more sampled shape, not automatic strength.
Unrepaired solid screening — Hyper3D welded watertight; SupaVoxel not watertight — if my next step is slicing, the preference reverses.
Nonmanifold edges — 0 vs 213 after welding — SupaVoxel creates a repair-and-recheck task before volume or print planning.
Face-connected regions — 1 vs 143 after welding — touching at a vertex is not the same as a continuous printable body.
Sliver faces — 388 vs 45 under the same criterion — this smaller mesh-health row genuinely goes SupaVoxel’s way.
Potential downward area — 2,573.1 vs 3,016.0 mm² at a 120 mm longest side — neither is measured support material, so this row cannot decide a print quote.
Actual controller fit — no measured cradle, clearance or load test on either side · Hyper3D unscored · SupaVoxel unscored — I will not award engineering points for a convincing render.

One image per service and a separate locked Hyper3D generation.

What was the job I thought I was buying?

I pictured a controller resting between raised fingers, with rock steadying the wrist. The image supplies a palm-forward gesture and rocky base, not a measured controller width, contact patch, cradle depth or load path. I can grade the sculpture in a render, not device clearance from drawn fingers.

The common source image: a gesture and rock base, not a measured device-holder drawing; publication rights still require review.

Which Hyper3D generation did I actually hold in my hands?

This matters more than a model name on a screenshot. Hyper3D Gen-2.5 produced a preview, let me confirm its geometry and showed a GLB option. Pressing Download on the tested Free account brought up a subscription demand. I got no Gen-2.5 GLB. I then made a separate Gen-1.5 generation from the same image; that one delivered a ZIP whose 13,098,572-byte PBR member is the mesh in this article. All Hyper3D topology and triangle numbers below belong to Gen-1.5, not the unavailable higher-generation preview. An impressive preview is not a file I can slice, retouch or quote to a customer.

Gen-2.5 on the tested Free account stopped at the Download gate; there is no Gen-2.5 file behind this comparison.

At desk distance, do both still look like hands?

Yes. Hyper3D’s front gives me the raised fingers, a readable wrist and a rock enclosure. I would not reject it at thumbnail size. SupaVoxel’s front makes the palm folds, curled fingers and uneven rock pieces more legible. That matters to someone making a hero illustration: if the hand has to fill half a product page, I want the gesture to keep its local relief instead of relying on paint alone. It is a visual judgment from these two renders, not an anatomical accuracy measurement. Both pictures use the same original PNG, but I did not inspect each company’s internal cropping or interpretation.

Hyper3D Gen-1.5 front: the gesture survives, but the palm and rock transitions look comparatively regular.

SupaVoxel front: more varied rock and palm shaping in this actual exported file, not a preview-only image.

What does almost eight times the geometry buy me?

Hyper3D’s downloadable PBR has 120,000 triangles and 92,233 vertices; SupaVoxel has 952,876 triangles and 490,760 vertices. At the demonstration scale where each model’s longest bounding-box side is set to 120 mm, average mesh edges are 0.5901 mm and 0.2305 mm. The number is a measure of sampling, not feature thickness. Still, it explains why the dense file gives an artist more surface to work with around small rocks and finger folds. If the art director asks for a crop right across the palm, that is the place I would spend a larger mesh budget. A sparse polygon count does not mean Hyper3D’s silhouette is broken; it means I should inspect the small forms before approving a close-up.

With color gone, Hyper3D’s broad gesture remains at 120,000 triangles; geometry, not paint, carries the silhouette.

SupaVoxel’s denser untextured surface retains more local rock and hand relief; density is not a manifold certificate.

Why does the prettier close-up lose the solid test?

I welded duplicate UV-seam vertices before counting edge incidence; otherwise a texture seam can look like an opening in the raw vertex data. Hyper3D then had one face-edge-connected region, consistent winding, no boundary edges and no nonmanifold edges. SupaVoxel had zero boundary edges too, but 213 nonmanifold edges and 143 face-edge-connected regions. Its vertex-connected region count is one: some pieces meet at points. That does not give me a single proper shell. This is the awkward trade: the file I like more as a sculpture is the file I must repair before asking a slicer to treat it as a volume. I have not performed that repair or measured how long it would take.

Hyper3D’s local wireframe; its zero welded nonmanifold edges come from the file test, not this screenshot.

SupaVoxel’s dense overlay darkens the frame; the 213 problematic edges must be located in the mesh, not guessed from black pixels.

Does a watertight result solve the controller problem?

No. Watertightness lets me compute an enclosed volume; it does not tell me whether a joystick slips between the fingers, whether a fingertip will snap, or whether the rock base falls forward. At that normalized 120 mm scale, Hyper3D measures 66.46 × 120 × 52.60 mm overall. SupaVoxel measures 64.35 × 120 × 65.82 mm. The larger SupaVoxel depth includes the rock and hand; neither figure is an opening. If I were paying a printer, I would first name a particular controller and measure a contact envelope against it. Then I would choose material, inspect local thickness, slice an oriented model and try a physical prototype. None of those things happened in this review.

Hyper3D’s 52.60 mm overall depth at the chosen normalization is not a cradle measurement.

SupaVoxel’s 65.82 mm depth includes the rocks and hand, not proven space for a gamepad.

Could I at least estimate supports or resin?

Only with explicit caveats. Treat world Y as up; flag every triangle whose normal points within 45 degrees of down; scale each longest bounding-box side to 120 mm. That gives 2,573.1 mm² of potential downward-facing surface for Hyper3D and 3,016.0 mm² for SupaVoxel, or 15.58% and 15.96% of their respective total surfaces. It is not slicer-generated support, and rotating either sculpture changes it. Only Hyper3D’s validated closed solid supports a meaningful volume estimate: 80.76 cm³. At an assumed $35 per liter of solid-fill resin, that is $2.83 before supports, waste, failed prints or labor. SupaVoxel gets no resin quote here because its mesh is not a valid closed solid. I would rather leave a price blank than send a maker a false precision.

An overhead view can show a silhouette, not whether the rock base will stay upright with a controller on it.

What did SupaVoxel get right besides polygon count?

A count alone is easy to sell. I also inspected a mesh-health detail that goes against Hyper3D: it has 388 sliver faces, while SupaVoxel has 45 under the same elongated-triangle criterion. SupaVoxel has one degenerate face where Hyper3D has none, so the cleaner sliver row is not a blanket health win. Visually I prefer the more articulated fingers and uneven rocks in SupaVoxel’s hero and rear views; the back is an interpretation because the original picture shows only the palm. A sculptor can pick the completion they prefer, but neither tool reconstructed an unseen photograph. This is why my digital-sculpture preference favors SupaVoxel while my first-pass print-solid recommendation does not.

Hyper3D inferred a smoother dorsal hand from an image that did not show the back.

SupaVoxel’s inferred grooves and nail-like forms give an artist more rear-view texture, not verified anatomy.

What does Hyper3D fairly win?

The unrepaired mesh-screening contest. One welded watertight face-connected solid, no bad edge incidence, consistent winding. For someone who only wants the earliest candidate for a physical print, I would take that result and work from it. Its downloadable 13.10 MB PBR file is also smaller than SupaVoxel’s tested 31.77 MB GLB, though the Hyper3D website actually transfers a 20.39 MB ZIP. The exchange rate is plain: I give up some of the palm and rock relief I liked on SupaVoxel, but I avoid the repair-and-retest obligation imposed by 213 nonmanifold edges. Even then, 388 slivers deserve local inspection and no mesh test has answered the controller-fit question. “Cleaner shell” is the most I can say, not “ready to sell.”

The textured Gen-1.5 sculpture is the sounder unrepaired solid candidate in this one pair.

Which result would I take tomorrow?

For a close-up digital concept of a hand-and-rock stand, I would take SupaVoxel and reserve editing time for its topology. Its exported sculpture is richer at the places I actually want to show; I can decide whether those details justify the file weight only after seeing my own target viewer. For a prototype that must reach slicing quickly, I would take the Hyper3D Gen-1.5 file, measure the exact controller and still print and load-test it. If neither route can survive those tests, I would redesign rather than declare either AI model a functional holder. Different next steps, different winners; this is an evidence-qualified preference, not an evasive tie.

Try the only fit test that would change this answer

Use SupaVoxel’s image-to-3D workflow with your own dimensioned controller concept if you want dense sculptural detail, then examine its exported mesh and repair and recheck it before making a print claim. Put the actual controller against a scale prototype. If it does not seat securely, the 952,876 triangles do not rescue the design. Conversely, if Hyper3D’s leaner surface suits your job and saves repair work, use it without pretending the valid solid alone proves load capacity. My preference is an invitation to run that real job, not a substitute for it.

How I measured this, and what I did not test

One matching 1,572,056-byte PNG, with internal preprocessing unmeasured; one SupaVoxel browser GLB and one Hyper3D Gen-1.5 PBR member extracted from its ZIP. The blocked Gen-2.5 attempt supplies no mesh. Paired renders used the same viewer, lighting, pitch and scale; Hyper3D used yaw 0° and SupaVoxel yaw 90° to align the subject, despite different native orientations. File topology was checked after seam welding. Each longest bounding-box side was independently normalized to 120 mm; $2.83 assumes 80.76 cm³ of solid-fill Hyper3D resin at $35/L. No slicer, print, actual controller fit, strength or image-rights clearance was tested. This comparison is a subjective digital-sculpture preference, not print certification.

Also in this series
Hyper3D Rodin Review 2026: 0.5 Credit Spent, Gen-2.5 File Blocked
Hyper3D 3D Hand Review 2026: The 20.39 MB Download Is a ZIP

Virlo in 2026: What It Is, What the API Costs, and a Python Starter

Greta Holt — Wed, 07 Oct 2026 03:12:42 +0000

A few months ago someone left a comment under a popular Virlo tutorial asking which part of Virlo the author had used: "comet/orbit/etc?" Nobody answered. If you go looking for Comet or Orbit today you'll find both labeled deprecated in Virlo's docs, which says a lot about how fast this product has moved since January.

I do data plumbing for a couple of small creator agencies. Virlo comes up in almost every planning call now, usually as "can we just pull this from Virlo?", so I spent some time reading the current docs end to end and wiring it into a scratch project. This is the write-up I wish I'd had: what Virlo is in October 2026, how the API bills you, a Python starter that tracks its own spend, and where I reach for something else.

Quick disclosure on that last part: Virlo is a discovery tool, and for the narrower job of watching what one named competitor posts on TikTok each week, I use Reachara. More on that split near the end.

So what is Virlo, exactly?

Virlo's homepage calls it social listening for TikTok, Reels and Shorts. In practice it's a large database of short-form videos (the homepage says 14.7M+ outlier videos) plus an AI layer that explains why they worked.

The core idea is the outlier: a video that beat its own creator's usual views. Their example is a creator who normally gets about 2.5K views and suddenly gets 2.8M. That video ranks above a big account having a normal week. It's the right instinct, because raw view counts mostly tell you who is already famous.

On top of that sit:

Content research agents. You describe a niche in a sentence, the agent writes search terms, and it pulls matching videos across TikTok, Instagram and YouTube, once or on a schedule.
Breakdowns. Hook, format and angle per video, plus a copilot called Vee that answers questions like "best hooks in my niche this week".
Outputs. Scripts, creative briefs, and reports exported as PDF, Excel, CSV or JSON.

The site also lists competitor tracking, Meta Ads Library research and audience insights read from comments.

The app and the API are separate products

This tripped up two people I work with, so it's worth stating plainly. The Virlo app is a subscription; the homepage lists Starter at $49/month (2,000 credits), Pro at $199/month (12,000 credits) and Enterprise from $499/month, each with a 7-day $0 trial. The Virlo API is separate, and you don't need an app subscription to use it. You add funds to a prepaid balance that never expires and pay per successful request.

The API lives at https://api.virlo.ai/v1 and authenticates with a bearer key that starts with virlo_tkn_. You need a balance before you can generate a key, and the key is shown once.

Here's what the calls I care about cost, from the billing docs:

Endpoint	What it returns	Price
`GET /v1/account/balance`	Your balance	Free
`GET /v1/trends/digest`	Today's 15 to 20 trending topics for a region	$0.25
`GET /v1/hashtags`	Top hashtags for a date range (max 90 days)	$0.05
`GET /v1/hashtags/:hashtag/performance`	One hashtag's video count, views, likes, comments	$0.05
`GET /v1/videos/digest`	Most-viewed videos of the last 48 hours	$0.25
`POST /v1/satellite/video-outlier`	Did this one video beat its creator's baseline?	$0.50
`POST /v1/agents`	A content research agent run	$0.50, or $1.50 with Data Intelligence

Errors are free, and re-reading results you already paid for is free. Every successful response carries an X-Cost header with the exact charge in dollars, which is the single most useful thing in the whole API for anyone who has to explain a bill.

What happened to Orbit and Comet?

They were Virlo's older agent endpoints: Orbit for one-time research, Comet for recurring. Both now sit under "Legacy (deprecated)" in the docs, which point you to POST /v1/agents instead. One endpoint now covers both cases with an is_recurring flag. A one-time agent is charged when you create it; a recurring agent is free to create and charged $0.50 after each run. The rate-limit docs add that the old agent endpoints go as low as 2 requests per minute, while the replacement has the normal limit. If an older tutorial or your own code still calls /v1/orbit or /v1/comet, migrate it.

A Python starter that watches its own spend

This is the script I start every Virlo experiment from. It checks the balance (free), pulls today's US trends (25 cents), checks one hashtag (5 cents), handles 429s the way the docs describe, and adds up X-Cost so I know what the run cost.

import os
import time

import requests

API = "https://api.virlo.ai/v1"
HEADERS = {"Authorization": f"Bearer {os.environ['VIRLO_API_KEY']}"}
spent = 0.0


def get(path, **params):
    """GET a Virlo endpoint, honour Retry-After on 429, and tally X-Cost."""
    global spent
    for attempt in range(4):
        r = requests.get(f"{API}{path}", headers=HEADERS, params=params, timeout=30)
        if r.status_code == 429:
            time.sleep(int(r.headers.get("Retry-After", 2 ** attempt)))
            continue
        r.raise_for_status()  # 402 = balance too low, 404 = hashtag has no videos
        spent += float(r.headers.get("X-Cost", "0"))
        return r.json()["data"]
    raise RuntimeError(f"still rate limited on {path}")


print("balance:", get("/account/balance")["balance"])  # free

for group in get("/trends/digest", region="us", top_exemplars=0):  # $0.25
    print(group["title"], "| local_date:", group["local_date"])
    for item in group["trends"][:5]:
        status = (item["momentum"] or {}).get("status", "not measured yet")
        print(f'  {item["ranking"]:>2}. {item["trend"]["name"]} [{status}]')

tag = get("/hashtags/mealprep/performance",  # $0.05, no '#' in the path
          start_date="2026-07-08", end_date="2026-10-05")
print(f'#{tag["hashtag"]}: {tag["video_count"]} videos, avg {tag["avg_views"]:.0f} views')

print(f"this run cost ${spent:.2f}")

Set VIRLO_API_KEY in your environment and run it. Everything in the response lives under data, field names are snake_case, and momentum can be null until Virlo has measured a trend, hence the or {}.

Details that will bite you

These are all in the docs, but scattered across pages:

The daily trend list rolls over at 7:00 New York time. Call before that and you get yesterday's list, even if title says today. Check local_date, not title. Trends are added again at 13:00 and 19:00.
Hashtag ranges max out at 90 days, and stats start on 1 June 2024. A 91-day range returns a 400 with invalid_date_range.
Never put # in the path. A raw # breaks the URL; use the bare tag or %23.
There's no platform parameter on hashtags. For one platform, call /v1/tiktok/hashtags, /v1/youtube/hashtags or /v1/instagram/hashtags. Passing platform gets you a 400.
Top-hashtag lists aren't niche-specific, so fyp and shorts lead. For niche hashtags the docs point you to a content research agent.
count is Virlo's count, not TikTok's. It's how many videos in Virlo's data used the tag in your dates. Views freeze about a week after posting.
The outlier check charges every time. Creator, sound and hashtag lookups are served free from cache for 6 hours; the video outlier check isn't, and it's billed even if the check fails.
Rate limits are per key, per endpoint, resetting on the clock in UTC. Hashtag stats and trends allow 50 requests a minute; creator lookups and outlier checks only 5.

For AI-assistant workflows there's also an MCP server, which the developer site says exposes 46 tools to clients like Claude, Cursor and VS Code. I haven't moved anything to it yet, but it's the obvious next step for anyone already living in an agent.

Where I stop using Virlo

Virlo is excellent at the question "what's working in this niche right now?" It's less suited, at least for my clients, to "what did our competitor post on TikTok this week, and did any of it travel?" You can approximate it with tracking and agents, but you end up writing the glue: deciding which hashtags the competitor actually lives under, re-running, diffing.

That narrower job is what Reachara is built for. You name a competitor by website, @handle or hashtag; it infers up to 12 TikTok hashtags their videos run under, sweeps them on a schedule (weekly on the entry plan, daily above it), and ranks posts by plays divided by the posting account's followers. It's TikTok-only, it starts at $99/month for two monitored competitors with no free tier, and it doesn't do audience demographics or ad spend, which it says up front. For broad discovery, Virlo. For a fixed watchlist of rivals on TikTok, Reachara.

FAQ

Is Virlo free?
The app has a 7-day $0 trial, then starts at $49/month. The API has no subscription; you prepay a balance and most requests cost $0.50 or less. The balance check and re-reads of paid results are free.

Does Virlo have an API?
Yes, at https://api.virlo.ai/v1, with 25+ endpoints for trends, creators, hashtags, sounds, hooks and research agents, plus webhooks and an MCP server. Docs are at dev.virlo.ai.

What platforms does Virlo cover?
TikTok, YouTube Shorts and Instagram Reels, with the Meta Ad Library available inside research agents.

What replaced Virlo Orbit and Comet?
POST /v1/agents. Set is_recurring to false for what Orbit did and true for what Comet did.

Final notes

If you're evaluating Virlo for a team, start with the balance check and one trends call; the whole quickstart costs a quarter. Keep the API docs open, because the pricing table and rate limits are spelled out there more precisely than anywhere else. And if the real ask turns out to be "keep an eye on these three competitors on TikTok," look at Reachara before you build that pipeline yourself.