tripo Glb Viewer export review

Readers evaluating 3D files in a glb viewer can use this comparison to see whether Tripo and SupaVoxel preserve the knitted tray’s relief as geometry, how their texture assets differ, and what the export sizes mean for viewing and downstream use.

cover

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

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

The question on this tray was whether Tripo or SupaVoxel was faking the cable knit with a normal map on a smooth shell — because if either were, you would print a bald tray. Neither is. The untextured mesh renders, which load no texture at all, show the full cable relief on both sides, and both back silhouettes are scalloped stitch by stitch, which a normal map physically cannot do. Both files also ship a normal map on top of that real displacement: Tripo a 4096 PNG at 4.72 MB, SupaVoxel a 2048 WebP at 144 KB. So nobody prints a smooth tray, and the story is relief quality, not relief presence — and on quality Tripo wins. Tripo keeps three distinguishable stitch languages on the rim; SupaVoxel smooths the cable into fat tubes and flattens the grounds into soft ridges. Tripo's price for that: 63.61 MB against 5.71 MB, 11.1×.

Knit is real displaced geometry — Tripo yes · SupaVoxel yes · neither faked it
Distinguishable stitch languages on the rim — Tripo 3 (braided cable, seed ground, 1×1 rib) · SupaVoxel 1 smoothed cable + soft ridges · Tripo wins, plainly
GLB size — Tripo 63.61 MB · SupaVoxel 5.71 MB · 11.1×
Bytes per triangle — Tripo 33.38 B · SupaVoxel 5.87 B · 5.7×
Texture a slicer actually reads (baseColor) — Tripo 3.07 MB 4K JPEG · SupaVoxel 0.34 MB 2048 WebP · 9.0×
Texture a slicer never reads — Tripo 6.27 MB · SupaVoxel 0.28 MB · 22.6×
Normal map alone — Tripo 4.72 MB PNG · SupaVoxel 144 KB WebP · 32.8×, on relief that is already geometry
First load on 12 Mbps mobile — Tripo 42.4 s · SupaVoxel 3.8 s · 11.1×

Five things that decide this case:

SupaVoxel loses the surface here, and it is not a rounding error. Tripo's rim resolves braided cable with visible plies, a seed/moss field between the cables, and a fine 1×1 rib you can count column by column. SupaVoxel renders the cables as smooth fat tubes and the rib field as soft parallel ridges.
Tripo bought that with 2.0× the triangles — 1,905,766 against 971,646 — and 0.2384 mm mean edge against 0.3333 mm. On dense repeating relief that converts. On most subjects it would not.
Tripo also bought it with a texture policy unrelated to the knit: three uncompressed 4096 maps totalling 9.35 MB, 6.27 MB of which no slicer reads, against SupaVoxel's three 2048 WebPs at 0.62 MB.
That single 4.72 MB PNG normal map is 83% of the entire SupaVoxel GLB — decoration on top of relief that is already displaced geometry.
Neither model invented anything. Both extended the knit onto the back of the rim, which the photo never showed, and neither produced fake lettering or a maker's mark.

Judging the printed stitch layer on one tray, take Tripo's file. If the tray is going on a web page, into a viewer, or anywhere 63.61 MB per asset is a number someone reads, take SupaVoxel's — the exchange rate is at the end.

The input both tools saw

The single input: a 1,794,081-byte PNG, sha256 ae8f6d6a…, one off-white round tray, low rim, two punched-through handles, cable-and-rib knit over the whole surface. A three-quarter top view, so the underside and the back of the rim exist in neither tool's evidence — which is why the back renders below matter.

The stress test: strip every texture and see what is left

The SupaVoxel mesh with no textures loaded at all. The cables, the bead columns and the braided rows across the floor are all still there, so this knit is real displaced geometry*. The failure mode is in the same frame: with no texture, the cables read as smooth tubes where Tripo's still read as braid.*

Tripo's mesh at the same camera, also untextured. Same answer — real geometry — but the seed field and the fine rib are still distinguishable with no texture at all.

This is the whole reason I ran the case, and the tempting story turned out false. Nobody normal-mapped a bald tray. Both tools displaced the mesh, both ship a normal map anyway, and it sits on top of the displacement rather than instead of it.

Relief present in the untextured mesh — Tripo yes · SupaVoxel yes · neither faked it
Normal map also shipped — Tripo 4096 PNG 4.72 MB · SupaVoxel 2048 WebP 144 KB · cosmetic on both
Who wins the relief — Tripo, on stitch legibility · shown at 1:1 two sections down

Front, same camera, same light

SupaVoxel, yaw 90 so both handles sit left and right. The rim cables are smooth fat tubes crossing a dense field of fine bead columns. The crossings read; the plies inside each strand do not. The bottom silhouette of the rim is a near-smooth arc with a faint ripple.

Tripo at the same camera. Three stitch types on one rim: braided cable with the plies visible inside each strand, a seed/moss field between the cables, and countable 1×1 rib columns. The bottom silhouette is bumpy stitch by stitch, not an arc.

Both handles are genuine through-holes on Tripo's model and on SupaVoxel's, so neither took the easy way out on the hard part of the shape.

Back: the face neither tool was shown

SupaVoxel from behind, a surface that does not exist in the input. No invented decoration: the same cable-and-bead language continues around, with a through-hole at each end. What it did do is repeat — the back is more uniform than the front and several cable crossings do not line up. The outer floor silhouette is a near-smooth arc.

Tripo from behind. Tripo continued the knit too, and harder: the seed field and the fine rib are both still there, and the outer floor silhouette is a ring of sawteeth, one bump per stitch.

Neither model hallucinated text, a logo or a stamp onto the unseen face. On invention the two are tied; on resolution they are not.

The one-to-one crop where SupaVoxel loses

The SupaVoxel rim at 1:1. Two things are true at once. The relief is real — both silhouettes of the rim break up, and a normal map cannot cut a silhouette. And the stitch languages collapsed — four smooth fat tubes interlacing with no plies on them; where the seed field should be, a line of smooth beads; where the 1×1 rib should be, soft ridges you cannot count.

Tripo at the same crop: every ply inside every cable strand, individual seed bumps between the cables, countable rib columns on both sides, and a bottom edge that is sawtoothed stitch by stitch. This is where the 2.0× triangles and the 0.2384 mm mean edge cash out.

This is SupaVoxel's loss, stated where it happened rather than filed under regrets. Tripo did not waste those triangles here: a knitted tray is one of the few subjects that can absorb that density, and it absorbed it.

Triangles — Tripo 1,905,766 · SupaVoxel 971,646 · 2.0×
Mean triangle edge at 120 mm — Tripo 0.2384 mm · SupaVoxel 0.3333 mm · Tripo 1.68× finer than a 0.4 mm nozzle, SupaVoxel 1.20×
Both far finer than the ~4 mm cable pitch — so this is a modelling difference, not a resolution limit on either side

One thing worth correcting before anyone extrapolates: Tripo's triangle count is not a response to knit density. Across the nine other objects I ran, Tripo emits 1,896,372–1,996,779 triangles whatever the subject — a 5.2% spread, a fixed house budget. SupaVoxel's varies with the subject, 945,492 to 2,786,054, a 146% spread; on an armoured vehicle it emitted 44% more than Tripo. There is no ceiling on the SupaVoxel side. Here it chose the lower number, and here that cost it the rim. Ten objects is a sample, not a law.

Where the 63.61 MB actually goes

Tripo's export dialog. Texture Resolution defaults to "4k Current", and that default is most of the file. Three fields, no face count, no LOD, no line saying what this will weigh. The auto-filled name is "woven basket 3d model" — Tripo classified a knitted tray as a woven basket.

baseColor — Tripo 3.07 MB, 4096 JPEG · SupaVoxel 0.34 MB, 2048 WebP · 9.0×
Everything else (metallicRoughness + normal) — Tripo 6.27 MB · SupaVoxel 0.28 MB · 22.6×
Normal map alone — Tripo 4.72 MB PNG · SupaVoxel 144 KB WebP · 32.8×
All textures — Tripo 9.35 MB across three 4096 maps · SupaVoxel 0.62 MB across three 2048 maps · 15.1×
Geometry compression — SupaVoxel EXT_meshopt_compression + KHR_mesh_quantization · Tripo none (it declares KHR_materials_volume and FB_ngon_encoding)

A slicer reads baseColor and nothing else, so 6.27 MB of Tripo's download — 22.6× the SupaVoxel equivalent — is bytes a printing user fetches and discards. The 4.72 MB PNG normal map alone is 83% of the entire SupaVoxel GLB, describing relief that is already in the mesh.

SupaVoxel's baseColor is half the resolution, 2048 against 4096 — the one texture row where Tripo's extra bytes buy something real. They buy tinting, not stitch detail; the stitches live in the geometry, which is where SupaVoxel lost this case.

Bytes per triangle: 5.87 against 33.38

GLB size — Tripo 63,609,736 B · SupaVoxel 5,707,056 B · 11.1×
Bytes per triangle — Tripo 33.38 B · SupaVoxel 5.87 B · 5.7×
Triangles — Tripo 1,905,766 · SupaVoxel 971,646 · 2.0×

The file gap is 11.1× while the mesh gap is only 2.0×, and the difference between those ratios is entirely encoding policy. Tripo ships uncompressed geometry and uncompressed 4K images; SupaVoxel ships meshopt-compressed, quantised geometry and WebP. Per triangle Tripo costs 5.7× more to move, and none of that 5.7× is about how good Tripo's tray looks.

What it costs to open this in a browser

12 Mbps mobile, first load — Tripo 42.4 s · SupaVoxel 3.8 s · 38.6 s saved
100 Mbps home, first load — Tripo 5.09 s · SupaVoxel 0.46 s
CDN at $0.085/GB, 10,000 loads/month — Tripo $54.07 · SupaVoxel $4.85 · $49.22/month, $590.60/year
Geometry VRAM — Tripo 54.3 MB · SupaVoxel 27.7 MB · 26.5 MB saved
100 assets downloaded — Tripo 6.36 GB · SupaVoxel 0.57 GB

A 42-second first load is not a slow product page, it is a page without a 3D preview. And this is exactly where Tripo's rim detail stops paying: shrink the tray to a product-page viewport and Tripo's 2.0× triangles is close to invisible. The visitor waits 38.6 seconds longer and sees almost the same tray.

The relief is checkable before you download it — on one side

SupaVoxel's Wire view, inside the browser: the cables, the floor braids and the rim ribs all appear in the mesh itself. The "real geometry or painted fake?" question answered before a single byte is downloaded.

The same result page: Triangles 971,646 — matching the parsed GLB to the digit — millimetre dimensions you can flip to raw, a timestamped version, and Textured / Mesh / Wire / Normals one click apart.

Tripo's viewer has a textured model and a material strip. No wireframe, no mesh view, no normals view. On a subject whose entire value is surface relief, Tripo lets you inspect that surface as geometry only after you have paid, exported and downloaded 63.61 MB.

Tripo's viewport does not show the texture until after export

Tripo's textured mesh, which only appeared after export. The form is right — round tray, two punched handles, full-surface knit — the face-count readout is still half-hidden behind the Assets panel, and a promo banner ("Smart Mesh P2.0: Quads & Edit — Try For Free") still sits across the top.

What I did not measure

albedo ΔE — not captured, so no number on colour fidelity. Both trays read as the same matte off-white against the input; that is an eyeball claim, not a measurement.
UV chart occupancy — not captured.
The SupaVoxel export click count — not captured; that screenshot is byte-identical to the previous step. Tripo's is 2 steps, captured.
Full orientation alignment — partial. My probe ran 0/90/180/270 on Tripo but crashed the headless browser after 0 and 90 on SupaVoxel, so a finer off-axis angle was not ruled out here. Verified: at yaw 90 both SupaVoxel handles sit left and right and are visible, matching Tripo's yaw-0 framing, so every pair above is the same view of the same object.
Two wireframe zoom renders — discarded. At 971,646 and 1,905,766 triangles both render near-solid black at that focal length; I opened both to confirm genuine density rather than a blank frame, and neither is used as evidence.

Final verdict: Tripo scores 60/100

On the question I built this case to ask, both tools give the same answer: the knit is real displaced geometry, nobody faked it with a normal map, nobody prints a bald tray. On the follow-up — how good is the relief — Tripo wins outright, three legible stitch languages against a smoothed cable and soft ridges. A real loss for SupaVoxel, on a subject built entirely out of surface.

Then Tripo charges 63.61 MB for it: 6.27 MB of texture no slicer opens, 4.72 MB of that a single PNG normal map describing relief already in the mesh, uncompressed geometry, a 4K default buried in a dialog that never mentions size, and a file name calling a knitted tray a woven basket. SupaVoxel's file is 5.71 MB, meshopt-compressed and quantised, WebP throughout, and it loads on a phone in 3.8 seconds.

One run each, defaults — a sample of one per tool on this object. Every byte figure was parsed from the two downloaded GLB files, which is why you can check all of them yourself.

Which one I would use for this job

For a tray that has to live in a browser, a catalogue, an asset library or a batch, SupaVoxel is the file I would hand you: 5.71 MB against 63.61 MB, 5.87 bytes per triangle against 33.38, 3.8 s against 42.4 s on mobile, $58.20 a year of CDN against $648.80, 26.5 MB less VRAM, and real displaced knit geometry you verify in one click. Take Tripo if the printed stitch layer on one tray is the deliverable — Tripo's rim genuinely is better here, and I would rather show you the 1:1 crop than talk around it.

Originally published on Medium: Tripo GLB Export Review 2026: 63.61 MB for One Knitted Tray.