Meshes

Core Idea

There are no curved surfaces on a GPU. Every sphere, face, and hillside is a mesh — vertices joined into edges joined into triangular faces — and the sphere above is the proof: hover it and the flashlight shows the mosaic it’s really made of. Slide the subdivision and watch the silhouette, not the surface: the shading is smooth at every level (the normals lie beautifully), but the outline stays polygonal until enough triangles buy it round. Smoothness is a budget, not a property.

Why the Triangle Is the Atom

Three points define exactly one plane — always, with no exceptions. Four points only sometimes do, and the demo below is what happens when they don’t:

Lift the corner: the quad must choose a diagonal to fold along, and the two choices are two genuinely different surfaces — different slopes, different centre, different lighting. A triangle never faces that decision, which is why it is the one primitive rasterization hardware consumes. Everything else is converted first: a quad splits into two triangles, an N-gon into N−2. (Artists still model in quads — edge loops flow predictably — but at export the mesh becomes triangles, and the winding order of each one decides which way it faces: the cross product’s story.)

A Vertex Is a Record, Not a Point

Each vertex carries everything the pipeline will later want per corner:

The surface between corners owns nothing — everything mid-triangle is interpolated from these three records. How the records actually live in memory — typed arrays, sharing corners through indices, the upload to the GPU — is the buffers story.

The Budget

Every triangle is transformed and rasterized every frame, so poly count is a permanent negotiation between smoothness and frame rate:

The craft is spending triangles only where they touch the silhouette — the one place the mosaic can’t be faked — and letting texture maps fake the interior detail (a normal map makes 1,000 triangles light like a million). Distant objects renegotiate the deal entirely via level of detail.

Where Meshes Come From

Procedural primitives (box, sphere, plane) are built by code at runtime; authored models arrive as GLTF/GLB files with their attributes and materials bundled. And underneath many of them sits mathematics one level up: parametric curves extended to surfaces P(u, v) — Bézier patches, NURBS, subdivision surfaces — which are evaluated down to a triangle mesh at some resolution before the GPU ever sees them. The mesh is always the last stop before rendering.

A newer source is generative tools — text or reference images in, a .glb with PBR maps out. The mesh-quality lens above is exactly how to judge the output: a generated model can be faithful to its reference and still fail production, because production-ready means topology that survives deformation, clean UV unwraps, and texture maps that aren’t baked flat — precisely the per-corner records and layout this article is about. That’s why the honest sweet spot for generated assets is background props: things that read from a distance, placed at LOD tiers, wearing their detail as textures rather than vertices. The judgment of which topology will fail is still a human skill; the tools don’t supply it.

Connections

The triangle’s flatness guarantee is what lets rasterization cover it with one cheap test per pixel, and each triangle’s facing comes from the cross product of its edges. The per-corner records feed normals to lighting and uv addresses to texturing; buffers explains how those records are packed and shared in memory. Smooth mathematical surfaces — curves and surfaces — sit upstream, waiting to be tessellated into the mosaic.