“Low poly” and “high poly” are often treated as shorthand for asset quality. In real-time projects, that assumption rarely holds up. Assets with very low polygon counts can still perform poorly, while higher-density models can work perfectly well if they are built and used correctly.
This article is part of our broader asset workflow guides and focuses on how polygon density actually affects real-time performance when evaluating or buying assets.
Why Polygon Count Alone Is a Weak Metric
Polygon count is easy to measure, which is why it is often overemphasised. For early hardware and simpler engines, keeping triangle counts low was often the most direct way to maintain performance. That mindset still influences how assets are marketed and evaluated today. In practice, performance depends on several factors working together:
- Geometry distribution
- Asset repetition
- Material complexity
- Draw calls and batching
An asset with moderate polygon density but inefficient materials can perform worse than a more detailed asset built with clean topology and simple shaders.
Modern real-time engines, however, are far more complex. Performance is shaped by a combination of GPU workload, material complexity, draw calls, batching behaviour and memory usage. An asset with fewer polygons but multiple complex materials can be more expensive to render than a denser mesh using a single, well optimised shader. Focusing exclusively on polygon count for games can obscure the real sources of performance issues.
When Low Poly Assets Make Sense
Low poly assets remain essential in scenarios where performance margins are tight or where assets are used repeatedly across large scenes. Mobile projects, VR applications and large open environments all benefit from simplified geometry because they leave more headroom for lighting, post-processing and dynamic elements.
Low poly assets are particularly effective for background objects, secondary props and modular sets that are instantiated many times. In these cases, visual detail is often less noticeable than consistency and stability. This is why low poly approaches are common in real time game props and modular sets where reuse is more important than close-up detail, i.e. modular interior sets and industrial sets.
However, low poly should not be confused with careless. Assets still need clean topology, sensible edge flow and UV layouts that support efficient texturing. Poorly constructed low poly assets can introduce shading artefacts and visual noise that undermine their intended simplicity.
Typical Triangle Ranges for Low Poly Assets
In real-time projects, “low poly” usually describes assets whose geometry is appropriate for frequent reuse and mid-to-far viewing distances. As a rough guideline:
- Small props: hundreds to a few thousand triangles, i.e. 2-3 thousands
- Modular environment pieces: low thousands to low tens of thousands, i.e. valid for bigger modular architectural or structural assets
- Large background structures: simplified meshes with aggressive LODs
These ranges are not rules. The acceptable triangle count depends heavily on how often an asset is reused, how close it appears to the camera, the number of materials it uses and the target platform. A single asset’s cost is rarely the problem; cumulative cost is.
When Higher Density Assets Are Justified
Higher poly assets can work well when detail meaningfully contributes to the final result.
Common examples include:
- Hero props
- Vehicles and machinery
- Architectural focal points
- Simulation and visualisation projects
In these cases, adding geometry can reduce reliance on normal maps and improve how light interacts with the surface. This is especially relevant for curved objects such as vehicles, where overly simplified geometry can result in visible faceting and unrealistic reflections.
The key distinction is intent. Higher density should be used to support form and shading, not to add invisible detail. Geometry that does not affect silhouette, lighting or interaction rarely justifies its performance cost.
Level of Detail Changes the Low vs High Poly Question
Level of Detail (LOD) systems are one of the main reasons the low poly versus high poly debate is often oversimplified. In modern real-time engines, assets are rarely rendered at a single level of complexity. Instead, multiple versions of the same asset are displayed depending on distance from the camera.
A well-constructed asset may use higher polygon density for close-up views, then transition smoothly to simpler versions as distance increases. This approach allows projects to maintain visual quality where it matters while keeping overall performance under control.
From a practical standpoint this means that a “high poly” asset can still be perfectly suitable for real-time use if it includes sensible LODs. Conversely a low poly asset without LODs can become inefficient if it is visible across large areas or viewed from many distances.
Because LOD strategies vary significantly by engine, asset type and scene scale, they deserve separate consideration. We cover this in more detail in our dedicated guide to Level of Detail (LOD) workflows for game assets.
Normal Maps and the Illusion of Detail
Normal maps are often used to bridge the gap between low and high poly approaches. By baking detail from a dense mesh onto a simpler one, assets can appear complex while remaining relatively lightweight.
In real-time workflows, the success of this approach depends on execution. Poorly baked normal maps, inconsistent tangent spaces or mismatched smoothing can introduce artefacts that become obvious under dynamic lighting. In some cases, slightly increasing geometry density produces more stable and predictable results than relying heavily on baked detail.
For buyers, this means evaluating assets as complete packages. A low poly asset with well-authored normal maps may outperform a denser asset with poorly handled shading, but the opposite can also be true.
Reuse Multiplies Cost
One of the most overlooked aspects of polygon density is reuse. An asset that is acceptable when placed once may become problematic when duplicated dozens or hundreds of times. Small inefficiencies compound quickly in modular environments, interior scenes and large industrial layouts.
This is particularly relevant for environment assets and modular architecture,
where repetition is a core design principle. When evaluating assets intended for reuse, it is important to consider cumulative impact rather than isolated performance.
Game Engines Reward Consistency
Game engines differ in implementation, but they share common expectations. Assets with clean topology, reasonable density and predictable materials tend to behave well across engines such as:
Rather than optimising aggressively for a single engine, focusing on consistent real-time fundamentals usually yields better long-term results. Assets that follow these principles are easier to reuse across projects and engines without extensive rework.
What to Evaluate Before Buying Assets
When deciding between low poly and high poly assets, the most useful questions are contextual rather than numerical:
- How close will the asset be to the camera?
- How often will it be reused?
- Does its geometry meaningfully affect silhouette or shading?
- Are materials simple, consistent and PBR-correct?
- Does the asset match the target platform’s performance envelope?
Assets that answer these questions well tend to integrate smoothly regardless of how they are labelled.