game-rendering

name

game-rendering

description

You MUST consult this skill when reasoning about 3D rendering pipelines — coordinate spaces (model/world/view/clip/screen), perspective vs orthographic projection, affine transformations, triangle rasterization, barycentric coordinates, z-buffering, backface and frustum culling, UV mapping with perspective-correct interpolation, and lighting models (flat, Phong, multi-light blending). Also trigger when implementing a software renderer, debugging projection issues, or reasoning about what a GPU does internally. NOT for shader implementation in a specific engine (see godot-shader). NOT for art direction or visual legibility (see game-visuals). NOT for engine-specific renderer configuration.

3D Rendering Pipeline

Engine-agnostic reference for 3D rendering concepts: coordinate spaces, transformations, rasterization, visibility, texturing, and lighting. Synthesized from Marian Pekar's 3D Software Renderer in Odin from Scratch tutorial series (marianpekar.com).

Relationship to other skills: This skill covers the what and why of rendering math. For Odin/raylib implementation specifics, see odin-gamedev/references/raylib-rendering.md. For shader implementation in Godot, see godot-shader. For art direction and visual communication, see game-visuals. For diagnosing frame-rate and GPU bottlenecks, see game-performance.

---

Pipeline Overview

A 3D renderer transforms geometry through a series of coordinate spaces before producing pixels. Each space has a distinct purpose; each transition is a matrix multiplication.

  [Model Space]
       |
       | Model Matrix (T × R × S)
       v
  [World Space]
       |
       | View Matrix (camera transform)
       v
  [View Space]
       |
       | Projection Matrix (perspective or orthographic)
       v
  [Clip Space]
       |
       | Perspective Division (÷ w)
       v
  [NDC Space]   (-1 to +1 on each axis)
       |
       | Viewport Transform
       v
  [Screen Space]  (pixel coordinates)

Space	What it represents	Key operation
Model	Geometry relative to the object's own origin	Artist-authored mesh data
World	All objects in a shared coordinate system	Model matrix positions/orients the object
View	World seen from the camera's perspective; camera at origin	View matrix inverts the camera transform
Clip	Homogeneous coordinates ready for clipping	Projection matrix encodes FOV, aspect, near/far
NDC	Normalized Device Coordinates; cube [-1,1]³	Divide x,y,z by w
Screen	Integer pixel coordinates	Viewport scale and Y-flip

See references/transformations.md for the full matrix forms and derivations.

---

Mesh Data

A mesh is the input to the rendering pipeline. At minimum it contains:

Field	Type	Description
vertices	[]Vector3	Positions in model space
normals	[]Vector3	Surface normals per vertex (unit vectors)
uvs	[]Vector2	Texture coordinates per vertex, range [0,1]
triangles	[]Triangle	Index triples into the vertex/normal/UV arrays

A Triangle stores three indices: one for each vertex, normal, and UV. This allows vertices to be shared between triangles (reducing memory) while allowing different normals or UVs at the same position (required at hard edges and UV seams).

OBJ file format (Pekar Part IX) stores exactly this structure: v lines for vertices, vn for normals, vt for UVs, f lines for faces with vertex/uv/normal index triples. Loading an OBJ means parsing these lines and building the arrays above.

---

Per-Frame Rendering Loop

The full pipeline, from scene data to pixels, runs once per frame:

// Per frame:
clear(framebuffer, background_color)
clear(zbuffer, 0)          // 0 = "nothing drawn"; 1/w convention (larger = closer)

for each model in scene:
    M = model.transform.matrix()         // T × R × S

    for each triangle in model.mesh:
        // 1. Transform vertices to view space
        v0_view = V × M × triangle.v0
        v1_view = V × M × triangle.v1
        v2_view = V × M × triangle.v2

        // 2. Backface cull (in view space)
        if is_backfacing(v0_view, v1_view, v2_view): continue

        // 3. Project to clip space, then NDC
        v0_clip = P × v0_view
        v1_clip = P × v1_view
        v2_clip = P × v2_view

        // 4. Frustum cull
        if outside_frustum(v0_clip, v1_clip, v2_clip): continue

        // 5. Perspective divide → NDC
        v0_ndc = v0_clip.xyz / v0_clip.w
        ...

        // 6. NDC → screen space
        v0_screen = viewport_transform(v0_ndc)
        ...

        // 7. Rasterize: fill pixels, Z-test, interpolate UVs/normals, shade
        rasterize_triangle(v0_screen, v1_screen, v2_screen, ...)

Each step is covered in the reference files. The key insight is that culling happens as early as possible — backface culling in view space, frustum culling in clip space — to avoid rasterizing geometry that produces no pixels.

---

Decision Tables

Perspective vs. Orthographic Projection

Criterion	Perspective	Orthographic
Objects shrink with distance	Yes — natural depth cue	No — parallel lines stay parallel
Typical use	3D games, first/third-person views	CAD, 2D-style 3D, isometric games
Depth stored as	Non-linear (1/z distribution)	Linear (clip.z; range [-1, +1])
UV interpolation	Must be perspective-correct	Affine interpolation is exact
Switch at runtime	Yes — swap projection matrix	Yes — swap projection matrix

Rule: Use perspective for any scene where depth perception matters. Use orthographic when you want to preserve scale across distance (e.g., strategy games, blueprint views).

Flat vs. Phong Shading

Criterion	Flat Shading	Phong Shading
Normal computed	Once per triangle	Per pixel (interpolated from vertices)
Visual result	Faceted, hard edges between triangles	Smooth gradients across surfaces
Performance cost	Low — one dot product per triangle	Higher — dot product per pixel
Best for	Low-poly stylized art, early prototyping	Smooth organic surfaces
Requires	Triangle normal	Per-vertex normals in mesh data

Culling Strategy

Technique	What it eliminates	Cost	When to apply
Backface culling	Triangles facing away from camera	Very low (one dot product)	Always in closed meshes
Frustum culling	Triangles outside the view volume	Low (bounding box test)	Always
Occlusion culling	Geometry hidden behind other geometry	Medium–high	Complex scenes with many overlapping objects

Note: Backface and frustum culling are nearly free and should always be enabled. Occlusion culling requires spatial data structures and is out of scope here.

---

Key Invariants

Handedness consistency. Pick right-handed or left-handed coordinates and stay consistent throughout the pipeline. Mixing conventions causes mirrored geometry or inverted depth. Right-handed is the mathematical convention (OpenGL, Vulkan default); left-handed is common in Direct3D. The view matrix construction and projection matrix signs depend on this choice.

Perspective division. After the projection matrix, clip-space coordinates are in homogeneous form (x, y, z, w). Dividing by w gives NDC. This division is what makes distant objects appear smaller — the projection matrix encodes distance into w.

Store 1/w for perspective-correct interpolation. Linear interpolation in screen space is only correct for attributes that are linear in screen space. Depth and UV coordinates are not linear in screen space after perspective projection — they are linear in view space (before projection). What is linear in screen space is 1/w, U/w, and V/w. Storing 1/w (the reciprocal of clip-space w) and interpolating it linearly in screen space, then dividing back, gives perspective-correct results. This is why the Z-buffer stores 1/w rather than the raw view-space depth.

Winding order determines front faces. Counter-clockwise (CCW) winding is front-facing in right-handed systems. Backface culling depends on this convention being consistent across all meshes.

Model matrix order: T × R × S. Translation, then rotation, then scale. Applied right-to-left to a vertex: scale first, then rotate, then translate. Changing this order produces different results — scale after rotation causes shearing.

---

Common Bugs — Symptoms → Cause

Symptom	Likely Cause	Reference
Texture looks like it slides or distorts as the triangle rotates	Affine UV interpolation — not dividing by w	references/texturing.md
Pixels overdraw incorrectly; wrong geometry appears in front	No Z-buffer, or depth test direction reversed	references/visibility.md
Back faces of mesh are visible	Backface culling disabled or winding order inconsistent	references/visibility.md
Model disappears when camera gets close	Near-plane clipping not handled; geometry behind near plane projects incorrectly	references/visibility.md
Model looks inside-out or mirrored	Coordinate system handedness mismatch	references/transformations.md
Projection looks wrong (too wide, too narrow, stretched)	Incorrect aspect ratio in projection matrix, or FOV in wrong units (degrees vs radians)	references/transformations.md
Lighting is always maximum or always zero	Normal not normalized after interpolation, or dot product not clamped to [0,1]	references/lighting.md
Flat-shaded triangles show seams at edges	Expected — flat shading is per-triangle; switch to Phong for smooth surfaces	references/lighting.md
Z-fighting (flickering between two surfaces)	Two surfaces at nearly identical depth; Z-buffer precision insufficient	references/visibility.md
Triangle rasterization has gaps or double-drawn edges	Incorrect scanline bounds; off-by-one in FTFB split	references/rasterization.md

---

What's Not Covered Here

These topics are out of scope for this skill. They are mentioned only to orient you toward the right resource.

Topic	Where to look
Specular highlights (Blinn-Phong, Phong reflection model)	godot-shader/references/lighting.md; external: learnopengl.com
Normal/bump mapping	godot-shader/references/lighting.md
Shadow mapping	External: learnopengl.com/Advanced-Lighting/Shadows
Anti-aliasing (MSAA, FXAA, TAA)	External: GPU vendor documentation
Physically-based rendering (PBR)	External: learnopengl.com/PBR
GPU pipeline stages (vertex shaders, fragment shaders, rasterizer hardware)	godot-shader; external: Khronos OpenGL specification
Post-processing effects	godot-shader/references/vfx-and-postprocessing.md
Texture filtering (bilinear, trilinear, anisotropic)	External: GPU documentation
Spatial data structures for occlusion	External: game-engine-specific documentation

---

Worked Example: Tracing One Vertex Through the Pipeline

To make the coordinate space transitions concrete, here is a single vertex traced through each stage.

Setup: A cube vertex at model-space position (1, 1, 1). The cube is scaled by 0.5, rotated 45° around Y, and placed at world position (0, 0, -5). The camera is at the origin looking along -Z. FOV = 90°, aspect = 1.0, near = 0.1, far = 100.

// Model space
v_model = (1, 1, 1, 1)

// World space (after model matrix: scale 0.5, rotate 45° Y, translate (0,0,-5))
// Scale: (0.5, 0.5, 0.5)
// Rotate 45° Y: x' = 0.5*cos45 + 0.5*sin45 = 0.707, y' = 0.5, z' = -0.5*sin45 + 0.5*cos45 = 0
// Translate (0,0,-5): (0.707, 0.5, -5.0)
v_world = (0.707, 0.5, -5.0, 1)

// View space (camera at origin looking along -Z; view matrix is identity here)
v_view = (0.707, 0.5, -5.0, 1)

// Clip space (after perspective projection, FOV=90°, f=1/tan(45°)=1.0, aspect=1.0)
// clip.x = f/a * x = 0.707, clip.y = f * y = 0.5
// clip.z = -(far+n)/(far-n)*z - 2*far*n/(far-n) ≈ 4.805
// clip.w = -view.z = 5.0
v_clip = (0.707, 0.5, 4.805, 5.0)

// NDC (divide by w=5.0)
v_ndc = (0.141, 0.1, 0.961, 1)

// 1/w stored for depth and perspective-correct interpolation
inv_w = 1 / 5.0 = 0.2

// Screen space (800×600 viewport)
screenX = (0.141 * 0.5 + 0.5) * 800  ≈ 457   // right of center
screenY = (-0.1  * 0.5 + 0.5) * 600  = 270   // Y flipped; slightly above center

The vertex lands at approximately (457, 270) — right of center and slightly above the horizontal midline, which is correct for a vertex that is offset to the right and slightly above the camera's line of sight.

Key observations from this trace:

• The w component after projection equals the negated view-space z (-(-5.0) = 5.0)
• 1/w = 0.2 is stored for depth testing and perspective-correct UV interpolation
• The Y-flip in the viewport transform accounts for the screen's top-left origin
• The x-offset from rotation (0.707 world units) is visible in the final screen position (457 vs center 400)

---

References

File	Contents	Read when...
references/transformations.md	Coordinate spaces, all transformation matrices, view matrix construction, projection matrices, NDC→screen	You need matrix math, projection formulas, or are debugging coordinate space issues
references/rasterization.md	FTFB triangle rasterization, line drawing, barycentric coordinates	You're implementing a rasterizer or need to interpolate per-vertex attributes
references/visibility.md	Z-buffer, backface culling, frustum culling	You need depth testing or culling logic
references/texturing.md	UV mapping, texture sampling, perspective-correct interpolation	You're applying textures to triangles
references/lighting.md	Flat shading, Phong shading, multi-light blending, ambient/diffuse	You're implementing a lighting model

---

Relationship to Other Skills

godot-shader — Implements rendering concepts as GDSL shaders in Godot 4.x. When this skill explains the math (e.g., Lambertian diffuse), godot-shader provides the concrete .gdshader implementation. Use this skill to understand the concept; use godot-shader to write the code.

game-visuals — Art direction and visual communication: contrast, palette, legibility, simulation readability. This skill handles the rendering pipeline; game-visuals handles what the rendered image should communicate to the player.

game-performance — Diagnosing and fixing frame-rate problems: GPU bottlenecks, fill-rate, bandwidth, CPU submission overhead. This skill explains how the pipeline works; game-performance explains how to measure and fix it when it's too slow.

odin-gamedev — Odin/raylib glue patterns for custom rendering: the rl.Image software-framebuffer pattern, [^]rl.Color multi-pointer interop, power-of-2 texture sampling, and FPS overlay (see odin-gamedev/references/raylib-rendering.md). This skill covers the rendering math; Pekar's tutorial series at https://marianpekar.com/blog/software-renderer-in-odin-from-scratch-part-i is the complete worked implementation in Odin.

---

Further Reading

• Marian Pekar, 3D Software Renderer in Odin from Scratch (14-part series): https://marianpekar.com/blog/software-renderer-in-odin-from-scratch-part-i — a complete ground-up implementation covering every topic in this skill
• learnopengl.com — Comprehensive OpenGL tutorial covering the same pipeline concepts with GLSL shader implementations. Counterpoint: Jonathan Blow argues that funneling beginners straight to OpenGL is a mistake — it is long obsolete, recompiles shaders behind your back, and teaches wrong intuitions before you have the fundamentals to filter them.
• scratchapixel.com — Deep mathematical derivations of rasterization, projection, and shading from first principles

---

Learning Path & Philosophy (Jonathan Blow's view)

Where to start. Don't learn graphics on OpenGL (long obsolete; recompiles shaders behind your back; teaches wrong intuitions) or Vulkan (too low-level for fundamentals — you'll spend months on API ceremony before drawing a triangle). Start on a higher-level layer — raylib, SDL3, three.js — or by writing your own software renderer. The software renderer path is particularly effective: every concept in this skill becomes concrete and debuggable without a driver in the way.

What knowledge lasts. The durable knowledge is the math and algorithms — linear algebra, transforms, clipping, sampling, dithering — not any specific API. APIs change; the math doesn't. Investing in the math pays off across every renderer you'll ever touch.

Math prerequisites. The core requirement is linear algebra: matrices, eigenvectors, SVD. There is almost no calculus in game programming — a physics engine is the rare exception. "Working with vectors" is linear algebra, not vector calculus; don't let the name mislead you into thinking you need a calculus background first.

Rendering philosophy. All real-time computer graphics is hacky approximations of a correct answer that is too expensive to compute. The craft is choosing the hack that fits your game. A hyper-specific hack that no one else would use — one tuned to your art style, your scene complexity, your target hardware — can pay off far better than a general-purpose solution. Don't be embarrassed by the hack; be precise about what it trades away.