Skip to main content
Mallory Scotton

Mallory Scotton

Founder of Graphical Playground
View all authors

Basic Mathematical Knowledge for Graphical Engineering

· 63 min read
Mallory Scotton
Mallory Scotton
Founder of Graphical Playground

A Principal Engineer's Foundational Guide to the Mathematics Underpinning Real-Time Rendering

"You cannot reason about a renderer you cannot derive. Every rendering technique, from a single rasterized triangle to a full path-traced reservoir resampling pipeline, is the application of three centuries of mathematics to the problem of moving photons from a virtual world into a human eye. Learn the math, and the engine becomes obvious."

Abstract​

Real-time computer graphics is, at its core, applied mathematics with a deadline. Every frame, the GPU executes billions of arithmetic operations whose correctness rests on a small set of foundational mathematical structures: linear algebra, projective geometry, calculus, probability, and signal processing. Yet the modern engine engineer is rarely taught these subjects in a unified, graphics-oriented form. Textbooks treat them in isolation; tutorials skip the derivations; production codebases hide them behind opaque utility functions. This paper attempts to close the gap. We present a comprehensive, self-contained survey of the mathematical knowledge required to build, debug, and reason about a modern AAA renderer, from the first vector dot product up to the rendering equation, Monte Carlo importance sampling, quaternion blending, and the numerical stability concerns that haunt every shader. We motivate each topic with its concrete graphical application, derive the formulas from first principles where it aids understanding, and provide reference C++23 implementations consistent with the conventions of the Graphical Playground (GP) Engine's in-house mathematics library. This document is intended both as a study reference for engineers entering the field and as the foundational curriculum on which all subsequent GP educational material will build.

Keywords: linear algebra, quaternions, projective geometry, rendering equation, BRDF, Monte Carlo integration, signal processing, color spaces, numerical stability, SIMD, real-time rendering, GP Engine

Engine Architecture and Directory Layout: A Principal Engineer's Guide

· 55 min read
Mallory Scotton
Mallory Scotton
Founder of Graphical Playground

A Comparative Survey of AAA Engine Source Trees and the Design Rationale Behind the Graphical Playground Engine

"Architecture is not the directory tree. The directory tree is the architecture made visible. Open any AAA engine and within thirty seconds you can read its philosophy off the file system."

Abstract​

Game engine architecture usually gets discussed in terms of subsystems: renderers, physics, audio, animation. But before any code is written, a more concrete question shapes everything: how is the source tree organized? Where does a piece of code physically live, what is allowed to depend on it, and what does that dependency mean at compile-time, link-time, and runtime? This paper takes a close look at directory layout as an architectural tool. We survey the publicly documented source trees of seven canonical engines, Unreal Engine 5, Godot, id Tech 4 / Doom 3, O3DE, Bevy, Unity, and Cocos2d-x, and the publicly documented architectural philosophies of five proprietary AAA engines, Frostbite (DICE/EA), Decima (Guerrilla Games), Anvil (Ubisoft Montreal), Snowdrop (Ubisoft Massive), and RE Engine (Capcom). We pull out a taxonomy of five layout strategies, weigh the trade-offs of each, and present the Graphical Playground (GP) Engine layout: a hybrid that borrows Unreal Engine's Public/Private/Internal discipline and reshapes it for educational clarity, multi-backend pluggability, and declarative CMake builds via our custom orchestration layer (GPBT). It closes with the complete GP Engine repository topology, module anatomy, and the rationale for every directory we ship.

Keywords: engine architecture, directory layout, module system, build system, CMake, GPBT, public/private boundary, RHI, plug-in architecture, monorepo, dependency visibility

Virtualized Geometry Systems: Architecture, Theory, and Implementation

· 41 min read
Mallory Scotton
Mallory Scotton
Founder of Graphical Playground

A Principal Engineer's Guide to Production-Grade Micro-Polygon Rendering

"The geometry problem is not one of bandwidth alone, it is a problem of indirection, coherence, and the fundamental mismatch between the triangle and the pixel."

Abstract​

Modern game engines face an intractable triangle throughput ceiling: GPU rasterizers are designed around polygons covering several pixels, yet cinematic assets routinely produce triangles smaller than a single pixel at runtime distances. Classical Level-of-Detail (LOD) pipelines fail at this scale due to popping artifacts, authoring overhead, and the inability to leverage the full spatial resolution of sculpted meshes. This paper covers Virtualized Geometry Systems (VGS), the family of techniques that includes Epic Games' Nanite (Unreal Engine 5), Ubisoft's micropolygon pipeline, and related academic precursors such as Reyes, Progressive Meshes, and Streaming Mesh systems. Topics include cluster-based hierarchical level-of-detail, screen-space error metrics, BVH/DAG visibility culling, software rasterization fallback paths, virtual shadow maps, and GPU-driven draw dispatch. Included is a concrete implementation blueprint targeting a C++23/Vulkan 1.3 engine, with pseudocode, data layout specifications, and complexity analyses.

Keywords: virtualized geometry, LOD, BVH, cluster hierarchy, software rasterization, meshlet, screen-space error, GPU-driven rendering, visibility buffer, nanite