High-Poly vs. Low-Poly Models: A Production Decision Guide

A high-poly model carries more geometric detail than a low-poly model built for the same purpose. That comparison is useful, but the labels are relative rather than standardized. A 200,000-triangle shoe may be the lightweight version of a scan, an extravagant mobile-game prop, or a sensible hero asset in a desktop product viewer. Calling it “high poly” does not tell you whether it is appropriate.

The production question is which representation preserves the required image, motion, and interaction within a known delivery budget. That budget includes download bytes, decode time, GPU memory, vertex processing, draw submissions, animation cost, and the labor required to maintain the asset.

Three models often hide behind two labels#

A modern asset pipeline commonly has at least three geometric representations:

a source or sculpt model designed for editing and detail creation;
a render model with deliberate topology, UVs, materials, and deformation behavior;
one or more reduced delivery models for particular devices or viewing distances.

The source may contain 8 million triangles because it came from a sculpt, photogrammetry reconstruction, or CAD tessellation. It can hold pores, engraving, panel gaps, and manufacturing features without being suitable for real-time delivery. Its topology may be uneven, contain disconnected fragments, or lack usable UVs.

The render model might contain 80,000 triangles, a clean UV layout, tangent-space normal maps, and four material primitives. It is “low poly” relative to the source, but it may still be the highest level of detail shipped to a web viewer. A 20,000-triangle version and a 4,000-triangle distant version can share its material set.

Keep those roles explicit in filenames and metadata. Names such as chair_source.blend, chair_render_lod0.glb, and chair_render_lod2.glb are more useful than chair_high and chair_low_final2.

What geometry should preserve#

Geometry is valuable when it affects something the viewer can perceive or the runtime must calculate. Give priority to:

the outer silhouette against the background;
large changes in surface curvature;
open gaps and deep negative space;
contact points and intersections between parts;
features that cast distinct shadows;
deformation zones around joints;
collision shapes when they must follow the render mesh;
details wider than a few display pixels at the target view.

A normal map can change lighting across a surface but cannot change the silhouette. A painted black line can suggest a panel gap but will not create parallax when the camera moves. An alpha mask can cut a leaf outline but may add overdraw and sorting constraints. The right representation depends on what the feature must do.

Consider a 1-meter product shown at 900 pixels tall. A 2-millimeter bevel spans about 1.8 pixels before perspective and antialiasing. It may be barely visible and could be represented by a normal map. At a 2,700-pixel close-up, the same bevel spans roughly 5.4 pixels and can affect silhouette highlights enough to justify geometry. One asset can therefore need different answers for catalog thumbnails and an inspection mode.

Why raw polygon counts mislead#

Triangle count is a useful first measurement, but it is not a complete cost model. Two 100,000-triangle assets can behave very differently.

One may use a single indexed primitive with 62,000 rendered vertices and one 1024 × 1024 texture set. Another may be divided into 24 primitives, contain 140,000 rendered vertices after seams, and use six 4096 × 4096 texture sets. The second can require more CPU submission work, vertex bandwidth, and texture memory even though both report the same triangle total.

Count these quantities together:

triangles in the exported file, not only the authoring viewport;
rendered vertices after UV, normal, and material splits;
mesh primitives or draw-call candidates;
material and texture count;
texture dimensions, channels, and GPU formats;
skin influences and morph-target attributes;
compressed and decoded byte sizes;
peak memory during load;
frame time at representative camera positions;
visual error against the approved reference.

This inventory identifies the correct optimization. Removing 20,000 triangles will not solve a 64 MiB uncompressed color texture. Combining meshes will not help if it prevents useful culling and makes every frame draw hidden geometry.

The source-to-delivery workflow#

Preserve a non-destructive source#

Keep the original scan, CAD import, or sculpt separate. Apply scale and orientation conventions, name important parts, and remove obvious corruption, but do not destroy the only high-detail representation. A future close-up, print asset, or improved baking process may need it.

Define the delivery view before retopology#

Write down the smallest and largest projected size, camera distance, field of view, background contrast, animation requirements, and target hardware. “For web” is not a specification. “Interactive on mid-range phones, 600-pixel maximum height, 30 fps, under 3 MB transferred” is a usable starting point.

Build or generate render topology#

Manual retopology gives direct control over edge flow, deformation loops, and density placement. Automatic simplification is faster and often appropriate for rigid scanned objects. A hybrid workflow can automatically reduce broad regions, then manually repair the silhouette, joints, and material boundaries.

Avoid spending triangles uniformly. A flat underside that is never shown may need two triangles; a circular rim seen in profile may need dozens of segments. If a 32-sided cylinder looks faceted at the maximum view, 48 sides may be justified. If a 96-sided screw head occupies 12 pixels, it is not.

Create stable UVs and shading#

Unwrap the delivery mesh for the intended texel density. Mark hard edges where the surface should be discontinuous and coordinate those splits with UV seams when practical. Triangulate deterministically before baking if the baker and runtime might choose different diagonals.

The Blender glTF exporter documentation explains that supported mesh data is converted for glTF and that UV or normal discontinuities can increase exported vertex count. Inspect the exported result rather than assuming editing statistics equal delivery statistics.

Bake transferable detail#

Project information from the source onto the render model. Common bakes include:

tangent-space normal maps for fine surface direction;
ambient occlusion for controlled material use;
curvature or thickness masks used during texturing;
object-space normals for specialized pipelines;
displacement when the target renderer actually displaces geometry;
material IDs for texturing masks.

A bake needs an appropriate cage or ray distance. Too short misses recessed details; too long captures unrelated surfaces. Mirrored UVs, overlapping islands, inconsistent tangents, and differing triangulation can create seams. Test the normal map in the actual target runtime, because a clean baker preview is not sufficient evidence.

Validate the delivery artifact#

Export the GLB, run the Khronos glTF Validator, and compare it with the approved source under the target camera and lighting. Record both quality and performance measurements. For animated models, inspect extreme poses rather than only the bind pose.

Choosing a triangle budget from pixels#

Start with visibility instead of an industry folklore number. Capture the asset at the largest normal presentation size. Overlay a wireframe and ask where removing an edge changes a contour, highlight, or deformation by more than the acceptance threshold.

Suppose a mobile viewer renders at 1170 × 2532 pixels and a prop occupies at most 500 × 500 pixels. A fastener covering 6 × 6 pixels cannot reveal 500 triangles of modeled thread. Replacing 20 such fasteners could remove nearly 10,000 triangles with no measurable image loss. The main body, which controls hundreds of silhouette pixels, deserves a larger share.

Then benchmark several variants. For example:

LOD0: 96,000 triangles at the inspection view;
LOD1: 38,000 triangles for normal interaction;
LOD2: 9,500 triangles for thumbnails or distance;
billboard or impostor: 2 triangles for a fixed distant presentation.

Those ratios are hypotheses, not universal recommendations. Compare screen-space images, GPU and CPU frame times, load behavior, and transition artifacts. A model with transparent foliage or a costly shader can remain fragment-bound after major geometry reduction.

A decision record for each asset#

Write a short decision record beside the exported files. It should name the source revision, target devices, maximum projected size, triangle and rendered-vertex counts for each candidate, texture allocation, test scene, and reviewer. Add two or three annotated screenshots showing where a lower candidate failed. This turns “the artist thought 38,000 looked right” into evidence another person can reproduce.

For example, a chair might retain 42,000 triangles at LOD0 because the woven back is visible in a 900-pixel product close-up. A 17,000-triangle candidate passes at the normal 450-pixel view but loses three silhouette openings when enlarged. The team can ship both, choose the version from camera policy, and revisit the decision if the viewer later adds deeper zoom. Without that record, a future optimizer may remove the useful version or spend days rediscovering the threshold.

Also record alternatives rejected for non-geometric reasons. Replacing the weave with alpha-masked cards might reduce triangles by 80% yet increase overdraw, produce poor shadows, and fail from side angles. Baking it to a flat normal map might be adequate for thumbnails but unacceptable in WebXR. Optimization is a comparison among representations, not a contest to reach the smallest triangle total. That evidence also makes a budget enforceable in automated asset checks rather than dependent on memory.

When high detail is appropriate#

Retain more geometry when:

the user can inspect the object at close range;
the silhouette contains many real curves or perforations;
deformation would expose faceting or collapsing volume;
accurate shadows or reflections are part of the product experience;
the asset is rendered offline or on controlled high-end hardware;
source geometry is required for future baking and derivatives.

Even then, organize the source. Millions of accidental internal faces, duplicate shells, and invisible scan fragments are not artistic detail. Clean component separation makes later reduction safer.

When a lower-detail mesh is better#

Choose an aggressively reduced representation when the object is small on screen, repeated many times, delivered over constrained networks, or processed on thermally limited devices. Repetition multiplies cost: a 12,000-triangle prop instanced 100 times asks the GPU to consider 1.2 million triangles before culling details. A 3,000-triangle version reduces that geometric input by 75%.

Low poly should not mean careless. A strong low-detail asset has intentional silhouette edges, consistent shading, compact materials, sufficient UV padding, and tested deformation. It can be more technically sophisticated than the dense source because every remaining element has a reason to exist.

Common pipeline failures#

Reducing before defining the target. The team cannot judge acceptability without a view, device, and quality threshold.

Baking before topology is stable. Editing triangulation, UVs, or normals after baking changes the surface basis and can invalidate the normal map.

Keeping modeled and baked microdetail. Paying for both versions can create doubled shading and wastes geometry.

Treating decimation ratio as quality. A 50% setting describes removal, not perceptual success. Location matters.

Using viewport counts as shipped counts. Modifiers, triangulation, seams, flat normals, and exporter behavior can change the final totals.

Deleting the source. Destructive delivery optimization should never make future derivatives impossible.

Acceptance checklist#

Maximum and typical screen sizes are documented.
Triangle and rendered-vertex counts come from the exported asset.
Silhouette comparisons use production camera and resolution.
Important holes, gaps, and contact points remain geometric.
Normal-map detail matches target-runtime tangent space.
UV seams and hard edges do not create visible bake errors.
Material primitives are deliberate rather than source artifacts.
Static, animated, and extreme-pose views are reviewed as applicable.
Load time, decoded memory, and frame time meet stated budgets.
At least one lower-detail candidate was compared objectively.
LOD transitions do not pop at normal interaction speed.
The editable high-detail source remains archived separately.

Sources and further reading#

High poly and low poly describe a relationship, not a pass or fail state. A production-ready model is the least expensive representation that preserves the approved experience under measured delivery conditions.