Checking Raw AI 3D Output: Triangle Counts, Topology and Watertightness

The four counts

• Triangles: faces after triangulation. Compare it to a declared budget (polycount calculator). A “quad” mesh still has to be counted this way. The glTF 2.0 specification’s primitive types are points, lines and triangles, Tripo’s docs say enabling quad forces FBX output, and Meshy’s rigging limit counts “a quad” as 2 triangles.
• Loose pieces: disconnected mesh islands. A solid prop should be one, or a number you can explain.
• Open edges: edges with a single adjacent face. Zero after welding is the standard for “watertight”; the trimesh library defines that as every edge being included in two faces. An edge shared by three or more faces also fails that rule without being a hole, which is why the audit records non-manifold edges too. Blender selects both kinds with Select > Select All by Trait > Non Manifold, in Vertex or Edge mode.
• UV islands: separate UV shells, counted with one consistent method. Very many islands usually signal wasteful unwrapping, not necessarily a defect.

The script and field definitions are on the prompt set page. Always audit the raw file first, before any cleanup, and archive it.

Why a GLB can report seams as holes

Open-edge counts are only comparable if every file was welded the same way. Blender’s glTF documentation says the format “requires discontinuous normals, UVs, and other vertex attributes to be stored as separate vertices”, and offers a Merge Vertices import option that “attempts to combine co-located vertices where possible” but “cannot combine verts with different normals”. So a UV seam or hard edge in a GLB can arrive as two separate rows of vertices at one position, and a script counting edges with one adjacent face can report that seam as an open edge. trimesh has the same choice in another form: merging runs when process is true, and merge_tex and merge_norm decide whether vertices with different UVs or normals are combined.

Record two numbers. Raw is the count as imported with no merge. Welded is the count after Mesh > Clean Up > Merge by Distance at a tolerance you state. Gate on the welded count and keep the raw one, because a large gap between them says seams were most of the problem. Comparing one tool’s raw count with another’s welded count is the easiest way to produce a false ranking.

What the sources document

Defaults. Settings rather than generators can explain part of a triangle-count difference, so log them. StraySpark’s September 25, 2026 article reported several defaults, and the primary pages confirm them with one addition: Meshy’s should_remesh is false for its other models but true for meshy-6-lite.

Tripo’s docs suggest 50,000 to 100,000 faces for “Game-ready assets” and 10,000 to 50,000 for web and mobile. That is one vendor’s guidance. The hard limit we can point to is platform-specific: Roblox says “Individual meshes can not exceed 20,000 triangles”.

Anecdotes, not rates. The same article cites a dev.to review (21 September 2026, reviewer unnamed) reporting a raw Tripo model of 1,911,270 faces and 1,012,219 vertices. It also reports that a Meshy file the author used most, measured in the author’s own testing for its MeshPrep tool, had 633 separate pieces and 35,842 open border edges; the Meshy model version is not given. These are single-file observations from a vendor of a mesh-cleanup add-on (MeshPrep). They show such outputs exist, not how often. The article does not say whether the open-edge count was taken before or after welding. Tripo’s developer site advertises H-series models “with up to 2 million polygons”, so a file near that size is inside the documented range rather than a malfunction.

Engine facts. Epic’s Nanite Technical Details page (UE 5.8) gives 14.4 bytes per input triangle as the average for its Valley of the Ancients sample, which the same article repeats as a general figure. Epic’s worked example is a 1,545,338-triangle asset at 19.64 MB with Nanite versus 148.95 MB as a standard static mesh with four LODs. One sample and one asset are illustrations, not a rate for generated meshes, and the figures concern Unreal only, not Godot or Unity.

Model-card caveats. The TRELLIS.2 model card says raw meshes may occasionally contain small holes or minor topological discontinuities, and the base model is not aligned with human preferences. Open-source output is therefore expected to need a check.

How to run the check

1. Run the prompts you care about from the standard set per tool, default settings, and a second pass at the lowest-triangle or remesh setting if offered.
2. Export the production format. Import it with merging off, avoid any step that could silently fix it, and run the metrics script for the raw counts. Then merge by distance at your stated tolerance and run it again.
3. Fill one row per output: tool, plan, model version, triangles, loose_pieces, open_edges_raw, open_edges_welded, weld_tolerance, nonmanifold_edges, degenerate_faces, uv_islands, maps_present, settings. The glTF specification says mesh geometry “SHOULD NOT” contain degenerate triangles, so a nonzero count is worth noting even when nothing looks wrong.
4. Compare each row against your gate, not against other tools. Group by prompt class; a prop and a tentacled creature should not share a threshold.

Reading the counts together

A single count rarely tells you what to do; the combination usually does. These are diagnostic readings to check on your file, not measured frequencies.

What the counts cannot see

Clean counts do not mean good topology. A mesh can be watertight, on budget and still deform badly, because edge flow around joints is not in any of these numbers. Unity’s character guidance describes the goal as a topology that “allows the model to move without distorting the mesh”, which no count captures. Blender can at least surface poles with Select > Select All by Trait > Poles by Count, and its manual warns that poles “can cause ugly pinching” under subdivision. For a static prop none of this may matter. For a character it decides the outcome, so read the character rigging checks as well. Counts also say nothing about silhouette or whether the mesh matches the prompt.

Pass or fail

For a solid game prop: one piece (or explained parts), zero open edges, triangles within your declared budget. For a Nanite target in Unreal, the triangle budget is generous but zero open edges and few pieces still matter. For printing the bar is stricter; use print-readiness beyond the slicer. The gap between what you measure and the gate is what hole and floater repair and retopology methods must close.

Unknowns

No public source we read gives per-generator defect rates across a set of prompts. Meshy publishes the nearest thing, and its two descriptions of it do not line up. Its comparison post (updated 27 October 2026; Meshy discloses it is one of the tools compared) reports a “97% slicer pass rate” on character and figurine models “across 75 models in Bambu Studio”, with 55% fully watertight straight out of export, and says the rest typically carry one to three small holes at detail endpoints that are “fixable in under five minutes or in-browser with auto-repair”. The method paragraph in Meshy’s printing post describes that benchmark as 75 models from five generators across ten image categories, analyzed in Materialise Magics and validated in Bambu Studio. So the 75 is not all Meshy, and the number of Meshy character files behind the two percentages is not stated.

The same figures show why a slicer result and a mesh count are different measurements. One Meshy post calls the 97% a “no-repair” pass rate; the other says “45% of its models still need a repair”. Both can hold if a slicer accepts files with small holes. A slicer pass tells you a file sliced, and print-readiness beyond the slicer covers what it misses. Treat Meshy’s numbers as claims to compare with, not a benchmark. Back to cleaning up AI 3D models.