license: public domain CC0

[beware, there are errors in the following, it is just food for thought.]

Encoding Techniques (original version of the copy below)

Matrix (original version of the copy below)

Minimal 3D Game Asset Encoding Techniques

A comprehensive catalog of techniques for achieving the smallest possible 3D video game assets, inspired by demoscene practices. Each technique includes compatibility notes for building effective combinations.

Data Dynamism Spectrum (Immediate ↔ Retained)
Interactive Shader Development & Debugging
S-Expression Based Shader Language
Engine Compatibility Notes
Observed Patterns & Principles
Technique × Spectrum Compatibility Matrix
Hardware & Software Requirements
Offline / Online & Interactivity
Reference Appendix
Geometry Representation
Procedural Generation
Texture Techniques
Rendering Paradigms
Compression & Encoding
LOD & Streaming
Shader-Based Techniques
Animation Techniques
Lighting & Materials
Audio (Bonus)
Code Size Reduction

Data Dynamism Spectrum (Immediate ↔ Retained)

This section describes the fundamental axis of how static your data is - from fully retained (load once, GPU owns it forever) to fully immediate (CPU rebuilds everything every frame). This spectrum affects which techniques are compatible, where bottlenecks appear, and how debuggable your system is.

The Spectrum

RETAINED                                                          IMMEDIATE
(Static)                                                          (Dynamic)
    |                                                                  |
    |  D1  |  D2  |  D3  |  D4  |  D5  |  D6  |  D7  |  D8  |  D9  |  D10 |
    |      |      |      |      |      |      |      |      |      |      |
   GPU    GPU    GPU    GPU   Mixed  Mixed   CPU    CPU    CPU    CPU
  owns   owns   owns   drives        leans  drives builds  builds software
  world  scene  meshes render        CPU    GPU    GPU     all    renders
  graph  graph  only   cmds                 cmds   data    data   all

D1: Fully Retained World Scene Graph on GPU

Description: Entire world representation lives in GPU memory. GPU-driven rendering with minimal CPU involvement. Scene graph, transforms, visibility - all GPU-side.

Characteristics:

CPU uploads world once (or streams chunks)
GPU handles culling, LOD selection, draw call generation
Compute shaders manage scene updates
CPU mainly handles input and high-level game logic

Examples:

Nanite (UE5)
GPU-driven rendering pipelines
Modern AAA engines

Works well with:

G6 (Virtualized geometry)
L1 (GPU-selected LOD)
Massive static worlds
Persistent multiplayer environments

Does not work well with:

Rapid prototyping
Debugging (opaque GPU state)
Highly dynamic worlds
Simple projects (massive infrastructure)

Compression relevance:

Heavy compression worthwhile (amortized over long retention)
Streaming compression (Basis, Draco) makes sense
GPU-decodable formats preferred

Debugging characteristics:

Very difficult - state lives on GPU
Need GPU debuggers (RenderDoc, PIX)
Performance issues can be hidden/amortized
Hard to reason about what's actually happening

D2: Retained Scene Graph, CPU Transform Updates

Description: Scene graph and meshes retained on GPU, but CPU updates transforms each frame and manages object lifetime.

Characteristics:

Meshes uploaded once, retained
CPU maintains parallel scene representation
Transform matrices sent per-frame
CPU does visibility culling, sends draw calls

Examples:

Traditional game engines (Unity, older UE)
Most shipped games historically

Works well with:

G3 (Standard meshes)
Standard game logic
Reasonable dynamism
Established workflows

Does not work well with:

Extreme object counts (draw call limits)
Per-vertex animation
Procedural geometry

Compression relevance:

Mesh compression still valuable
Texture compression standard
Less pressure than D1 (more flexibility)

Debugging characteristics:

Moderate - can inspect CPU-side scene
Draw calls visible and countable
Transform issues debuggable
Still need GPU tools for rendering bugs

D3: Retained Meshes, Dynamic Materials/Textures

Description: Geometry stable, but materials, textures, or shader parameters change frequently.

Characteristics:

Mesh data static
Frequent uniform/constant buffer updates
Texture swapping or streaming
Shader parameter animation

Examples:

Games with dynamic weather/time of day
Material parameter animation
Texture streaming systems

Works well with:

T4 (Virtual texturing)
Dynamic lighting
Visual variety without geometry cost

Does not work well with:

Static baked lighting (conflicts with dynamic materials)
Extreme material counts

Compression relevance:

Texture compression critical (streaming bandwidth)
Mesh compression still applies

Debugging characteristics:

Moderate - geometry stable baseline
Material bugs more visible
Can diff against known-good state

D4: GPU-Driven with CPU Feedback

Description: GPU does heavy lifting but CPU reads back results for game logic (occlusion queries, physics readback).

Characteristics:

GPU generates visibility data
CPU reads back for AI, physics, gameplay
Latency-sensitive synchronization
Complex pipeline

Examples:

GPU occlusion culling with CPU readback
GPU physics with gameplay integration
Async compute patterns

Works well with:

Large worlds needing CPU-side knowledge
AI that needs visibility info
Complex gameplay systems

Does not work well with:

Low latency requirements (readback delay)
Simple games (complexity overhead)
Debugging (async timing issues)

Compression relevance:

Readback bandwidth matters
Compressed intermediate formats possible

Debugging characteristics:

Difficult - async timing issues
GPU/CPU sync bugs subtle
Need careful frame analysis

D5: Mixed Mode - Instanced Static + Dynamic Objects

Description: Static world retained, dynamic objects handled more immediately. Common practical compromise.

Characteristics:

Background/environment retained
Characters, items rebuilt/updated frequently
Clear separation of concerns
Hybrid data flow

Examples:

Most modern games
Open worlds with dynamic entities
Practical production approach

Works well with:

Most standard techniques
Reasonable performance
Flexible content

Does not work well with:

Fully dynamic worlds
Extreme consistency requirements

Compression relevance:

Static content: heavy compression
Dynamic content: lighter/faster compression

Debugging characteristics:

Moderate - can focus on one half at a time
Clear system boundaries help

D6: CPU-Driven Rendering, Retained Buffers

Description: CPU decides everything each frame but reuses uploaded buffer data. Traditional immediate-mode thinking with some retention.

Characteristics:

CPU builds command lists each frame
Buffers persist but CPU controls usage
Full CPU visibility into what's rendered
Explicit resource management

Examples:

Explicit APIs used "simply" (Vulkan/D3D12 without GPU-driven)
Older immediate-mode thinking with modern API
Teaching/learning graphics

Works well with:

Debugging (CPU sees everything)
Explicit control
Understanding what's happening

Does not work well with:

Extreme draw counts
Massive worlds
Full GPU utilization

Compression relevance:

Upload cost visible per-frame
Compression must be fast to decode

Debugging characteristics:

Good - CPU state fully inspectable
Can trace every decision
Performance costs visible and attributable

D7: Streaming Geometry (Partial Retention)

Description: Continuously stream geometry based on camera/player position. Hybrid retention with constant churn.

Characteristics:

Working set retained
Background streaming in/out
Memory budget management
Position-dependent loading

Examples:

Open world streaming
Flight simulators
Google Earth style

Works well with:

L5 (Streaming)
Massive worlds
Limited memory

Does not work well with:

Random access (teleportation)
Fast movement (pop-in)
Small contained levels

Compression relevance:

Streaming bandwidth critical
Progressive formats valuable
Decompression speed matters

Debugging characteristics:

Moderate - streaming adds complexity
Loading bugs hard to reproduce
Position-dependent behavior

D8: Per-Frame Geometry Generation (GPU)

Description: GPU generates geometry each frame via compute shaders. Data flow: parameters → compute → render.

Characteristics:

Minimal CPU upload (just parameters)
Compute shaders build vertex/index buffers
Marching cubes, procedural mesh, etc.
GPU-only intermediate data

Examples:

Voxel terrain (GPU marching cubes)
Procedural geometry
Particle mesh generation

Works well with:

P6 (Compute shader generation)
G4 (Voxels)
Highly dynamic geometry
Destructible environments

Does not work well with:

CPU physics on generated geometry
Traditional content pipelines
Debugging (GPU-only state)

Compression relevance:

Parameters compress well (tiny)
No mesh compression needed
Algorithm IS the compression

Debugging characteristics:

Difficult - geometry exists only on GPU
Need compute shader debugging
Can't easily inspect intermediate state

D9: Per-Frame Full Rebuild (CPU → GPU)

Description: CPU builds all render data every frame, uploads to GPU. True immediate mode.

Characteristics:

No retained geometry
Full CPU control and visibility
Upload bandwidth is the bottleneck
Every frame starts fresh

Examples:

Dear ImGui (2D)
Debug visualization systems
Prototyping
Some CAD/visualization tools

Works well with:

Debugging (perfect visibility)
Rapid iteration
Highly dynamic content
Simple mental model

Does not work well with:

Large data volumes
Performance-critical rendering
Complex meshes
Production games

Compression relevance:

Compression often counterproductive (decode cost)
Bandwidth to GPU is the limit
Simple formats preferred

Debugging characteristics:

Excellent - full CPU visibility
Every frame reproducible
No hidden state
Performance issues immediately obvious

D10: CPU Software Rendering

Description: CPU does all rendering, writes directly to framebuffer. Ultimate immediate mode.

Characteristics:

No GPU involvement
Full programmatic control
Single address space
Every pixel computed explicitly

Examples:

Demoscene software renderers
Embedded systems
Educational projects
Fallback renderers

Works well with:

Learning
Extreme control
No driver bugs
Deterministic rendering

Does not work well with:

Performance
Modern resolutions
Complex effects
Shipping games (usually)

Compression relevance:

Compression must be CPU-decodable
Memory bandwidth different constraints
May want uncompressed for speed

Debugging characteristics:

Perfect - everything in CPU memory
Can inspect any pixel's computation
Single-step through rendering
Print statements work

Why Immediate Mode Matters for Development

You noted preference for immediate mode for several reasons that are worth expanding:

1. Performance Transparency In retained mode, costs are amortized and hidden:

Uploading a 1M triangle mesh takes 50ms... but it happened 30 seconds ago
That spike in your profiler? Garbage collection of a released buffer from 3 frames ago
Draw call batching makes individual object costs invisible

In immediate mode:

Frame N's costs are incurred in Frame N
Profiler shows actual work being done NOW
No "well it was fast because it was cached" surprises

2. State Machine Clarity

// Retained mode question: "What is the GPU rendering right now?"
// Answer: Whatever combination of:
//   - Scene graph state (when was it last modified?)
//   - Pending uploads (are they done?)
//   - Cached command buffers (from when?)
//   - Material overrides (which are active?)

// Immediate mode answer: "Whatever I told it to render this frame."

3. Debugging Workflow

// Immediate mode debugging:
if (frame == 1234) {
    printf("About to draw object X at position %f,%f,%f\n", ...);
    // Set breakpoint here, inspect everything
}

// Retained mode debugging:
// "The object was uploaded at frame 100, 
//  its transform was last set at frame 1200,
//  the GPU is using command buffer from frame 1232,
//  the actual draw happens... somewhere in the driver"

4. Effect Implementation When implementing a new effect in immediate mode:

Write code that computes the effect
See result
Done

When implementing in retained mode:

Figure out where in the scene graph to hook
Determine what data needs caching
Handle invalidation when dependencies change
Manage lifetime of cached data
Actually write the effect
Debug why cached data is stale

5. Reproducibility Immediate mode: Same inputs → Same outputs (per frame) Retained mode: Same inputs → Different outputs (depending on history)

Immediate Mode Techniques Expanded

Since you want to expand on immediate mode, here are techniques that work well in that paradigm:

IM1: Ray Marching SDFs (Fully Immediate)

Each pixel independently computed from scratch. No retained geometry. Perfect immediate mode.

Implementation pattern:

// Every frame, every pixel:
for each pixel:
    ray = computeRay(pixel, camera)
    for steps in range(MAX_STEPS):
        p = ray.origin + ray.dir * t
        d = sceneSDF(p)  // Evaluate ENTIRE scene
        if d < EPSILON: shade and return
        t += d

Why it's immediate-friendly:

Scene defined by function, not data
No uploads, no buffers, no state
Change scene function → immediate visual change
Add object = add term to SDF function

IM2: Compute-to-Render Direct Pipeline

Generate geometry in compute, render same frame, discard.

Pattern:

Frame N:
  1. Dispatch compute (params → vertices)
  2. Barrier
  3. Draw generated vertices
  4. Discard vertex buffer (or ring-buffer reuse)

No retention, full regeneration each frame.

IM3: Uniform-Driven Procedural Geometry

Vertex shader generates positions from uniforms + vertex ID.

// No vertex buffer needed
vec3 position = proceduralPosition(gl_VertexID, u_time, u_params);

Upload: just uniforms (bytes). Geometry: computed.

IM4: Screen-Space Everything

If it can be computed in screen space, it's inherently immediate:

SSAO computed fresh each frame
Post-processing chains
Raymarched volumes
No geometry state, just pixels

IM5: Stateless Shader Uniforms

Instead of uploading mesh + transforms, upload:

Procedural parameters
Noise seeds
Time values
Mathematical definitions

Let shaders compute everything.

IM6: The "Fullscreen Quad + Math" Pattern

The most extreme immediate mode: render one quad, do everything in fragment shader.

// Entire 3D scene in fragment shader
void main() {
    vec3 ro = cameraPos;
    vec3 rd = normalize(rayDir(uv, cameraMatrix));
    
    float t = raymarch(ro, rd);
    vec3 p = ro + rd * t;
    vec3 n = calcNormal(p);
    vec3 col = shade(p, n, rd);
    
    fragColor = vec4(col, 1.0);
}

Data uploaded: Camera matrix, time, maybe a few floats. That's it.

IM7: Instanced Procedural Primitives

Draw N instances of nothing, generate everything from instance ID:

// "Mesh" is just instance count
// glDrawArraysInstanced(GL_TRIANGLES, 0, 36, 10000);  // 10000 cubes

void main() {
    int cubeID = gl_InstanceID;
    int vertexInCube = gl_VertexID;
    
    vec3 cubeCenter = proceduralPosition(cubeID, u_time);
    vec3 localPos = cubeVertex(vertexInCube);  // One of 36 vertices
    
    gl_Position = mvp * vec4(cubeCenter + localPos * scale, 1.0);
}

Uploaded data: Zero vertex buffers. Just uniforms and draw call.

IM8: Temporal Statelessness (No Frame Dependency)

Design rendering so frame N depends only on:

Current time
Current input state
Constant parameters

Not on:

Previous frame results
Accumulated buffers
History textures

This enables:

Jump to any frame instantly
Perfect reproducibility
No temporal artifacts from past errors

IM9: Parameter Space Exploration

Because immediate mode recomputes everything, you can:

Scrub time slider → see any moment
Tweak any parameter → instant result
No "rebuild" or "rebake" step

This is why ShaderToy is so effective for exploration.

IM10: Debug Injection Points

In immediate mode, you can inject debug visualization anywhere:

vec3 color = shade(p, n);

#ifdef DEBUG_NORMALS
    color = n * 0.5 + 0.5;
#endif

#ifdef DEBUG_DEPTH
    color = vec3(t / maxDist);
#endif

#ifdef DEBUG_ITERATIONS
    color = vec3(float(iterations) / float(MAX_STEPS));
#endif

No retained state to corrupt. Recompile shader, see debug view.

Immediate Mode Performance Patterns

Since immediate mode pays costs every frame, specific optimization patterns emerge:

IMP1: Hierarchical Early-Out

Instead of retaining a BVH, compute hierarchical bounds analytically:

float sceneSDF(vec3 p) {
    // Coarse bounds check (almost free)
    if (length(p - sceneCenter) > sceneRadius) return length(p - sceneCenter) - sceneRadius;
    
    // Check sub-regions
    float d = MAX_DIST;
    for (int region = 0; region < 8; region++) {
        vec3 regionCenter = ...;
        if (length(p - regionCenter) < regionRadius + d) {
            d = min(d, regionSDF(p, region));
        }
    }
    return d;
}

IMP2: Level of Detail via Iteration Count

In ray marching, distance = natural LOD:

// Far objects: fewer iterations automatically (larger steps)
// Near objects: more iterations (smaller steps near surface)
// LOD is emergent, not stored

IMP3: Resolution as LOD

Render at lower resolution, upscale. Immediate mode makes this trivial:

// Half res: every frame
// Full res: every frame
// No retained buffers to manage between modes

IMP4: Shader Complexity Budget

Fixed time budget per frame. In immediate mode, you control this directly:

if (technique_too_slow) {
    reduce MAX_STEPS;
    // or simplify SDF
    // or reduce resolution
    // Immediate feedback on cost
}

The Immediate Mode Development Loop

1. Write/modify shader code
2. Save file
3. Hot-reload shader (< 100ms)
4. See result
5. Repeat

Total iteration time: seconds

Compare to retained mode:

1. Modify scene graph code
2. Recompile application
3. Restart application
4. Wait for assets to load
5. Navigate to test location
6. See result
7. Repeat

Total iteration time: minutes

When Retained Mode is Actually Necessary

Despite the benefits of immediate mode, retained is necessary when:

Asset complexity exceeds real-time generation
- Photogrammetry scans
- Artist-authored detail
- Motion capture data
Performance requirements demand it
- 60+ fps with complex scenes
- Mobile power constraints
- VR latency requirements
Tooling expects it
- Content pipelines
- Level editors
- Team workflows
Network multiplayer
- Shared state must be synchronized
- Can't recompute from different random seeds

The key insight: Start immediate, retain when proven necessary.

Interactive Shader Development & Debugging

The current state of shader debugging is abysmal. You write code, compile, run, see wrong output, and then... stare at the code? Add return vec4(debugValue, 0, 0, 1) and recompile? This section explores better approaches.

The Problem with Current Shader Debugging

Current workflow:
1. Write shader
2. Compile (hope for no errors)
3. Run application
4. See wrong output
5. Guess what's wrong
6. Add debug output (return color = normal, etc.)
7. Recompile entire application
8. Navigate back to test case
9. Squint at colors trying to interpret values
10. Repeat 5-9 approximately 47 times
11. Finally find the bug
12. Remove debug code
13. Discover you introduced a new bug while debugging

Total time: hours

What We Actually Want: Shader REPL/Notebook

Imagine a development environment where:

┌─────────────────────────────────────────────────────────────────┐
│ SHADER NOTEBOOK                                          [Run] │
├─────────────────────────────────────────────────────────────────┤
│ Cell 1: Define SDF primitives                                   │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ (define (sphere p r)                                        │ │
│ │   (- (length p) r))                                         │ │
│ │                                                             │ │
│ │ (define (box p b)                                           │ │
│ │   (let ((q (- (abs p) b)))                                  │ │
│ │     (+ (length (max q 0)) (min (max q.x (max q.y q.z)) 0))))│ │
│ └─────────────────────────────────────────────────────────────┘ │
│ [✓ Compiled] [Visualize] [Trace]                                │
│                                                                 │
│ Cell 2: Compose scene                                           │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ (define (scene p)                                           │ │
│ │   (smooth-union                                              │ │
│ │     (sphere (- p (vec3 0 1 0)) 0.5)                         │ │
│ │     (box p (vec3 1 0.2 1))                                  │ │
│ │     0.3))                                                   │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ [✓ Compiled] [Visualize] [Trace]                                │
│                                                                 │
│ ┌──────────────────────┐  ┌─────────────────────────────────┐  │
│ │   [Live Preview]     │  │ Trace at cursor (123, 456):     │  │
│ │                      │  │   p = (0.23, 1.02, -0.5)        │  │
│ │     ████████         │  │   sphere_d = 0.021              │  │
│ │   ██████████████     │  │   box_d = 0.83                  │  │
│ │   ██████████████     │  │   smooth_union_d = 0.019        │  │
│ │     ████████         │  │   iterations = 34               │  │
│ │                      │  │   total_distance = 4.23         │  │
│ └──────────────────────┘  └─────────────────────────────────┘  │
│                                                                 │
│ REPL> (scene (vec3 0 1 0))                                      │
│ => 0.0                                                          │
│ REPL> (gradient scene (vec3 0 1 0))                             │
│ => (0.0, 1.0, 0.0)  ; normal points up, correct                 │
│ REPL> _                                                         │
└─────────────────────────────────────────────────────────────────┘

DEB1: Pixel-Level Trace Capture

Concept: Click on any pixel, get full execution trace for that pixel.

Implementation approaches:

Debug shader variant: Compile shader with trace buffer writes

#ifdef TRACE_ENABLED
traceBuffer[traceIndex++] = vec4(TRACE_ID_SPHERE_DIST, d, 0, 0);
#endif

Single-pixel compute dispatch: Re-run shader for just clicked pixel with full tracing

Printf debugging (where supported):

// Vulkan debugPrintfEXT, requires validation layers
debugPrintfEXT("p=%v3f d=%f", p, d);

Works well with:

Immediate mode rendering (stateless, reproducible)
Ray marching (single pixel = single ray = traceable)
Compute shaders (can capture arbitrary data)

Does not work well with:

Retained mode (which state version?)
Geometry shaders (amplification complicates tracing)
Multi-pass (which pass?)

DEB2: Hot-Reload with State Preservation

Concept: Edit shader, see result instantly, without losing camera position or scene state.

Implementation:

File watcher detects change
  → Compile new shader (background thread)
  → If success: swap shader, keep all uniforms
  → If fail: show error inline, keep old shader running
  → Never restart application

Existing tools with this:

Bonzomatic (demoscene live coding)
ShaderToy (web, but loses state on error)
glslViewer (command line, file watching)
Synthclipse (Eclipse-based)

What's missing: Integration with actual game engine scenes.

DEB3: In-Editor Visualization HUDs

Concept: Overlay debug info directly on the rendered frame, togglable via hotkeys or REPL.

┌────────────────────────────────────────────────────────┐
│ [F1] Normals  [F2] Depth  [F3] Iterations  [F4] UVs   │
│ [F5] Overdraw [F6] Mip Level [F7] Shader Cost         │
├────────────────────────────────────────────────────────┤
│                                                        │
│   Scene renders here with selected overlay             │
│                                                        │
│   ┌─────────────────────┐                              │
│   │ Stats:              │                              │
│   │ Avg iterations: 42  │                              │
│   │ Max iterations: 128 │                              │
│   │ Pixels at max: 2.3% │                              │
│   │ Frame time: 4.2ms   │                              │
│   └─────────────────────┘                              │
│                                                        │
│ > _                               [REPL input here]    │
└────────────────────────────────────────────────────────┘

REPL commands:

> set maxIterations 64          ; tweak uniform
> reload                        ; hot reload shaders
> capture                       ; save trace for this frame
> show normals                  ; enable normal vis
> query 320 240                 ; trace specific pixel
> time scene                    ; profile scene SDF
> bisect scene p0 p1 0.001      ; find exact surface point

DEB4: Value Inspection via Color Mapping

Since GPUs output colors, encode values as colors systematically:

// Standard debug palette
vec3 debugValue(float v, float minV, float maxV) {
    float t = (v - minV) / (maxV - minV);
    // Turbo colormap or similar
    return turboColormap(t);
}

// Directional encoding
vec3 debugDirection(vec3 d) {
    return d * 0.5 + 0.5;  // [-1,1] -> [0,1]
}

// Signed distance encoding  
vec3 debugSDF(float d) {
    if (d < 0.0) return vec3(-d, 0, 0);  // Inside: red
    else return vec3(0, 0, d);            // Outside: blue
}

Enhancement: Configurable color mapping with legend overlay.

DEB5: Time-Travel Debugging

For immediate mode rendering, we can replay any frame:

Record: [Camera, Time, Uniforms] for each frame
Playback: Jump to any recorded frame, re-render, trace

Timeline:
[====|====|====|====|====|====|====|====]
                    ^ Frame 847
                      Bug appears here
                      
[Step Back] [Step Forward] [Slow Motion] [Trace This Frame]

Works extremely well with: Immediate mode (stateless) Difficult with: Retained mode (need to record all state changes)

DEB6: Differential Rendering

Compare two shader versions side-by-side or as diff:

┌──────────────────────────────────────────────────────────────┐
│ [Before]              [After]               [Diff]           │
│ ┌────────────────┐    ┌────────────────┐   ┌────────────────┐│
│ │                │    │                │   │                ││
│ │  Old shader    │    │  New shader    │   │  Difference    ││
│ │  output        │    │  output        │   │  (amplified)   ││
│ │                │    │                │   │                ││
│ └────────────────┘    └────────────────┘   └────────────────┘│
│                                                              │
│ Max diff: 0.023 at (234, 567)                                │
│ Mean diff: 0.0001                                            │
│ Pixels > threshold: 0.3%                                     │
└──────────────────────────────────────────────────────────────┘

Useful for:

Optimization (verify output unchanged)
Bug hunting (when did it break?)
Precision debugging (float issues)

DEB7: Shader Profiling Integration

Per-pixel cost visualization:

// Instrument shader to count operations
#ifdef PROFILE_MODE
    int opCount = 0;
    #define SIN(x) (opCount++, sin(x))
    #define SQRT(x) (opCount++, sqrt(x))
    // etc.
#endif

// Or use hardware counters where available
// AMD: shader_clock, shader_cycles
// NVIDIA: similar with NSight

Overlay: Heatmap of shader cost per pixel.

S-Expression Based Shader Language

The verbosity and inflexibility of GLSL/HLSL actively impedes the immediate-mode, exploratory workflow. A Lisp-like language would enable:

Macros - Generate repetitive code, DSLs within the language
Homoiconicity - Code as data, enabling powerful metaprogramming
Conciseness - Less boilerplate, more signal
REPL-friendly - Natural fit for interactive development

SEXPR1: Core Language Design

; Define an SDF primitive
(define (sphere p r)
  (- (length p) r))

; Define a combinator (this is where macros shine)
(defmacro smooth-union (a b k)
  `(let ((h (clamp (+ 0.5 (/ (- ,b ,a) ,k)) 0.0 1.0)))
     (- (mix ,b ,a h) (* ,k h (- 1.0 h)))))

; Use it
(define (scene p)
  (smooth-union
    (sphere p 1.0)
    (sphere (- p (vec3 1.5 0 0)) 0.8)
    0.3))

; Domain repetition as a macro
(defmacro repeat-domain (p spacing body)
  `(let ((,p (- (mod (+ ,p (* ,spacing 0.5)) ,spacing) (* ,spacing 0.5))))
     ,body))

; Infinite spheres!
(define (infinite-spheres p)
  (repeat-domain p (vec3 3.0)
    (sphere p 0.5)))

SEXPR2: Compilation Targets

Source (.scm/.lisp)
       │
       ▼
   ┌───────────┐
   │  Parser   │
   └───────────┘
       │
       ▼
   ┌───────────┐
   │   Macro   │ ◄── User-defined macros expand here
   │ Expansion │
   └───────────┘
       │
       ▼
   ┌───────────┐
   │    IR     │ ◄── S-expression intermediate representation
   └───────────┘
       │
       ├──────────────┬──────────────┬──────────────┐
       ▼              ▼              ▼              ▼
   ┌───────┐     ┌───────┐     ┌───────┐     ┌───────┐
   │ GLSL  │     │ HLSL  │     │ SPIR-V│     │ Metal │
   │  Gen  │     │  Gen  │     │  Gen  │     │  Gen  │
   └───────┘     └───────┘     └───────┘     └───────┘
       │              │              │              │
       ▼              ▼              ▼              ▼
   OpenGL         DirectX        Vulkan        macOS/iOS

SEXPR3: Example Macro Power

Problem: GLSL has no generics, no templates, lots of repetition.

GLSL approach:

float smoothUnionFloat(float a, float b, float k) { ... }
vec2 smoothUnionVec2(vec2 a, vec2 b, float k) { ... }
vec3 smoothUnionVec3(vec3 a, vec3 b, float k) { ... }
vec4 smoothUnionVec4(vec4 a, vec4 b, float k) { ... }

S-expr approach:

(defmacro define-smooth-union (type)
  `(define (,(symbol-append 'smooth-union- type) a b k)
     (let ((h (clamp (+ 0.5 (/ (- b a) k)) 0.0 1.0)))
       (- (mix b a h) (* k h (- 1.0 h))))))

(define-smooth-union float)
(define-smooth-union vec2)
(define-smooth-union vec3)
(define-smooth-union vec4)

; Or even better, let type inference handle it:
(define-generic smooth-union (a b k)
  (let ((h (clamp (+ 0.5 (/ (- b a) k)) 0.0 1.0)))
    (- (mix b a h) (* k h (- 1.0 h)))))

SEXPR4: Domain-Specific Extensions

; SDF-specific syntax
(sdf-define scene
  (union
    (intersect
      (sphere origin 1.0)
      (plane (vec3 0 1 0) 0.0))
    (transform (translate 0 2 0)
      (rotate-y time
        (box origin (vec3 0.5))))))

; Expands to efficient GLSL with proper transforms

SEXPR5: Debugging Integration

; Trace macro for debugging
(defmacro trace (label expr)
  (if *debug-mode*
    `(let ((result ,expr))
       (emit-trace ,label result)
       result)
    expr))

; Usage
(define (scene p)
  (trace 'final-distance
    (smooth-union
      (trace 'sphere-distance (sphere p 1.0))
      (trace 'box-distance (box p (vec3 1)))
      0.3)))

; In release mode, traces compile away completely

SEXPR6: Existing Work & Tools

Existing Lisp-to-shader compilers:

Varjo (Common Lisp → GLSL, mature, used in production)
Shady (Scheme-like → GLSL)
CEPL (Common Lisp live-coding environment with Varjo)
Shader-lib (Racket → GLSL)
Penumbra (Clojure → GLSL, older)

Related approaches:

ISF (Interactive Shader Format) - JSON metadata + GLSL
The Book of Shaders Editor - Live preview but still GLSL
KodeLife - Commercial live-coding tool
cables.gl - Visual node-based, compiles to GLSL

What's missing: Deep integration with game engines, not just standalone tools.

SEXPR7: Minimal Kernel Language Approach

Alternative: Define a tiny core, sugar on top:

Core primitives (the "kernel"):
- lambda, let, if, define
- Arithmetic: + - * / mod
- Comparisons: < > = 
- Vector ops: vec2, vec3, vec4, swizzle
- Math: sin, cos, sqrt, abs, min, max, clamp, mix, length, dot, cross, normalize

Everything else: macros in user space

This kernel compiles directly to GLSL/HLSL/SPIR-V intrinsics.

SEXPR8: The REPL Experience

shader-repl> (define (sphere p r) (- (length p) r))
; sphere defined

shader-repl> (sphere (vec3 0 0 0) 1.0)
; => -1.0  (inside the sphere)

shader-repl> (sphere (vec3 2 0 0) 1.0)
; => 1.0  (outside the sphere)

shader-repl> (gradient sphere (vec3 1 0 0) 0.001)
; => (1.0, 0.0, 0.0)  (normal points +X)

shader-repl> (render scene #:width 800 #:height 600)
; [Opens preview window]

shader-repl> (set! *camera-pos* (vec3 0 2 5))
; [Preview updates immediately]

shader-repl> (export-glsl scene "scene.glsl")
; Wrote scene.glsl

shader-repl> (time (scene (vec3 0 0 0)))
; 0.000023ms per evaluation (CPU reference)
; Estimated GPU: ~0.0001ms per pixel

Engine Compatibility Notes

The unfortunate reality: most techniques must eventually work with Godot, Unreal, or Unity. Here's a realistic assessment of integration difficulty.

Compatibility Rating Scale

★★★★★ - Native support, just use it
★★★★☆ - Plugin/extension exists, works well  
★★★☆☆ - Possible with effort, some limitations
★★☆☆☆ - Hacky, fights the engine, fragile
★☆☆☆☆ - Theoretically possible, practically painful
☆☆☆☆☆ - Fundamentally incompatible, don't try

Engine Architecture Summary

Aspect	Godot 4	Unreal 5	Unity 2022+
Renderer	Vulkan/OpenGL (custom)	RHI abstraction	SRP (URP/HDRP)
Shader lang	Godot Shading Language	HLSL + Material Editor	HLSL/ShaderLab
Custom shaders	★★★★☆ Easy	★★★☆☆ Complex	★★★★☆ Moderate
Compute shaders	★★★☆☆ Recent addition	★★★★☆ Good support	★★★★☆ Good support
Custom render passes	★★★☆☆ Possible	★★☆☆☆ Very complex	★★★★☆ SRP makes this easier
Hot reload shaders	★★★★★ Built-in	★★★☆☆ Editor only	★★★★☆ Works
Source access	★★★★★ Open source	★★★★☆ Source available	☆☆☆☆☆ Closed

Technique Compatibility Matrix

Geometry Techniques

Technique	Godot 4	Unreal 5	Unity	Notes
G1: Billboards	★★★★★	★★★★★	★★★★★	Universal support
G2: SDFs (ray marched)	★★★☆☆	★★☆☆☆	★★★☆☆	Custom shader, fights lighting
G3: Standard meshes	★★★★★	★★★★★	★★★★★	This is what engines do
G4: Voxels	★★★☆☆	★★★☆☆	★★★☆☆	Plugins exist, not native
G5: Gaussian Splats	★★☆☆☆	★★★☆☆	★★★☆☆	Emerging plugin support
G6: Nanite-style	☆☆☆☆☆	★★★★★	☆☆☆☆☆	UE5 exclusive
G9: Subdivision	★★☆☆☆	★★★☆☆	★★☆☆☆	Limited runtime support

Procedural Techniques

Technique	Godot 4	Unreal 5	Unity	Notes
P1: Proc buildings	★★★☆☆	★★★★☆	★★★☆☆	Houdini→UE pipeline good
P2: Proc terrain	★★★★☆	★★★★★	★★★★☆	Good support across
P4: Proc textures	★★★★☆	★★★★☆	★★★★☆	Shader-based, universal
P6: Compute gen	★★★☆☆	★★★★☆	★★★★☆	Godot compute newer

Texture Techniques

Technique	Godot 4	Unreal 5	Unity	Notes
T1: BC/DXT/ASTC	★★★★★	★★★★★	★★★★★	Universal
T4: Virtual texturing	☆☆☆☆☆	★★★★★	★★☆☆☆	UE has best support
T6: Procedural tex	★★★★☆	★★★☆☆	★★★★☆	UE material editor verbose
T7: Triplanar	★★★★★	★★★★★	★★★★★	Easy shader technique

Rendering Paradigms

Technique	Godot 4	Unreal 5	Unity	Notes
R1: Rasterization	★★★★★	★★★★★	★★★★★	Default
R2: Ray marching	★★★☆☆	★★☆☆☆	★★★☆☆	Custom pass needed
R5: Deferred	★★★★☆	★★★★★	★★★★☆	HDRP is deferred
R7: RT/Path tracing	★★☆☆☆	★★★★★	★★★★☆	UE5 Lumen excellent

Animation

Technique	Godot 4	Unreal 5	Unity	Notes
A2: Skeletal	★★★★★	★★★★★	★★★★★	Core feature
A4: Procedural	★★★☆☆	★★★★☆	★★★★☆	UE Control Rig good
A5: VAT	★★★☆☆	★★★★☆	★★★★☆	Plugins/workflows exist

Immediate Mode & Debugging

Technique	Godot 4	Unreal 5	Unity	Notes
Shader hot reload	★★★★★	★★★☆☆	★★★★☆	Godot best here
Custom render pass	★★★☆☆	★★☆☆☆	★★★★☆	Unity SRP helps
Debug visualization	★★★☆☆	★★★★☆	★★★★☆	UE has good tools
REPL-style workflow	★★☆☆☆	★☆☆☆☆	★★☆☆☆	None support well
Custom shader lang	★★☆☆☆	★☆☆☆☆	★★★☆☆	Unity allows preprocessing

Integration Strategies by Engine

Godot 4 Integration

Advantages:

Open source - can modify anything
GDExtension for native code
Simple, readable codebase
Shader language is clean and well-documented
Best hot-reload support

Challenges:

Smaller ecosystem
Less mature advanced features
Compute shader support newer

Recommended approach for immediate-mode/SDF:

1. Create GDExtension in C++/Rust
2. Write custom VisualServer rendering commands
3. Use ComputeShader for generation
4. Hook into Godot's shader preprocessor for custom syntax

Difficulty: ★★★☆☆ (Medium, source helps)

S-expr shader integration:

Option A: Transpile to Godot Shading Language
  - Godot's shader lang is simple, good target
  - Loses some GLSL features but gains simplicity
  
Option B: GDExtension that compiles to SPIR-V directly
  - Bypass Godot's shader compiler
  - More complex but more powerful

Difficulty: ★★★☆☆ (Medium)

Unreal Engine 5 Integration

Advantages:

Extremely powerful rendering features
Good compute shader support
Nanite, Lumen, Virtual Texturing built-in
Large community, many tutorials

Challenges:

Massive, complex codebase
Strong opinions about how things should be done
Material Editor is visual, not text-friendly
Custom rendering is very complex
Shader compilation is slow

Recommended approach for immediate-mode/SDF:

1. Use Custom Stencil Buffer approach (hacky)
2. Or: Create custom SceneViewExtension
3. Or: Modify Deferred Shading pass (requires engine mod)
4. For simple cases: Ray march in post-process material

Difficulty: ★★☆☆☆ (Hard, fights the engine)

S-expr shader integration:

Option A: Generate HLSL, inject via Custom node in Materials
  - Limited to material graph context
  - Can't easily do full custom passes
  
Option B: Generate USF files, register as global shaders
  - More powerful, much more complex
  - Need to understand RDG (Render Dependency Graph)
  
Option C: Plugin that preprocesses .usf files
  - Intercept shader compilation
  - Very fragile, version-dependent

Difficulty: ★☆☆☆☆ (Very Hard)

What UE5 is good at (use these instead):

Nanite for massive geometry - just use it
Lumen for GI - just use it
Material Editor for standard PBR - accept the visual workflow
Niagara for particles/procedural

Unity Integration

Advantages:

SRP (Scriptable Render Pipeline) allows custom rendering
C# is reasonable for tooling
Good shader variant system
Moderate complexity (between Godot and Unreal)
Shader preprocessing possible

Challenges:

Closed source
SRP documentation incomplete
Multiple render pipelines (URP vs HDRP) fragment ecosystem
Shader compilation can be slow

Recommended approach for immediate-mode/SDF:

1. Create custom RenderFeature in URP/HDRP
2. Add custom render pass
3. Full control over what's rendered
4. Can inject compute shaders

Difficulty: ★★★☆☆ (Medium, SRP helps)

S-expr shader integration:

Option A: Transpile to HLSL, use as .shader files
  - Most straightforward
  - Can use ShaderLab wrapper for multi-platform
  
Option B: Custom ScriptedImporter for .scm files
  - Editor recognizes your file type
  - Compiles on import
  - Good workflow integration

Option C: Shader preprocessing via IPreprocessShaders
  - Intercept compilation
  - Transform AST before Unity compiles
  
Difficulty: ★★★☆☆ (Medium, good extensibility)

Recommended Engine by Technique Priority

If your priority is...

Priority	Recommended	Reasoning
Immediate mode workflow	Godot	Best hot reload, simplest to modify
Custom shader language	Unity	Best preprocessing hooks
Maximum visual quality	Unreal	Nanite, Lumen, etc.
SDF-based rendering	Godot	Easiest to add custom render pass
Procedural generation	Unreal	Houdini integration, PCG framework
Open source control	Godot	Only option
VR/AR	Unity	Best XR support historically
Tiny executable size	Godot	Smallest runtime
AAA production	Unreal	Industry standard

The "Escape Hatch" Approach

When engines fight you too much:

Strategy: Render to texture in custom code, composite in engine

┌─────────────────────────────────────────────────────────────┐
│                      Your Custom Renderer                    │
│                                                             │
│  ┌─────────────────┐     ┌─────────────────┐               │
│  │  S-expr Shader  │ ──► │  GLSL/HLSL/MSL  │               │
│  │    Compiler     │     │                 │               │
│  └─────────────────┘     └─────────────────┘               │
│           │                       │                         │
│           ▼                       ▼                         │
│  ┌─────────────────────────────────────────┐               │
│  │        Custom Rendering Context          │               │
│  │   (Separate window or shared context)    │               │
│  └─────────────────────────────────────────┘               │
│                         │                                   │
│                         ▼                                   │
│                  Render to Texture                          │
│                         │                                   │
└─────────────────────────┼───────────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────────┐
│                    Game Engine                               │
│                                                             │
│   ┌───────────────────────────────────────────────────┐     │
│   │  Apply texture to quad / full-screen pass          │     │
│   │  Engine handles: UI, physics, audio, input, etc.   │     │
│   └───────────────────────────────────────────────────┘     │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Benefits:

Full control over rendering
Engine handles everything else
Clean separation of concerns
Can develop renderer independently

Drawbacks:

Context switching overhead
Synchronization complexity
Lose some engine integration (shadows, etc.)
Two codebases to maintain

Future: WebGPU as Universal Target?

WebGPU is emerging as a potential universal shader target:

S-expr source
     │
     ▼
  WGSL output
     │
     ├──► Browser (native WebGPU)
     ├──► Desktop (Dawn/wgpu)
     └──► Engines (via plugins)
         ├──► Godot (wgpu backend in development)
         ├──► Unity (WebGPU export)
         └──► Unreal (less likely)

Advantages:

Single target language (WGSL)
Modern API design
Cross-platform by design
Good for immediate-mode patterns

Current status: Promising but not production-ready for games.

Spectrum Position Affects Compression Strategy

Position	Compression Strategy	Rationale
D1-D2 (Retained)	Heavy offline compression (Draco, BC7, Basis)	Amortize decode cost over long retention
D3-D5 (Mixed)	Balanced compression, fast decode	Some retained, some dynamic
D6-D7 (Streaming)	Progressive, fast decode	Bandwidth limited, can't wait
D8-D9 (Immediate)	Minimal/no compression	Decode cost paid every frame
D10 (Software)	Whatever CPU handles	Different constraints entirely

Key insight: In immediate mode, your "compression" is your procedural algorithm. The SDF function IS the compressed representation of your geometry.

Mapping Other Techniques to Spectrum

Technique	Best Spectrum Position	Notes
G2 (SDFs)	D8-D10	Inherently immediate, computed not stored
G6 (Nanite)	D1	Extremely retained, GPU-driven
G4 (Voxels)	D5-D8	Can be either, often dynamic
P6 (Compute generation)	D8	Generated each frame
T6 (Procedural textures)	D8-D9	No texture data, computed
R2 (Ray marching)	D8-D10	Stateless per-pixel
G1 (Billboards)	D2-D5	Usually retained, updated
A5 (Vertex Animation Textures)	D2	Retained, sampled

Observed Patterns & Principles

After cataloging these techniques, several meta-patterns emerge:

Pattern 1: Rightward Dependency (Immediate Can Use Retained, Not Vice Versa)

RETAINED ◄─────────────────────────────────── IMMEDIATE
   D1    D2    D3    D4    D5    D6    D7    D8    D9    D10
   
   ────────────────────────────────────────────────────────►
   Easy to depend on things to the RIGHT (more immediate)
   
   ◄────────────────────────────────────────────────────────
   Hard to depend on things to the LEFT (more retained)

Why this happens:

Immediate mode code can always be "frozen" and retained
Retained mode code assumes data exists; can't easily generate it on demand
You can cache the output of procedural generation, but you can't easily proceduralize cached data

Examples:

A retained mesh (D2) can easily use a procedural texture (D8) - just compute it once, bake to texture
A procedural SDF (D8) cannot easily use a pre-built mesh (D2) - would need SDF conversion
Nanite (D1) can't invoke compute-generated geometry (D8) - it needs pre-clustered data

Implication: Design your most constrained/retained systems first, then fill in with more immediate techniques.

Pattern 2: Compression Relevance Inversely Correlates with Dynamism

High Compression Value ◄─────────────────► Low Compression Value
        D1    D2    D3    D4    D5    D6    D7    D8    D9    D10
        
The more retained, the more compression matters.
The more immediate, the less traditional compression applies.

At D1-D3: Heavy compression (Draco, BC7, Basis) - amortized over long retention At D4-D6: Moderate compression - balance decode speed vs. size At D7-D8: Light/fast compression - streaming, decode cost matters At D9-D10: Algorithm IS compression - procedural = maximally compressed

Implication: If you're targeting extreme compression, you're implicitly pushed toward immediate/procedural.

Pattern 3: Debugging Ease Correlates with Dynamism

Hard to Debug ◄───────────────────────────► Easy to Debug
     D1    D2    D3    D4    D5    D6    D7    D8    D9    D10

Why:

D1: State on GPU, async, no visibility
D5: Mixed, can focus on one half
D10: Everything in CPU memory, print statements work

Implication: Develop in immediate mode (D8-D10), then migrate leftward for performance.

Pattern 4: Engine Compatibility Inversely Correlates with Dynamism

Good Engine Support ◄────────────────────► Poor Engine Support
      D1    D2    D3    D4    D5    D6    D7    D8    D9    D10
      
(With exception of D1 in UE5 specifically due to Nanite)

Why: Game engines are built around retained scene graphs (D2-D3). They have pipelines for:

Loading meshes → GPU buffers
Managing transforms
Culling, batching, draw calls

They don't have pipelines for:

"Here's a function, evaluate it per-pixel"
"Generate geometry in this compute shader, render it, discard"

Exception: UE5's Nanite is D1, but required rewriting Unreal's entire renderer.

Implication: The more immediate your technique, the more you fight the engine.

Pattern 5: The "Goldilocks Zone" is D5-D6

For most practical game development:

D1-D2: AAA with dedicated engine teams
D3-D4: Standard production games
D5-D6: Best balance of flexibility and compatibility
D7-D8: Specialized (voxel games, demoscene)
D9-D10: Prototyping, learning, extreme cases

D5-D6 characteristics:

CPU understands what's being rendered
Can use both retained and immediate techniques
Debuggable
Works with engines (with some effort)
Reasonable performance

Pattern 6: Procedural Techniques Cluster at D8

Almost all procedural techniques (P1-P8) naturally live at D8:

They compute rather than store
Output can be captured (→ move left) or computed fresh (→ stay)
Parameters are tiny (bytes), output is large (megabytes)

The procedural bargain: Trade compute for storage.

Pattern 7: Style Constraints Enable Extreme Positions

The ART* techniques (single primitive, single palette, low resolution) enable:

D10 becomes viable (CPU can handle simple rendering)
D8-D9 become practical (less to compute)
Compression becomes trivial (less variety = better ratios)

Implication: Artistic constraints are technical enablers.

Pattern 8: Animation Breaks Immediate Mode Assumptions

Animation is the hardest category for immediate mode because:

Keyframe data must come from somewhere (artists)
Skeletal hierarchies need state
Blending requires history

Solutions:

A4 (Procedural animation) - stays immediate
A5 (VAT) - bake to texture, become retained
Accept hybrid: retained animation data, immediate rendering

Pattern 9: The Two Cultures

There are essentially two graphics programming cultures:

Culture A: Retained/Engine (D1-D4)

"Load asset, add to scene, engine handles it"
Performance via caching, batching, culling
Debug via engine tools
Artist-driven content

Culture B: Immediate/Procedural (D7-D10)

"Compute everything from parameters"
Performance via algorithm efficiency
Debug via printf and visualization
Programmer-driven content

Most techniques belong clearly to one culture. Mixing them is possible but requires bridging.

Pattern 10: The Demoscene Position

Demoscene 4KB/64KB intros occupy D8-D10 exclusively:

No room for retained data
Everything procedural
Executable packer as final compression
SDF + ray marching dominant

This represents the theoretical minimum for 3D graphics: pure algorithm, zero assets.

Technique × Spectrum Compatibility Matrix

This table shows which techniques work at which spectrum positions.

Legend:

● = Native/natural fit
◐ = Possible with effort
○ = Theoretically possible but awkward
✗ = Incompatible/nonsensical

Geometry Techniques

Technique	D1	D2	D3	D4	D5	D6	D7	D8	D9	D10
G1: Billboards	◐	●	●	●	●	●	●	◐	◐	◐
G2: SDFs	✗	✗	✗	○	◐	◐	●	●	●	●
G3: Polygon Meshes	●	●	●	●	●	●	◐	○	○	◐
G4: Voxels	◐	◐	◐	◐	●	●	●	●	◐	◐
G5: Gaussian Splats	●	●	◐	◐	◐	○	○	✗	✗	✗
G6: Nanite-style	●	○	✗	✗	✗	✗	✗	✗	✗	✗
G7: Mesh Compression	●	●	●	●	●	●	●	✗	✗	✗
G8: Implicit Noise	✗	✗	○	◐	◐	●	●	●	●	●
G9: Subdivision	◐	●	●	●	●	◐	○	○	○	○
G10: Displacement	◐	●	●	●	●	●	◐	○	○	○
G11: CSG	✗	○	○	◐	●	●	●	●	●	●
G12: NURBS/Curves	○	●	●	●	●	◐	◐	○	○	○
G13: Height Maps	◐	●	●	●	●	●	●	●	◐	◐
G14: Sprite Stacking	✗	●	●	●	●	●	◐	○	●	●
G15: Style Transfer	✗	○	◐	◐	●	●	●	●	○	✗
G16: Geometry Images	●	●	●	◐	◐	○	○	✗	✗	✗

(Additional technique × spectrum tables for Procedural, Texture, Rendering, etc. continue in the full document)

Technique × Technique Compatibility Matrix

These matrices show how different techniques work together.

Legend:

✅ = Strong synergy (designed to work together)
⚠️ = Possible (can combine with effort)
❌ = Incompatible (fundamentally different paradigms)
➖ = Same technique / not applicable

Core Geometry Techniques

	G1 Bill	G2 SDF	G3 Mesh	G4 Voxel	G5 Splat	G6 Nanite	G8 Noise	G9 Subdiv	G11 CSG	G13 Height
G1 Billboard	➖	❌	✅	⚠️	⚠️	✅	❌	⚠️	❌	✅
G2 SDF	❌	➖	❌	⚠️	❌	❌	✅	❌	✅	⚠️
G3 Mesh	✅	❌	➖	⚠️	⚠️	✅	⚠️	✅	⚠️	✅
G4 Voxel	⚠️	⚠️	⚠️	➖	❌	❌	✅	❌	✅	✅
G5 Splat	⚠️	❌	⚠️	❌	➖	❌	❌	❌	❌	⚠️
G6 Nanite	✅	❌	✅	❌	❌	➖	❌	⚠️	❌	⚠️
G8 Noise	❌	✅	⚠️	✅	❌	❌	➖	⚠️	✅	✅
G9 Subdiv	⚠️	❌	✅	❌	❌	⚠️	⚠️	➖	⚠️	⚠️
G11 CSG	❌	✅	⚠️	✅	❌	❌	✅	⚠️	➖	⚠️
G13 Height	✅	⚠️	✅	✅	⚠️	⚠️	✅	⚠️	⚠️	➖

Key Observations:

G2 (SDF) is fundamentally incompatible with polygon-based techniques (G3, G6, G9)
G6 (Nanite) works great with traditional meshes, impostors for LOD
G4 (Voxel) bridges SDF and mesh worlds - can convert to either
G8 (Noise) is highly compatible with procedural approaches (SDF, voxel, heightmap)

Geometry × Rendering Paradigms

	R1 Forward	R2 RayMarch	R3 VoxCast	R4 Particle	R5 Deferred	R6 Forward+	R7 RT
G1 Billboard	✅	❌	❌	✅	✅	✅	⚠️
G2 SDF	❌	✅	⚠️	❌	❌	❌	⚠️
G3 Mesh	✅	❌	❌	⚠️	✅	✅	✅
G4 Voxel	⚠️	⚠️	✅	⚠️	⚠️	⚠️	⚠️
G5 Splat	⚠️	❌	❌	✅	⚠️	⚠️	❌
G6 Nanite	⚠️	❌	❌	⚠️	✅	⚠️	✅
G8 Noise	⚠️	✅	✅	⚠️	⚠️	⚠️	⚠️
G9 Subdiv	✅	❌	❌	❌	✅	✅	✅
G11 CSG	⚠️	✅	⚠️	❌	⚠️	⚠️	⚠️
G13 Height	✅	⚠️	⚠️	⚠️	✅	✅	✅

Key Observations:

R2 (Ray Marching) is the natural match for SDF, incompatible with most mesh techniques
G6 (Nanite) uses software rasterization internally, integrates with deferred
R7 (Ray Tracing) works with traditional geometry, not pure SDF or procedural

Geometry × Texture Techniques

	T1 Compress	T3 Atlas	T4 Virtual	T6 ProcTex	T7 Triplanar	T8 Palette
G1 Billboard	✅	✅	✅	⚠️	❌	✅
G2 SDF	❌	❌	❌	✅	✅	⚠️
G3 Mesh	✅	✅	✅	✅	⚠️	✅
G4 Voxel	⚠️	⚠️	⚠️	✅	✅	✅
G5 Splat	⚠️	⚠️	⚠️	❌	❌	❌
G6 Nanite	✅	✅	✅	✅	⚠️	⚠️
G8 Noise	❌	❌	❌	✅	✅	⚠️
G11 CSG	⚠️	⚠️	⚠️	✅	✅	✅
G13 Height	✅	⚠️	✅	✅	✅	✅

Key Observations:

T6 (Procedural Textures) is the natural match for SDF and procedural geometry
T7 (Triplanar) is essential for geometry without UV coordinates (voxels, SDF, CSG)
G5 (Splats) have their own color representation, don't use traditional texturing
T1 (Compression) doesn't apply to pure procedural (nothing to compress)

Geometry × Animation

	A1 Keyframe	A2 Skeletal	A4 Procedural	A5 VAT	A6 Morph
G1 Billboard	✅	❌	⚠️	⚠️	❌
G2 SDF	⚠️	❌	✅	❌	⚠️
G3 Mesh	✅	✅	✅	✅	✅
G4 Voxel	⚠️	❌	✅	⚠️	❌
G6 Nanite	✅	⚠️	⚠️	⚠️	⚠️
G8 Noise	⚠️	❌	✅	❌	⚠️
G9 Subdiv	✅	✅	✅	⚠️	✅
G11 CSG	⚠️	❌	✅	❌	⚠️
G13 Height	✅	❌	✅	⚠️	⚠️

Key Observations:

A2 (Skeletal) only works with deformable mesh representations (G3, G9)
A4 (Procedural) is the natural match for SDF and procedural geometry
G6 (Nanite) has limited skeletal support (world-space evaluation issue)

Geometry × Lighting

	M1 Flat	M2 Phong	M3 PBR	M4 Lightmap	M7 Toon	M8 Matcap
G1 Billboard	✅	⚠️	⚠️	⚠️	✅	✅
G2 SDF	✅	✅	✅	❌	✅	✅
G3 Mesh	✅	✅	✅	✅	✅	✅
G4 Voxel	✅	✅	⚠️	⚠️	✅	⚠️
G5 Splat	✅	⚠️	⚠️	❌	⚠️	❌
G6 Nanite	✅	✅	✅	✅	✅	✅
G8 Noise	✅	✅	⚠️	❌	✅	✅
G11 CSG	✅	✅	⚠️	❌	✅	✅
G13 Height	✅	✅	✅	✅	✅	✅

Key Observations:

M4 (Lightmaps) requires UV-unwrapped static geometry - incompatible with SDF, noise, CSG
M1 (Flat) and M7 (Toon) work with almost everything
G3 (Mesh) is the most lighting-compatible representation

Mega-Matrix: Core Techniques (Condensed)

A condensed view of the most important technique interactions across all categories:

	G2 SDF	G3 Mesh	G4 Vox	G6 Nan	P6 Comp	T6 Proc	R2 March	R5 Def	M3 PBR	M4 Light	A2 Skel	A4 Proc
G2 SDF	➖	❌	⚠️	❌	✅	✅	✅	❌	✅	❌	❌	✅
G3 Mesh	❌	➖	⚠️	✅	✅	✅	❌	✅	✅	✅	✅	✅
G4 Voxel	⚠️	⚠️	➖	❌	✅	✅	⚠️	⚠️	⚠️	⚠️	❌	✅
G6 Nanite	❌	✅	❌	➖	❌	✅	❌	✅	✅	✅	⚠️	⚠️
P6 Compute	✅	✅	✅	❌	➖	✅	⚠️	⚠️	⚠️	❌	⚠️	✅
T6 ProcTex	✅	✅	✅	✅	✅	➖	✅	✅	✅	❌	✅	✅
R2 RayMarch	✅	❌	⚠️	❌	⚠️	✅	➖	⚠️	✅	❌	❌	✅
R5 Deferred	❌	✅	⚠️	✅	⚠️	✅	⚠️	➖	✅	✅	✅	✅
M3 PBR	✅	✅	⚠️	✅	⚠️	✅	✅	✅	➖	✅	✅	✅
M4 Lightmap	❌	✅	⚠️	✅	❌	❌	❌	✅	✅	➖	⚠️	❌
A2 Skeletal	❌	✅	❌	⚠️	⚠️	✅	❌	✅	✅	⚠️	➖	✅
A4 ProcAnim	✅	✅	✅	⚠️	✅	✅	✅	✅	✅	❌	✅	➖

Paradigm Clusters Visible:

Top-left (G2, P6, T6, R2, A4): Procedural/Immediate cluster - lots of ✅
Center-right (G3, G6, R5, M3, M4, A2): Traditional/Retained cluster - lots of ✅
Cross-paradigm (❌ patterns): SDF↔Mesh, Lightmap↔Procedural, RayMarch↔Deferred

Fundamental Paradigm Splits

The matrix reveals four fundamental splits:

Split	Left Side	Right Side	Root Cause
Representation	G2 SDF, G8 Noise, G11 CSG	G3 Mesh, G6 Nanite, G9 Subdiv	Mathematical function vs stored triangles
Rendering	R2 Ray March, R3 Voxel Cast	R1 Forward, R5 Deferred, R7 RT	Per-pixel evaluation vs rasterization
Data Source	P6 Compute, T6 Procedural, A4 Procedural	M4 Lightmap, A2 Skeletal, A5 VAT	Runtime computation vs precomputed data
Parameterization	G2, G4, G8, G11 (no UVs)	G3, G6, G9 (UVs)	Implicit surface vs explicit mapping

Compatibility Recipes

Pre-validated technique combinations for common use cases:

Recipe: Demoscene 4KB

G2 (SDF) + P8 (Fractal) + T6 (Procedural) + R2 (RayMarch) + M2 (Phong) + A4 (Procedural)

✅ All compatible - pure procedural, no stored data

Recipe: Mobile Game

G3 (Mesh) + G1 (Billboard) + T1 (Compress) + T3 (Atlas) + R1 (Forward) + M4 (Lightmap) + A2 (Skeletal) + L1 (Discrete LOD)

✅ All compatible - traditional retained, baked lighting

Recipe: Open World AAA

G6 (Nanite) + G3 (Mesh) + P2 (Terrain) + T4 (Virtual) + R5 (Deferred) + R7 (RT) + M3 (PBR) + M4 (Lightmap) + A2 (Skeletal) + L5 (Streaming)

✅ All compatible - Nanite + traditional with streaming

Recipe: Voxel Sandbox

G4 (Voxel) + P6 (Compute) + T8 (Palette) + R3 (VoxelCast) + M2 (Phong) + A4 (Procedural) + C7 (DAG)

✅ All compatible - voxel-focused stack

Recipe: Stylized Indie

G3 (Mesh) + G9 (Subdiv) + T6 (Procedural) + T8 (Palette) + R1 (Forward) + M7 (Toon) + M8 (Matcap) + A2 (Skeletal) + A4 (Procedural)

✅ All compatible - stylized with procedural touches

Procedural Techniques

Technique	D1	D2	D3	D4	D5	D6	D7	D8	D9	D10
P1: Proc Buildings	○	◐	◐	◐	●	●	●	●	◐	◐
P2: Proc Terrain	○	◐	◐	●	●	●	●	●	◐	◐
P3: Proc Vegetation	○	◐	◐	●	●	●	●	●	◐	○
P4: Proc Textures	✗	○	◐	●	●	●	●	●	●	●
P5: Wang Tiles	◐	●	●	●	●	●	◐	○	○	○
P6: Compute Gen	○	○	○	◐	●	●	●	●	✗	✗
P7: Grammar-Based	○	◐	◐	◐	●	●	●	●	●	●
P8: Fractals	✗	○	○	◐	●	●	●	●	●	●

Texture Techniques

Technique	D1	D2	D3	D4	D5	D6	D7	D8	D9	D10
T1: GPU Compression	●	●	●	●	●	●	●	○	○	✗
T2: Supercompression	●	●	●	●	●	●	●	○	○	○
T3: Atlasing	●	●	●	●	●	●	◐	○	○	○
T4: Virtual Texturing	●	●	●	●	◐	◐	●	○	✗	✗
T5: Tex Synthesis	○	◐	◐	●	●	●	●	●	◐	◐
T6: Procedural Tex	✗	○	◐	●	●	●	●	●	●	●
T7: Triplanar	◐	●	●	●	●	●	●	●	●	●
T8: Palette-Based	◐	●	●	●	●	●	●	●	●	●
T9: Polynomial Approx	✗	○	○	◐	●	●	●	●	●	●
T10: Fourier/DCT	○	◐	◐	●	●	●	●	●	◐	◐
T11: Neural Compress	●	●	◐	◐	◐	○	○	○	✗	✗
T12: Detail Textures	●	●	●	●	●	●	●	◐	◐	◐
T14: Material ID	◐	●	●	●	●	●	●	●	●	●

Rendering Paradigms

Technique	D1	D2	D3	D4	D5	D6	D7	D8	D9	D10
R1: Rasterization	●	●	●	●	●	●	●	◐	◐	◐
R2: Ray Marching	✗	✗	○	◐	●	●	●	●	●	●
R3: Voxel Raycasting	○	◐	◐	●	●	●	●	●	●	●
R4: Particles	●	●	●	●	●	●	●	●	◐	◐
R5: Deferred	●	●	●	●	●	◐	○	○	✗	✗
R6: Forward+	●	●	●	●	●	●	◐	○	○	✗
R7: Hybrid RT	●	●	●	●	◐	◐	○	○	✗	✗
R8: Software Raster	●	●	●	●	●	●	●	●	●	●

Compression & Encoding

Technique	D1	D2	D3	D4	D5	D6	D7	D8	D9	D10
C1: Delta Encoding	●	●	●	●	●	●	●	○	○	○
C2: Quantization	●	●	●	●	●	●	●	●	●	●
C3: Octree	●	●	●	●	●	●	●	●	◐	◐
C4: Run-Length	●	●	●	●	●	●	●	○	○	○
C5: LZ-family	●	●	●	●	●	●	●	○	○	○
C6: Entropy Coding	●	●	●	●	●	●	◐	○	○	○
C7: Sparse Voxel DAG	●	●	◐	◐	●	●	●	○	✗	✗
C8: PCA/SVD	●	●	●	●	●	◐	◐	○	○	○

LOD & Streaming

Technique	D1	D2	D3	D4	D5	D6	D7	D8	D9	D10
L1: Discrete LOD	●	●	●	●	●	●	◐	○	○	○
L2: Continuous LOD	●	●	●	●	●	●	●	◐	○	○
L3: HLOD	●	●	◐	◐	●	◐	○	✗	✗	✗
L4: Impostor LOD	●	●	●	●	●	●	●	◐	◐	◐
L5: Streaming	●	●	●	●	●	●	●	○	✗	✗

Animation

Technique	D1	D2	D3	D4	D5	D6	D7	D8	D9	D10
A1: Keyframe	●	●	●	●	●	●	◐	○	○	○
A2: Skeletal	●	●	●	●	●	◐	○	○	○	○
A3: Anim Compression	●	●	●	●	●	●	◐	✗	✗	✗
A4: Procedural Anim	○	◐	◐	●	●	●	●	●	●	●
A5: VAT	●	●	●	●	●	◐	◐	○	✗	✗
A6: Morph Targets	●	●	●	●	●	●	◐	○	○	○
A7: Bone Baking	●	●	●	●	●	◐	○	✗	✗	✗
A8: Flipbook	◐	●	●	●	●	●	●	◐	●	●

Lighting & Materials

Technique	D1	D2	D3	D4	D5	D6	D7	D8	D9	D10
M1: Flat/Unlit	●	●	●	●	●	●	●	●	●	●
M2: Lambert/Phong	●	●	●	●	●	●	●	●	●	●
M3: PBR	●	●	●	●	●	●	◐	◐	○	○
M4: Lightmaps	●	●	●	◐	◐	○	○	✗	✗	✗
M5: Spherical Harm	●	●	●	●	●	●	◐	○	○	○
M6: Light Probes	●	●	●	●	●	◐	○	○	✗	✗
M7: Toon Shading	●	●	●	●	●	●	●	●	●	●
M8: Matcaps	●	●	●	●	●	●	●	●	●	●

Artistic Constraints

Technique	D1	D2	D3	D4	D5	D6	D7	D8	D9	D10
ART1: Single Primitive	○	◐	●	●	●	●	●	●	●	●
ART2: Single Palette	●	●	●	●	●	●	●	●	●	●
ART3: Low Resolution	●	●	●	●	●	●	●	●	●	●
ART4: Outline Only	◐	●	●	●	●	●	●	●	●	●
ART5: Silhouette Design	●	●	●	●	●	●	●	●	●	●

Immediate Mode Techniques

Technique	D1	D2	D3	D4	D5	D6	D7	D8	D9	D10
IM1: Ray March SDF	✗	✗	✗	○	◐	●	●	●	●	●
IM2: Compute→Render	✗	✗	○	◐	●	●	●	●	✗	✗
IM3: Uniform-Driven	✗	○	◐	●	●	●	●	●	●	✗
IM4: Screen-Space	◐	●	●	●	●	●	●	●	●	●
IM6: Fullscreen+Math	✗	✗	✗	○	◐	●	●	●	●	●
IM7: Instanced Proc	✗	○	◐	●	●	●	●	●	○	✗

Reading the Matrix

To find techniques for a specific spectrum position: Read down the column. ● and ◐ are viable choices.

To see how universal a technique is: Read across the row. More ● = more universal.

Most universal techniques (work everywhere):

C2: Quantization
M1: Flat/Unlit
M2: Lambert/Phong
M7: Toon Shading
M8: Matcaps
ART2: Single Palette
ART3: Low Resolution
ART5: Silhouette Design
R8: Software Rasterization (ironic but true)

Most position-specific techniques:

G6: Nanite (D1 only)
M4: Lightmaps (D1-D3 only)
G2: SDFs (D5-D10 only)
R2: Ray Marching (D5-D10 only)

Reference Appendix

This appendix provides search-based links to documentation, examples, papers, and tools. Using search links rather than direct URLs helps prevent link rot.

Search Link Format

All links use DuckDuckGo searches. Format: https://duckduckgo.com/?q=<search+terms>

Demoscene References

4KB/64KB Intros (Extreme Procedural)

Demoscene Tools

Signed Distance Fields (G2, R2)

Tutorials & Fundamentals

Advanced SDF Techniques

SDF in Games

Voxels (G4)

Algorithms

Voxel Games/Engines

Nanite / Virtualized Geometry (G6)

Gaussian Splatting / NeRF (G5, H2)

Procedural Generation (P1-P8)

Buildings & Architecture

Terrain

Vegetation

Noise Functions

Texture Compression (T1-T16)

GPU Formats

Procedural Textures

Virtual Texturing

Mesh Compression (G7)

Animation Compression (A3, A5)

Compute Shader Generation (P6, D8)

S-Expression / Lisp Shader Languages (SEXPR)

Shader Debugging & Development (DEB)

Engine Documentation

Godot

Unreal Engine

Unity

Research Papers

Rendering

SDFs & Ray Marching

Voxels

Compression

Procedural

WebGPU / WGSL

Audio (Bonus)

Code Size Reduction

Notable Talks & Presentations

Community Resources

Hardware & Software Requirements

This section catalogs the minimum hardware and API requirements for each technique, enabling filtering by target platform.

Requirement Tiers

Hardware Tiers

Tier	Name	GPU Examples	Era	Typical Use
HW0	Ancient	Intel GMA, GeForce 6/7	2004-2006	Retro, embedded
HW1	Old	GeForce 8/9, Radeon HD 2000-4000	2006-2009	Legacy support
HW2	Moderate	GeForce 400-600, Radeon HD 5000-7000	2010-2013	Wide compatibility
HW3	Modern	GeForce 900+, Radeon RX 400+, Intel UHD	2015-2019	Current mainstream
HW4	Current	GeForce RTX 20+, Radeon RX 6000+, Intel Arc	2020+	High-end features
HW5	Cutting Edge	RTX 40+, RX 7000+, with mesh shaders/RT	2022+	Newest features

Mobile Hardware Tiers

Tier	Name	GPU Examples	Era	Typical Use
MW0	Ancient Mobile	Adreno 200, Mali-400	2010-2013	Legacy devices
MW1	Old Mobile	Adreno 300, Mali-T600, PowerVR 6	2013-2015	Budget devices
MW2	Moderate Mobile	Adreno 500, Mali-G71, Apple A9	2016-2018	Mid-range
MW3	Modern Mobile	Adreno 600+, Mali-G77+, Apple A12+	2019+	Current phones
MW4	Current Mobile	Adreno 700+, Mali-G710+, Apple A15+	2021+	Flagship phones

Software/API Tiers

Tier	Name	APIs	Features
SW0	Legacy	OpenGL 2.1, ES 2.0, DX9	Fixed function fallbacks, basic shaders
SW1	Established	OpenGL 3.3, ES 3.0, DX10	Full programmable pipeline, instancing
SW2	Modern	OpenGL 4.3, ES 3.1, DX11	Compute shaders, tessellation
SW3	Explicit	Vulkan 1.0, DX12, Metal	Explicit memory, async compute
SW4	Cutting Edge	Vulkan 1.3, DX12 Ultimate, Metal 3	Mesh shaders, RT, variable rate shading

Spectrum Positions: Requirements

Position	Min HW	Min Mobile	Min SW	Notes
D1 (Full GPU Scene)	HW4	MW4	SW3	Requires advanced GPU-driven features
D2 (Retained + CPU Transform)	HW1	MW1	SW0	Standard retained mode, universal
D3 (Retained + Dynamic Mat)	HW1	MW1	SW0	Same as D2, just more uniform updates
D4 (GPU + CPU Feedback)	HW2	MW2	SW2	Needs query/readback support
D5 (Mixed Static/Dynamic)	HW1	MW1	SW1	Flexible, works broadly
D6 (CPU-Driven, Retained Buf)	HW1	MW1	SW0	Traditional approach, universal
D7 (Streaming)	HW1	MW1	SW1	Needs async loading capability
D8 (Per-Frame GPU Gen)	HW2	MW2	SW2	Needs compute shaders
D9 (Per-Frame CPU Rebuild)	HW0	MW0	SW0	Just needs basic drawing
D10 (CPU Software)	HW0	MW0	N/A	No GPU required

Technique Requirements Matrix

Geometry Techniques

Technique	Min HW	Min Mobile	Min SW	Compute	Mesh Shaders	RT	Notes
G1: Billboards	HW0	MW0	SW0	No	No	No	Universal, textured quads
G2: SDFs (analytical)	HW1	MW1	SW0	No	No	No	Just needs fragment shaders
G2: SDFs (baked 3D tex)	HW1	MW1	SW1	No	No	No	Needs 3D texture support
G3: Polygon Meshes	HW0	MW0	SW0	No	No	No	Universal baseline
G4: Voxels (CPU mesh)	HW0	MW0	SW0	No	No	No	Generate mesh on CPU
G4: Voxels (GPU raycst)	HW1	MW1	SW0	No	No	No	Fragment shader raycast
G4: Voxels (compute)	HW2	MW2	SW2	Yes	No	No	GPU mesh generation
G5: Gaussian Splats	HW3	MW3	SW2	Yes	No	No	Sorting, compute required
G6: Nanite-style	HW4	N/A	SW3	Yes	Opt	No	Software raster, clusters
G7: Mesh Compression	HW0	MW0	SW0	No	No	No	CPU decode, standard draw
G8: Implicit Noise	HW1	MW1	SW0	No	No	No	Fragment shader evaluation
G9: Subdivision	HW2	MW2	SW2	No	No	No	Needs tessellation shaders
G9: Subdivision (CPU)	HW0	MW0	SW0	No	No	No	Pre-subdivide on CPU
G10: Displacement	HW2	MW2	SW2	No	No	No	Needs tessellation
G10: Displacement (vtx)	HW1	MW1	SW1	No	No	No	Vertex texture fetch
G11: CSG (mesh)	HW0	MW0	SW0	No	No	No	CPU boolean operations
G11: CSG (SDF)	HW1	MW1	SW0	No	No	No	min/max in shader
G12: NURBS/Curves	HW0	MW0	SW0	No	No	No	CPU tessellation
G12: NURBS (GPU)	HW2	MW2	SW2	No	No	No	GPU tessellation
G13: Height Maps	HW0	MW0	SW0	No	No	No	Standard vertex displacement
G14: Sprite Stacking	HW0	MW0	SW0	No	No	No	Just 2D sprites
G15: Style Transfer	HW3	MW3	SW2	Yes	No	No	Neural network inference
G16: Geometry Images	HW1	MW1	SW1	No	No	No	Texture as geometry

Procedural Generation Techniques

Technique	Min HW	Min Mobile	Min SW	Compute	Notes
P1: Proc Buildings (CPU)	HW0	MW0	SW0	No	Generate mesh on CPU
P1: Proc Buildings (GPU)	HW2	MW2	SW2	Yes	Compute shader generation
P2: Proc Terrain (CPU)	HW0	MW0	SW0	No	Classic approach
P2: Proc Terrain (GPU)	HW2	MW2	SW2	Yes	Erosion simulation etc
P3: Proc Vegetation	HW0	MW0	SW0	No	L-system on CPU
P4: Proc Textures	HW1	MW1	SW0	No	Fragment shader noise
P5: Wang Tiles	HW0	MW0	SW0	No	Just texture sampling
P6: Compute Gen	HW2	MW2	SW2	Yes	Core requirement
P7: Grammar-Based	HW0	MW0	SW0	No	CPU-side parsing
P8: Fractals (2D)	HW0	MW0	SW0	No	Fragment shader
P8: Fractals (3D SDF)	HW1	MW1	SW0	No	Ray marching

Texture Techniques

Technique	Min HW	Min Mobile	Min SW	Compute	Notes
T1: BC1-BC5/DXT	HW0	N/A	SW0	No	Desktop standard
T1: ETC1	N/A	MW0	SW0	No	Android baseline
T1: ETC2	N/A	MW1	SW1	No	ES 3.0 required
T1: ASTC	HW3	MW2	SW2	No	Modern mobile standard
T1: BC6H/BC7	HW2	N/A	SW1	No	DX11+ HDR/quality
T2: Basis Universal	HW0	MW0	SW0	No	Transcodes to platform format
T3: Atlasing	HW0	MW0	SW0	No	Universal
T4: Virtual Texturing	HW2	MW2	SW2	Opt	Page table management
T5: Tex Synthesis	HW1	MW1	SW1	No	Fragment shader
T6: Procedural Tex	HW1	MW1	SW0	No	Pure shader
T7: Triplanar	HW0	MW0	SW0	No	3x texture sample
T8: Palette-Based	HW0	MW0	SW0	No	Texture indirection
T9: Polynomial	HW1	MW1	SW0	No	Shader math
T10: Fourier/DCT	HW1	MW1	SW0	No	Shader reconstruction
T11: Neural Compress	HW3	MW3	SW2	Yes	Network inference
T12: Detail Textures	HW0	MW0	SW0	No	Multi-texture blend
T14: Material ID	HW0	MW0	SW0	No	Texture lookup

Rendering Paradigms

Technique	Min HW	Min Mobile	Min SW	Compute	RT	Notes
R1: Forward	HW0	MW0	SW0	No	No	Universal baseline
R2: Ray Marching	HW1	MW1	SW0	No	No	Fragment shader loops
R3: Voxel Raycast	HW1	MW1	SW0	No	No	Fragment shader
R4: Particles (CPU)	HW0	MW0	SW0	No	No	Upload each frame
R4: Particles (GPU)	HW2	MW2	SW2	Yes	No	Compute update
R5: Deferred	HW1	MW1	SW1	No	No	MRT support needed
R5: Deferred (mobile)	HW2	MW2	SW1	No	No	Bandwidth concerns
R6: Forward+	HW2	MW2	SW2	Yes	No	Compute light culling
R7: Hybrid RT	HW4	N/A	SW4	Yes	Yes	RT cores/software
R8: Software Raster	HW2	MW2	SW2	Yes	No	Compute shader
R9: PRT/Lightmaps	HW0	MW0	SW0	No	No	Just textures

Compression & Encoding

Technique	Min HW	Min Mobile	Min SW	Notes
C1: Delta Encoding	HW0	MW0	SW0	CPU decode
C2: Quantization	HW0	MW0	SW0	Universal
C3: Octree	HW0	MW0	SW0	CPU traversal
C3: Octree (GPU)	HW2	MW2	SW2	Compute traversal
C4: Run-Length	HW0	MW0	SW0	CPU decode
C5: LZ-family	HW0	MW0	SW0	CPU decode
C6: Entropy Coding	HW0	MW0	SW0	CPU decode
C7: Sparse Voxel DAG	HW2	MW2	SW2	GPU traversal preferred
C8: PCA/SVD	HW0	MW0	SW0	CPU or shader reconstruct

LOD & Streaming

Technique	Min HW	Min Mobile	Min SW	Compute	Notes
L1: Discrete LOD	HW0	MW0	SW0	No	Universal
L2: Continuous LOD	HW1	MW1	SW1	No	Vertex shader
L2: CDLOD/Geoclipmaps	HW1	MW1	SW1	No	Terrain specific
L3: HLOD	HW0	MW0	SW0	No	Pre-merged meshes
L4: Impostor LOD	HW0	MW0	SW0	No	Billboard fallback
L5: Streaming	HW0	MW0	SW0	No	Async loading

Animation Techniques

Technique	Min HW	Min Mobile	Min SW	Compute	Notes
A1: Keyframe	HW0	MW0	SW0	No	Universal
A2: Skeletal (CPU)	HW0	MW0	SW0	No	CPU skinning
A2: Skeletal (GPU)	HW1	MW1	SW1	No	Vertex shader skinning
A3: Anim Compression	HW0	MW0	SW0	No	CPU decode
A4: Procedural Anim	HW0	MW0	SW0	No	CPU or shader
A5: VAT	HW1	MW1	SW1	No	Vertex texture fetch
A6: Morph Targets	HW0	MW0	SW0	No	Blend on CPU or GPU
A7: Bone Baking	HW0	MW0	SW0	No	Pre-process
A8: Flipbook	HW0	MW0	SW0	No	UV animation

Lighting & Materials

Technique	Min HW	Min Mobile	Min SW	Compute	Notes
M1: Flat/Unlit	HW0	MW0	SW0	No	Universal
M2: Lambert/Phong	HW0	MW0	SW0	No	Universal
M3: PBR	HW1	MW1	SW1	No	IBL needs cubemaps
M4: Lightmaps	HW0	MW0	SW0	No	Just textures
M5: Spherical Harm	HW0	MW0	SW0	No	Shader eval
M6: Light Probes	HW0	MW0	SW0	No	Sample and apply
M7: Toon Shading	HW0	MW0	SW0	No	Simple shader
M8: Matcaps	HW0	MW0	SW0	No	View-space UV

Shader/Immediate Mode Techniques

Technique	Min HW	Min Mobile	Min SW	Compute	Notes
S1: Domain Repetition	HW1	MW1	SW0	No	Shader fract/mod
S2: Shader Deform	HW0	MW0	SW0	No	Vertex shader
S3: Parallax Mapping	HW1	MW1	SW0	No	Fragment shader loops
S4: Screen-Space FX	HW1	MW1	SW1	No	Post-process
S5: SDF Blending	HW1	MW1	SW0	No	Shader math
S6: Raymarching Opt	HW1	MW1	SW0	No	Better algorithms
IM1: Raymarch SDF	HW1	MW1	SW0	No	Full-screen quad
IM2: Compute→Render	HW2	MW2	SW2	Yes	Compute required
IM3: Uniform-Driven	HW1	MW1	SW1	No	Instancing helps
IM6: Fullscreen+Math	HW1	MW1	SW0	No	Pure fragment
IM7: Instanced Proc	HW1	MW1	SW1	No	Instancing required

Debugging & Development

Technique	Min HW	Min Mobile	Min SW	Notes
DEB1: Pixel Trace	HW2	MW2	SW2	Compute or debug shader
DEB2: Hot Reload	HW0	MW0	SW0	Runtime shader compile
DEB3: Debug HUDs	HW0	MW0	SW0	UI overlay
DEB4: Value→Color	HW0	MW0	SW0	Shader modification
DEB5: Time Travel	HW0	MW0	SW0	State recording
DEB6: Diff Rendering	HW1	MW1	SW1	Dual render targets
DEB7: Shader Profiling	HW2	MW2	SW2	Vendor-specific tools

API Feature Requirements Detail

OpenGL / OpenGL ES Version Mapping

Feature	GL	GL ES	DX	Vulkan	Metal	Notes
Basic shaders	2.0	2.0	9	1.0	1.0	GLSL 1.10+
Instancing	3.1	3.0	10	1.0	1.0	Draw call reduction
MRT (deferred)	2.0	3.0	9	1.0	1.0	Multiple render targets
3D Textures	1.2	3.0	10	1.0	1.0	Volume data
Texture arrays	3.0	3.0	10	1.0	1.0	Atlasing alternative
Floating point tex	3.0	3.0	10	1.0	1.0	HDR, data textures
Integer textures	3.0	3.0	10	1.0	1.0	ID buffers
Geometry shaders	3.2	3.2*	10	1.0	N/A	*ES extension
Tessellation	4.0	3.2*	11	1.0	1.0	*ES extension
Compute shaders	4.3	3.1	11	1.0	1.0	GPGPU
SSBO	4.3	3.1	11	1.0	1.0	Large buffers
Indirect draw	4.0	3.1	11	1.0	1.0	GPU-driven
Bindless textures	4.4*	N/A	N/A	1.0*	N/A	*Extension
Mesh shaders	N/A	N/A	12U	1.2*	3.0	*Extension
Ray tracing	N/A	N/A	12U	1.2*	3.0	*Extension
Variable rate shading	N/A	N/A	12U	1.2*	2.0	*Extension

Mobile-Specific Considerations

Concern	Impact	Techniques Affected
Bandwidth	Deferred rendering expensive	R5, T4
Fill rate	Complex fragment shaders hurt	R2, P4, IM1
Thermal	Sustained compute throttles	All compute-heavy
Memory	Limited VRAM	T4, G6, large textures
Precision	mediump/lowp required	P4, T6 (precision issues)
Tile-based	Different perf characteristics	R5 (can help), MRT
No geometry shaders	Many devices lack support	G9 (hardware tess)

Platform Compatibility Quick Reference

"Works Everywhere" Techniques (HW0/MW0 + SW0)

These techniques work on virtually any GPU from the last 20 years:

Geometry:

G1: Billboards
G3: Polygon Meshes
G7: Mesh Compression (CPU decode)
G11: CSG (mesh booleans)
G13: Height Maps
G14: Sprite Stacking

Textures:

T2: Basis Universal (transcodes)
T3: Atlasing
T7: Triplanar Mapping
T8: Palette-Based
T12: Detail Textures
T14: Material ID

Rendering:

R1: Forward Rendering
R4: Particles (CPU)
R9: Lightmaps/PRT

Animation:

A1: Keyframe
A2: Skeletal (CPU skinning)
A6: Morph Targets
A8: Flipbook

Lighting:

M1: Flat/Unlit
M2: Lambert/Phong
M4: Lightmaps
M7: Toon Shading
M8: Matcaps

LOD:

L1: Discrete LOD
L3: HLOD
L4: Impostor LOD
L5: Streaming

"Modern Baseline" Techniques (HW2/MW2 + SW2)

These require compute shaders and are the current mainstream:

Geometry:

G4: Voxels (compute generation)
G5: Gaussian Splats
G9: Subdivision (GPU tessellation)
G10: Displacement (GPU)

Procedural:

P1: Proc Buildings (GPU)
P2: Proc Terrain (GPU erosion)
P6: Compute Generation

Textures:

T4: Virtual Texturing
T11: Neural Compression

Rendering:

R4: Particles (GPU compute)
R6: Forward+
R8: Software Rasterization

Compression:

C7: Sparse Voxel DAG (GPU)

"Cutting Edge" Techniques (HW4+ / SW4)

These require latest hardware:

Geometry:

G6: Nanite-style (mesh shaders help)

Rendering:

R7: Hybrid Ray Tracing

Features used:

Mesh shaders
Hardware ray tracing
Variable rate shading
Advanced async compute

WebGL Compatibility Notes

WebGL has specific limitations that affect technique viability:

WebGL Version	Equivalent	Key Limitations
WebGL 1.0	ES 2.0	No 3D textures, no instancing, no MRT, limited precision
WebGL 2.0	ES 3.0	No compute shaders, no geometry shaders, no tessellation
WebGPU	Vulkan-like	Compute shaders, modern features, still emerging

*Extensions may provide some features

WebGL 1.0 Compatible Techniques:

All "Works Everywhere" techniques
Basic SDF ray marching (IM1, R2)
Procedural textures (P4, T6)
Simple noise functions

WebGL 2.0 Additional:

3D textures (baked SDFs)
Instancing (IM7)
Transform feedback
MRT (deferred shading)

Requires WebGPU:

Any compute-based generation
Modern particle systems
GPU-driven rendering

VR-Specific Requirements

VR adds additional constraints:

Requirement	Impact	Affected Techniques
90+ FPS	Halves frame budget	All compute-heavy techniques
Stereo rendering	2x geometry	G6 helps, G2/R2 hurt (2x rays)
Low latency	No heavy post-process	S4 (limited), R7
Reprojection	Needs depth	R2 must output depth
Foveated rendering	Helps perf	Works with most techniques
Single-pass stereo	Needs instancing	Requires SW1+

VR-Friendly:

G6 (Nanite) - geometry efficient
R1 (Forward) - low latency
M4 (Lightmaps) - cheap GI
L1-L4 (LOD) - essential

VR-Challenging:

R2 (Ray marching) - 2x cost for stereo
R5 (Deferred) - bandwidth on mobile VR
Heavy post-processing

Recommended Minimum Targets by Project Type

Project Type	Target HW	Target Mobile	Target SW	Key Techniques
Demoscene 4KB	HW1	N/A	SW0	G2, R2, P4, T6, IM1
Indie (wide reach)	HW1	MW1	SW1	G3, R1, T1, A2, L1
Indie (stylized)	HW1	MW1	SW1	G1, M7, ART*
Mobile game	HW2	MW2	SW1	G3, R1, T1 (ASTC), M4
PC mid-range	HW2	N/A	SW2	P6, R6, T4
PC high-end	HW3	N/A	SW3	G6, R7, T11
VR (standalone)	HW3	MW3	SW2	G3, R1, M4, L1-4
VR (PC)	HW4	N/A	SW3	G6, R1, L1
Web (broad)	HW1	MW1	WebGL2	G3, R1, P4, A2
Web (modern)	HW3	MW3	WebGPU	P6, R2, more

Interactive Filter Criteria (for future website)

The website should allow filtering by:

Hardware:

[ ] Ancient (HW0/MW0) - 2006 and earlier
[ ] Old (HW1/MW1) - 2006-2012
[ ] Moderate (HW2/MW2) - 2012-2018
[ ] Modern (HW3/MW3) - 2018-2022
[ ] Current (HW4/MW4) - 2022+
[ ] Cutting Edge (HW5) - Latest features

Platform:

[ ] Desktop (Windows/Mac/Linux)
[ ] Mobile (iOS/Android)
[ ] Web (WebGL 1.0)
[ ] Web (WebGL 2.0)
[ ] Web (WebGPU)
[ ] VR (Standalone)
[ ] VR (PC-tethered)
[ ] Console (current gen)
[ ] Console (last gen)

API:

[ ] OpenGL 2.1 / ES 2.0 / DX9
[ ] OpenGL 3.3 / ES 3.0 / DX10
[ ] OpenGL 4.3 / ES 3.1 / DX11
[ ] Vulkan / DX12 / Metal
[ ] Vulkan 1.3 / DX12 Ultimate / Metal 3

Required Features:

[ ] Compute shaders
[ ] Tessellation
[ ] Geometry shaders
[ ] Mesh shaders
[ ] Ray tracing
[ ] Bindless textures
[ ] Indirect draw
[ ] 3D textures

Spectrum Position:

[ ] D1-D3 (Retained)
[ ] D4-D6 (Mixed)
[ ] D7-D10 (Immediate)

When user selects constraints, techniques that don't meet requirements are grayed out or hidden, and the compatibility matrix updates to show only viable combinations.

Offline / Online & Interactivity

This section addresses the temporal dimension of when computation happens and how mutable/interactive the results can be.

The Two Axes

                        INTERACTIVITY
                             │
            Static ◄─────────┼─────────► Fully Interactive
         (view only)         │         (modify anything)
                             │
    ─────────────────────────┼─────────────────────────────
                             │
         Offline ◄───────────┼───────────► Online
       (precompute)     COMPUTATION      (realtime)
                          TIMING

Computation Timing (Offline ↔ Online):

Offline: Computed before runtime (build time, bake time, preprocessing)
Online: Computed during runtime (per-frame, on-demand)

Interactivity (Static ↔ Interactive):

Static: Cannot be modified at runtime (view/playback only)
Interactive: Can be modified by user/gameplay in real-time

Key insight: Online enables interactive, but doesn't guarantee it. You can compute something every frame that the user can't meaningfully change.

Computation Timing Spectrum

Tier	Name	When	Latency	Examples
CT0	Build-time	Asset pipeline	Minutes-hours	Lightmaps, LOD generation, mesh compression
CT1	Load-time	Game startup/level load	Seconds	Shader compilation, texture transcoding
CT2	Streaming	Background during play	100ms-seconds	Terrain chunks, texture streaming
CT3	Per-frame	Every frame	16ms budget	Standard rendering, animation
CT4	Per-pixel/vertex	Shader execution	Microseconds	Procedural textures, SDF evaluation
CT5	Per-interaction	On user input	<100ms for feel	Physics response, terrain deformation

Interactivity Levels

Level	Name	Description	Examples
I0	Fully Static	Cannot change at all	Pre-rendered video, baked lightmaps
I1	View Interactive	Camera/viewpoint changes only	Architectural walkthrough, photo viewer
I2	Parameter Interactive	Tweak predefined parameters	Color grading, time-of-day slider
I3	Object Interactive	Move/modify discrete objects	Standard game objects, physics
I4	Content Interactive	Add/remove/reshape content	Voxel editing, terrain sculpting
I5	Fully Generative	Create anything in real-time	Live coding, Dreams PS4 sculpting

The Precomputation Trade-off

More Precomputation ───────────────────────► Less Precomputation
                                            
    ┌─────────────────────────────────────────────────────────┐
    │ OFFLINE                          │ ONLINE               │
    │                                  │                      │
    │ • Higher quality possible        │ • Lower quality      │
    │ • More computation time          │ • Strict time budget │
    │ • Results are static             │ • Results can change │
    │ • Storage cost for results       │ • Compute cost       │
    │ • Iteration requires rebake      │ • Instant iteration  │
    │ • Works on weak runtime HW       │ • Needs strong HW    │
    └─────────────────────────────────────────────────────────┘

The fundamental trade-off:

Precompute more → Higher quality, less interactive
Precompute less → Lower quality (or higher HW req), more interactive

Precomputation Techniques Catalog

PRE1: Texture Mipmapping

Description: Pre-generate filtered lower-resolution versions of textures.

Computation Timing: CT0 (build-time) or CT1 (load-time) Interactivity Impact: None - transparent optimization Storage Cost: +33% texture size Runtime Benefit: Proper filtering, reduced bandwidth, fewer artifacts

What it enables:

Correct minification filtering
Anisotropic filtering quality
Reduced aliasing
Texture streaming (load lower mips first)

Without it: Runtime would need to filter on-the-fly (expensive) or accept aliasing.

Works with: All texture-based techniques Engine support: Universal, automatic

PRE2: Lightmap Baking

Description: Pre-compute global illumination, shadows, ambient occlusion into textures.

Computation Timing: CT0 (build-time), minutes to hours Interactivity Impact: I0-I1 (lighting is static, can only move camera/dynamic objects) Storage Cost: Significant (often largest asset) Runtime Benefit: Complex GI "for free" at runtime

What it enables:

Path-traced quality GI
Soft shadows from area lights
Multiple bounce illumination
Works on mobile/low-end

Without it: Need runtime GI (expensive) or accept flat lighting.

Variants:

Directional lightmaps (store dominant direction)
Radiosity normal mapping (store for multiple directions)
Spherical harmonic lightmaps

Limitations:

Static geometry only
UV unwrapping required
Long bake times
Large storage

Works with: M4, R9, any static environment Does not work with: Fully dynamic scenes, destructible geometry

PRE3: LOD Generation

Description: Pre-generate simplified mesh versions for distance rendering.

Computation Timing: CT0 (build-time) Interactivity Impact: None - transparent optimization Storage Cost: ~50-100% additional mesh data Runtime Benefit: Massive triangle reduction at distance

Approaches:

Mesh decimation (Simplygon, MeshLab)
Manual artist LODs
Automatic edge collapse
Impostor baking (billboard from mesh)

What it enables:

Draw millions of objects at distance
Consistent frame rate across view distances
Lower memory bandwidth

Works with: L1, L3, L4, standard mesh workflows Does not work with: Fully procedural geometry (must regenerate or cache)

PRE4: Shader Compilation / Permutation Baking

Description: Pre-compile shader variants for all material/feature combinations.

Computation Timing: CT0 (build-time) or CT1 (load-time) Interactivity Impact: None - transparent Storage Cost: Can be huge (permutation explosion) Runtime Benefit: No shader compilation stalls

Problem it solves: Runtime shader compilation causes frame hitches.

Approaches:

Compile all permutations offline
Shader warmup passes at load time
Pipeline state object caching (Vulkan/DX12)
Shader precompilation (Metal)

Challenges:

Permutation explosion (N features → 2^N shaders)
Platform-specific compilation
Update requires rebuild

PRE5: Navigation Mesh Generation

Description: Pre-compute walkable surface representation for AI pathfinding.

Computation Timing: CT0 (build-time) Interactivity Impact: I0-I3 (navmesh is static, but objects can move on it) Storage Cost: Small-moderate Runtime Benefit: Fast pathfinding

What it enables:

A* pathfinding at scale
AI navigation
Crowd simulation

Dynamic alternatives:

Runtime navmesh generation (CT3) - expensive but allows destruction
Hierarchical pathfinding
Flow fields

PRE6: Physics Collision Mesh Simplification

Description: Pre-generate simplified collision geometry from render mesh.

Computation Timing: CT0 (build-time) Interactivity Impact: Physics is interactive (I3), but collision shape is static Storage Cost: Small Runtime Benefit: Fast collision detection

Approaches:

Convex hull decomposition
Simplified proxy meshes
Primitive fitting (boxes, capsules, spheres)
Bounding volume hierarchies

PRE7: Ambient Occlusion Baking

Description: Pre-compute per-vertex or texture-space ambient occlusion.

Computation Timing: CT0 (build-time) Interactivity Impact: I0-I1 (AO is static) Storage Cost: Per-vertex: small. Texture: moderate Runtime Benefit: High-quality AO without SSAO cost

Variants:

Vertex AO (per-vertex float)
Texture AO (dedicated channel)
Bent normal baking (AO direction)

Runtime alternative: SSAO, GTAO, HBAO (CT3)

PRE8: SDF Volume Baking

Description: Pre-compute signed distance field in 3D texture from mesh.

Computation Timing: CT0 (build-time), can be slow Interactivity Impact: I0-I1 (SDF is static, but enables dynamic queries) Storage Cost: Moderate-high (3D texture) Runtime Benefit: Fast distance queries, soft shadows, AO

What it enables:

Mesh → SDF conversion for hybrid rendering
Soft shadows from SDF
Global distance field (UE5)
Collision detection acceleration

Tools:

SDFGen, mesh-to-sdf utilities
Raytraced SDF baking
Jump flooding algorithm

Works with: G2 (as alternative to analytical SDF), H5 (hybrid)

PRE9: Visibility / PVS Baking

Description: Pre-compute which areas can see which other areas.

Computation Timing: CT0 (build-time), can be hours Interactivity Impact: I0-I1 (visibility is static) Storage Cost: Moderate Runtime Benefit: Instant occlusion culling

What it enables:

Skip rendering of guaranteed-hidden objects
Reduce draw calls dramatically in interiors
Enable streaming decisions

Classic approach: Potentially Visible Sets (Quake-era) Modern: GPU occlusion queries, hierarchical Z-buffer (online)

Works with: Indoor environments, levels with walls Does not work with: Open worlds, destructible environments

PRE10: Texture Compression

Description: Pre-compress textures to GPU-friendly formats.

Computation Timing: CT0 (build-time) Interactivity Impact: None - transparent Storage Cost: Reduced (that's the point) Runtime Benefit: Lower memory, faster sampling

Formats: BC1-7, ASTC, ETC1/2 (see T1)

Why offline: Quality compression (BC7, ASTC) is slow. Runtime transcoding (Basis) is faster but still CT1.

PRE11: Animation Compression

Description: Pre-compress animation curves, removing redundancy.

Computation Timing: CT0 (build-time) Interactivity Impact: None - animation plays back identically Storage Cost: Reduced Runtime Benefit: Lower memory, potentially faster playback

Techniques:

Curve fitting
Keyframe reduction
Quantization
Delta encoding
ACL library

PRE12: Impostor / Billboard Baking

Description: Pre-render 3D object from multiple angles to use as billboard.

Computation Timing: CT0 (build-time) Interactivity Impact: I0-I1 (impostor is static representation) Storage Cost: Texture atlas per object Runtime Benefit: Render complex objects as single quad

Variants:

Simple billboard (1 view)
Octahedral impostor (8-24 views, interpolate)
Spherical impostor (full sphere of views)

What it enables:

Massive forests, crowds at distance
Complex objects as LOD fallback

Works with: L4, G1

PRE13: Convolution / Cubemap Preprocessing

Description: Pre-filter environment maps for different roughness levels.

Computation Timing: CT0 or CT1 Interactivity Impact: I0-I1 (environment is static) Storage Cost: Moderate (mip chain of cubemaps) Runtime Benefit: PBR specular IBL at single texture sample

What it enables:

Split-sum IBL approximation
Roughness-correct reflections
Single-sample specular

Without it: Would need importance sampling at runtime (expensive).

Related: Pre-integrated BRDF LUT

PRE14: Mesh Optimization / Vertex Cache Optimization

Description: Pre-reorder vertices and indices for GPU cache efficiency.

Computation Timing: CT0 (build-time) Interactivity Impact: None - transparent Storage Cost: None (same data, different order) Runtime Benefit: Better GPU cache utilization, faster rendering

Tools: meshoptimizer, AMD Tootle, Forsyth algorithm

Should always do this: Free performance, no downside.

PRE15: Occlusion Data Baking (Per-Object)

Description: Pre-compute occlusion contribution of objects for culling hints.

Computation Timing: CT0 (build-time) Interactivity Impact: I0-I3 (objects can move, but their occlusion properties are static) Storage Cost: Small per object Runtime Benefit: Better culling decisions

Example: Mark objects as "large occluder" or "never occludes"

PRE16: Terrain Erosion Simulation

Description: Pre-simulate hydraulic/thermal erosion on heightmap terrain.

Computation Timing: CT0 (build-time), minutes Interactivity Impact: I0-I1 (terrain is static) Storage Cost: Just heightmap Runtime Benefit: Realistic terrain without runtime simulation

Can be online: GPU erosion simulation exists but expensive.

Works with: P2, G13

PRE17: Procedural Content Caching / Baking

Description: Run procedural generation offline, store results.

Computation Timing: CT0 (build-time) or CT1 (load-time, seed-based) Interactivity Impact: I0-I2 (can't modify the generation, only parameters) Storage Cost: Full generated content Runtime Benefit: Use procedural algorithms that are too slow for real-time

Pattern:

Offline: Run expensive procedural algorithm
         Store result as static asset
Online:  Load and use as normal mesh/texture

Enables: Complex generation algorithms (expensive erosion, multi-pass synthesis) Loses: Runtime variation, interactivity

PRE18: Cluster / Meshlet Generation

Description: Pre-divide meshes into GPU-friendly clusters for culling.

Computation Timing: CT0 (build-time) Interactivity Impact: None - transparent Storage Cost: Additional index data Runtime Benefit: Enables per-cluster culling, mesh shaders

Required for: G6 (Nanite-style), mesh shader pipelines Tools: meshoptimizer, Nanite importer

PRE19: BVH / Acceleration Structure Building

Description: Pre-build bounding volume hierarchies for ray tracing or collision.

Computation Timing: CT0 (static) or CT3 (dynamic, for RT) Interactivity Impact: Varies - static BVH = I0, dynamic rebuild = I3+ Storage Cost: Moderate Runtime Benefit: Fast ray-geometry intersection

For ray tracing: Modern RT APIs build/update AS at runtime, but static geometry can pre-build.

PRE20: Voxelization

Description: Pre-convert mesh to voxel representation.

Computation Timing: CT0 (build-time) Interactivity Impact: I0-I1 (voxels are static) Storage Cost: Depends on resolution Runtime Benefit: Enables voxel-based algorithms (GI, AO)

What it enables:

Voxel cone tracing GI
SDF from voxels
Collision acceleration

Technique Classification: Offline / Online / Interactivity

Geometry Techniques

Technique	Typical Timing	Can Be Precomputed?	Interactivity Level	Notes
G1: Billboards	CT3	Yes (PRE12)	I1-I3	Pre-bake for static, dynamic for characters
G2: SDFs (analytical)	CT4	N/A (pure math)	I2-I5	Inherently online, fully interactive
G2: SDFs (baked)	CT0 (PRE8)	Yes	I0-I1	Trade interactivity for quality
G3: Meshes	CT0	Yes (standard)	I0-I3	Static meshes + dynamic transforms
G4: Voxels	CT0-CT3	Partially	I0-I5	Minecraft: online editable
G5: Gaussian Splats	CT0	Yes (captured)	I0-I1	Mostly for captured content
G6: Nanite	CT0 (PRE18)	Yes (required)	I1-I3	Clustering must be offline
G7: Mesh Compression	CT0	Yes (required)	N/A	Compression is inherently offline
G8: Implicit Noise	CT4	Can cache (PRE17)	I2-I5	Online by nature
G9: Subdivision	CT0 or CT3	Yes (pre-subdivide)	I1-I3	Runtime tess or pre-subdivide
G10: Displacement	CT0 or CT3	Yes (bake to mesh)	I1-I3	Similar to subdivision
G11: CSG	CT0 or CT4	Yes (bake) or No (SDF)	I0-I5	Baked mesh vs real-time SDF
G13: Height Maps	CT0 or CT3	Usually yes	I0-I4	Editable terrain possible

Procedural Techniques

Technique	Typical Timing	Can Be Precomputed?	Interactivity Level	Notes
P1: Proc Buildings	CT0-CT2	Yes, commonly	I0-I2	Generate at build/load time
P2: Proc Terrain	CT0-CT3	Yes, but loses variety	I0-I4	Online enables infinite terrain
P3: Proc Vegetation	CT0-CT1	Yes	I0-I2	Generate on load
P4: Proc Textures	CT4	Can bake (PRE17)	I2-I4	Baking loses runtime variation
P5: Wang Tiles	CT0	Yes	I0-I2	Tiles themselves are precomputed
P6: Compute Gen	CT3	Defeats purpose	I3-I5	Point is runtime generation
P7: Grammar-Based	CT0-CT2	Yes	I0-I2	Usually generate on load
P8: Fractals	CT4	Can bake	I2-I5	Usually online for interaction

Texture Techniques

Technique	Typical Timing	Can Be Precomputed?	Interactivity Level	Notes
T1: GPU Compression	CT0 (PRE10)	Required	N/A	Must be offline
T2: Supercompression	CT0	Required	N/A	Offline compress, runtime transcode
T3: Atlasing	CT0	Yes	N/A	Build-time packing
T4: Virtual Texturing	CT0+CT2	Tiles precomputed	I1	Streaming is online, content is static
T5: Tex Synthesis	CT0 or CT3	Can pre-synthesize	I0-I3	Offline: quality. Online: variation
T6: Procedural Tex	CT4	Can bake (PRE17)	I2-I5	Bake for mobile, online for PC
T7: Triplanar	CT4	No (it's a mapping)	I1-I3	Online projection
T8: Palette-Based	CT0	Yes	I2-I3	Palette can change at runtime
T9-T10: Polynomial/DCT	CT0	Yes (encode offline)	I0-I2	Encoding is offline
T11: Neural	CT0	Required (training)	I0-I1	Training is very offline
T12: Detail Textures	CT0	Yes	I1	Standard textures

Rendering Paradigms

Technique	Typical Timing	Can Be Precomputed?	Interactivity Level	Notes
R1: Forward	CT3	No	I3	Online rendering
R2: Ray Marching	CT3-CT4	Not typically	I3-I5	Online, enables interactivity
R5: Deferred	CT3	No	I3	Online rendering
R7: Ray Tracing	CT3	AS can be static	I3-I5	Mix of precomputed AS + online tracing
R9: PRT/Lightmaps	CT0 (PRE2)	Required	I0-I1	Precomputation is the point

Lighting & Materials

Technique	Typical Timing	Can Be Precomputed?	Interactivity Level	Notes
M1-M3: Direct Lighting	CT3-CT4	No	I3	Online by nature
M4: Lightmaps	CT0 (PRE2)	Required	I0-I1	Static lighting
M5: SH Probes	CT0 or CT3	Usually yes	I0-I2	Bake probes, sample at runtime
M6: Light Probes	CT0	Usually yes	I0-I2	Same as SH
M7-M8: Toon/Matcap	CT3-CT4	No	I3	Simple online shading

Animation

Technique	Typical Timing	Can Be Precomputed?	Interactivity Level	Notes
A1: Keyframe	CT0+CT3	Data is precomputed	I0-I3	Data offline, playback online
A2: Skeletal	CT0+CT3	Rig offline, skinning online	I0-I3	Mix
A4: Procedural	CT3	Defeats purpose	I3-I5	Online is the point
A5: VAT	CT0	Required	I0-I2	Bake simulation to texture

Precomputation in the Demoscene

Demoscene has a unique relationship with precomputation because executable size is limited:

What demoscene precomputes (at build time):

Shader minification
Executable packing
Music pattern data
Nothing else (no room for baked data!)

What demoscene computes at runtime:

All geometry (SDFs, procedural)
All textures (procedural noise, patterns)
All animation (procedural, sync to music)
Everything else

The demoscene philosophy: Precomputation requires storage. Extreme size limits push everything online. The "compression" is the algorithm itself.

Research insight: Demoscene techniques prove what's achievable with zero precomputation, establishing the lower bound of quality at any given runtime budget.

Precomputation Strategy by Project Type

Project Type	Precomputation Budget	Online Budget	Strategy
Mobile game	High	Low	Bake everything possible (lightmaps, LODs, compressed textures)
PC indie	Moderate	Moderate	Balance: bake lighting, runtime procedural details
AAA	Very high	High	Massive baking + runtime enhancements
VR	High	Very low	Extreme precomputation due to 90fps requirement
Demoscene	None	All	Everything runtime procedural
Arch viz	Very high	Low	Pre-render quality, runtime just navigation
Procedural game	Low	High	Minimal precompute to enable runtime generation
Live performance	None	All	Everything must be real-time interactive

Interactive Filter Additions (for website)

Add these filters to the interactive website:

Computation Timing:

[ ] Build-time only (CT0)
[ ] Load-time acceptable (CT0-CT1)
[ ] Streaming/background OK (CT0-CT2)
[ ] Must be per-frame (CT3+)
[ ] Must be per-pixel/procedural (CT4)

Interactivity Required:

[ ] Static is fine (I0)
[ ] View-only interactive (I1)
[ ] Parameter tweaking (I2)
[ ] Object manipulation (I3)
[ ] Content editing (I4)
[ ] Full generative (I5)

Precomputation Constraints:

[ ] No storage for precomputed data (demoscene)
[ ] Limited storage (mobile)
[ ] Moderate storage OK (PC indie)
[ ] Unlimited storage (AAA)

Cross-Reference: Precomputation × Hardware

Some precomputation can offload runtime requirements:

If you precompute...	You can reduce runtime to...	HW savings
Lightmaps (PRE2)	Texture sample	HW2 → HW0
LODs (PRE3)	LOD selection	N/A (always needed)
SDFs (PRE8)	3D texture sample	HW2 → HW1
Impostors (PRE12)	Billboard render	HW3 → HW0
Procedural content (PRE17)	Static mesh	HW2 → HW0
Erosion (PRE16)	Heightmap sample	HW2 → HW0

Pattern: Heavy precomputation can enable running on weaker hardware by trading storage for compute.

Cross-Reference: Precomputation × Spectrum Position

Spectrum Position	Precomputation Role	Notes
D1-D2 (Retained)	Heavy precomputation expected	Data loaded once, used many times
D3-D4 (Mixed)	Moderate precomputation	Static data + dynamic updates
D5-D6 (Flexible)	Optional precomputation	Can go either way
D7-D8 (Streaming/Generating)	Minimal precomputation	Data computed on demand
D9-D10 (Immediate)	No precomputation	Everything computed per-frame

Geometry Representation

G1: Billboards / Impostors

Description: Replace 3D geometry with camera-facing 2D planes textured with pre-rendered or stylized images.

Variants:

Simple billboards (always face camera)
Axial billboards (rotate around one axis, e.g., trees)
Octahedral impostors (8-12 pre-rendered views, blend between)
Spherical impostors (full sphere of views)

Works well with:

G15 (Style transfer post-processing)
T3 (Texture atlasing)
T8 (Palette-based textures)
R4 (Particle systems)
L2 (Distance-based LOD)

Does not work well with:

R2 (Ray marching SDFs) - fundamentally different paradigm
G4 (Voxels) - conflicting representations
A2 (Skeletal animation) - billboards lack skeletal structure
Lighting that requires normal information (unless using normal maps)

G2: Signed Distance Fields (SDFs)

Description: Represent geometry as mathematical functions returning distance to nearest surface. Rendered via ray marching.

Variants:

Analytical SDFs (pure math functions)
Baked SDF textures (3D textures storing distances)
Hybrid (analytical + baked details)

Works well with:

P1 (Procedural geometry via CSG operations)
S1 (Domain repetition for instancing)
S5 (Smooth blending between shapes)
R2 (Ray marching renderer)
T7 (Triplanar mapping)
A4 (Procedural animation)

Does not work well with:

G3 (Traditional polygon meshes) - different pipeline
G6 (Nanite-style virtualized geometry)
Hardware tessellation
Traditional rasterization pipeline
Existing game engine workflows

Engine Compatibility:

Godot: ★★★☆☆ - Custom shader + render pass, doable with GDExtension
Unreal: ★★☆☆☆ - Post-process material (limited) or engine mod (hard)
Unity: ★★★☆☆ - Custom RenderFeature in SRP, reasonable

Spectrum Position: D8-D10 (inherently immediate mode)

G3: Traditional Polygon Meshes (Baseline)

Description: Standard triangle/quad meshes. Included for compatibility reference.

Works well with:

Most standard techniques
G6 (Nanite instancing)
A1, A2, A3 (Standard animation)
All standard texture techniques

Does not work well with:

R2 (Ray marching) - requires conversion
G2 (SDFs) - different representation

G4: Voxels

Description: Represent geometry as 3D grids of filled/empty cells, optionally with material data.

Variants:

Dense voxel grids
Sparse voxel octrees (SVO)
Sparse voxel DAGs (directed acyclic graphs - massive compression)
Voxel run-length encoding

Works well with:

P2 (Procedural terrain/caves)
C3 (Octree compression)
R3 (Voxel ray casting)
T8 (Palette-based materials)
Destructible environments
L3 (Octree-based LOD)

Does not work well with:

G1 (Billboards) - conflicting paradigms
Smooth organic shapes (without very high resolution)
A2 (Skeletal animation) - voxels don't deform well
Traditional GPU rasterization (needs conversion)

G5: Point Clouds / Splats

Description: Represent surfaces as collections of points, rendered as small discs or gaussians.

Variants:

Raw point clouds
Gaussian splats (3D Gaussian Splatting)
Surfels (surface elements with normals)

Works well with:

Photogrammetry/scanned data
L2 (Distance-based LOD via point density)
Neural compression techniques
Real-time capture scenarios

Does not work well with:

Sharp edges and hard surfaces
A2 (Skeletal animation)
Traditional texture mapping
Small file sizes (typically large datasets)

G6: Virtualized Geometry (Nanite-style)

Description: Stream and render massive meshes by breaking into clusters, culling aggressively, and using software rasterization for small triangles.

Works well with:

G3 (Traditional meshes as source)
Massive instance counts
L1 (Seamless LOD)
Highly detailed static environments

Does not work well with:

G2 (SDFs)
G4 (Voxels)
A2 (Skeletal animation) - limited support
Very low memory budgets (needs streaming infrastructure)
Procedural geometry (needs pre-built clusters)

Engine Compatibility:

Godot: ☆☆☆☆☆ - Would require rewriting renderer
Unreal: ★★★★★ - Native, this is UE5's flagship feature
Unity: ☆☆☆☆☆ - No equivalent, would need custom implementation

Spectrum Position: D1 (maximally retained, GPU-driven)

G7: Mesh Compression Formats

Description: Compress traditional meshes using specialized algorithms.

Variants:

Draco (Google) - aggressive vertex/index compression
Meshoptimizer - vertex cache optimization + compression
OpenCTM
Corto
Quantization (reduce vertex precision)

Works well with:

G3 (Traditional meshes)
Any mesh-based workflow
Network streaming

Does not work well with:

Procedural geometry (already minimal)
G2, G4 (Different representations)

G8: Implicit Surfaces via Noise Functions

Description: Define surfaces as isosurfaces of noise functions (e.g., Perlin, Simplex, Worley).

Works well with:

P2 (Procedural terrain)
G2 (SDFs) - noise as SDF modifier
Marching cubes extraction
T6 (Procedural textures)

Does not work well with:

Precise authored shapes
Character models
Architectural details

G9: Catmull-Clark / Subdivision Surfaces

Description: Store coarse control cage, subdivide at runtime to desired detail.

Works well with:

Hardware tessellation
L1 (Adaptive LOD based on screen coverage)
Animation (animate control cage only)
Organic shapes

Does not work well with:

Hard surface details
Very low-end hardware
Real-time LOD transitions (popping)

G10: Displacement Mapping on Simple Base Meshes

Description: Use simple base geometry + displacement maps for detail.

Works well with:

G9 (Subdivision surfaces)
Hardware tessellation
T1 (Texture compression)
Terrain rendering

Does not work well with:

Extreme displacement (silhouette issues)
Very low poly bases
Mobile/low-end hardware

G11: Constructive Solid Geometry (CSG)

Description: Build complex shapes from boolean operations on primitives.

Works well with:

G2 (SDFs) - trivial CSG with min/max operations
P1 (Procedural buildings)
Architectural/mechanical shapes
Level editors

Does not work well with:

Organic shapes
Traditional mesh pipeline (needs baking)
Real-time modification at scale

G12: Curve-Based Geometry (Bezier, B-Splines, NURBS)

Description: Define surfaces mathematically via control points and basis functions.

Works well with:

CAD-like precision
Tessellation at runtime
Vehicle/architectural modeling
Fonts and text

Does not work well with:

Organic characters
Texture mapping (parameterization issues)
Game engine standard workflows

G13: Height Maps (2.5D Geometry)

Description: Represent terrain as 2D grid of heights.

Works well with:

P2 (Procedural terrain)
L2 (Distance-based LOD like CDLOD, geoclipmaps)
T1 (Standard texture compression)
Large outdoor environments

Does not work well with:

Overhangs, caves, arches
Vertical surfaces
Indoor environments

G14: Sprite Stacking

Description: Stack 2D sprite layers to create pseudo-3D effect (popular in indie games).

Works well with:

2D art pipelines
Pixel art aesthetics
Simple rotation
Low memory budgets

Does not work well with:

Free camera rotation (limited angles)
Smooth surfaces
Complex lighting

G15: Style Transfer / Neural Rendering on Billboards

Description: Render simple geometry, apply neural style transfer to add apparent detail/dimension.

Works well with:

G1 (Billboards)
Artistic/stylized games
Post-processing pipeline

Does not work well with:

Realistic graphics
Consistent frame-to-frame appearance (temporal stability)
Low-end hardware (neural networks expensive)

G16: Geometry Images

Description: Encode mesh geometry as 2D images (positions, normals as RGB). GPU-friendly compression.

Works well with:

Standard image compression
GPU texture sampling
Streaming

Does not work well with:

High genus topology
Sharp features
Very detailed meshes

G17: Tetrahedral Meshes

Description: Represent solid volumes with tetrahedra for simulation/deformation.

Works well with:

Soft body physics
Destruction simulation
Medical/scientific viz

Does not work well with:

Standard rendering (need surface extraction)
Real-time at high detail
Typical game assets

Procedural Generation

P1: Procedural Building/Structure Generation

Description: Generate architectural geometry from rules, grammars, or parameters.

Variants:

L-systems
Shape grammars
Wave Function Collapse
Houdini-style procedural graphs

Works well with:

G2 (SDFs) for component shapes
G11 (CSG) for combining
T6 (Procedural textures)
Infinite/large worlds

Does not work well with:

Hand-authored unique buildings
Very specific architectural requirements
Interiors with complex layouts

P2: Procedural Terrain

Description: Generate terrain from noise functions, erosion simulation, etc.

Variants:

Fractal noise (fBm, ridged multifractal)
Erosion simulation (hydraulic, thermal)
Tectonic simulation
Machine learning terrain

Works well with:

G13 (Height maps)
G8 (Noise-based implicit surfaces)
T6 (Procedural textures)
L2 (Terrain LOD systems)

Does not work well with:

Specific authored terrain features
Multiplayer synchronization (seed matching)
Playtesting consistency

P3: Procedural Vegetation

Description: Generate trees, plants from L-systems or space colonization algorithms.

Works well with:

G1 (Billboard LOD for distance)
Wind animation
Large forests with variety

Does not work well with:

Specific tree shapes
Very low memory (still need some parameters)

P4: Procedural Textures (Runtime)

Description: Generate textures entirely in shaders from noise and math.

Works well with:

G2 (SDFs) - same mathematical mindset
Infinite detail at any resolution
Zero texture memory

Does not work well with:

Specific authored looks
Photorealistic materials
Caching/performance on low-end

P5: Wang Tiles / Corner Tiles

Description: Small set of tiles that can be combined infinitely without visible repetition.

Works well with:

Terrain texturing
2D games
Procedural layouts

Does not work well with:

Continuous 3D surfaces
Non-tiling requirements

P6: Compute Shader Geometry Generation

Description: Generate mesh data directly in compute shaders, output to vertex buffers.

Variants:

Marching cubes/tetrahedra
Dual contouring
Procedural mesh construction
Instanced generation

Works well with:

G4 (Voxel to mesh conversion)
G8 (Noise isosurface extraction)
Massive polygon counts (GPU parallel)
Dynamic/destructible geometry

Does not work well with:

CPU-bound game logic needing mesh data
Very old GPUs
Debugging (hard to inspect)

Engine Compatibility:

Godot: ★★★☆☆ - ComputeShader API newer but functional, RenderingDevice access
Unreal: ★★★★☆ - Good compute support, but integrating with rendering complex
Unity: ★★★★☆ - ComputeShader + Graphics.DrawProceduralIndirect works well

Spectrum Position: D8 (per-frame GPU generation)

P7: Grammar-Based Generation

Description: Use formal grammars (L-systems, graph grammars) to generate content.

Works well with:

P1 (Buildings)
P3 (Plants)
Dungeons/levels
Consistent rule-based content

Does not work well with:

Organic, non-structured content
Very specific requirements
Real-time generation at scale

P8: Fractal Geometry

Description: Self-similar mathematical structures (Mandelbrot, Menger sponge, etc.)

Works well with:

G2 (SDFs) - many fractals have SDF formulas
Alien/abstract aesthetics
Infinite zoom

Does not work well with:

Real-world objects
Performance (often computationally expensive)
Traditional game aesthetics

Texture Techniques

T1: GPU Texture Compression (BC/DXT, ASTC, ETC)

Description: Hardware-accelerated block compression, typically 4:1 to 8:1 ratio.

Variants:

BC1-BC7 (Desktop)
ASTC (Mobile/modern)
ETC1/ETC2 (Mobile)
PVRTC (iOS legacy)

Works well with:

G3 (Standard meshes)
Nearly everything standard
Hardware sampling

Does not work well with:

Procedural texture generation (already computed)
Very high quality requirements (lossy)
Unusual data (not designed for non-color data)

T2: Texture Supercompression (Basis Universal, KTX2)

Description: Compress textures to universal intermediate, transcode to platform-specific format.

Works well with:

Cross-platform deployment
Streaming
Very small distribution size

Does not work well with:

Maximum quality
Already-compressed source textures

T3: Texture Atlasing

Description: Pack multiple textures into single larger texture.

Works well with:

G1 (Billboards)
Reducing draw calls
Sprite-based games

Does not work well with:

Mipmapping (bleeding artifacts)
Very different texture sizes
Dynamic texture updates

T4: Virtual Texturing / Megatextures

Description: Stream texture tiles on demand, potentially unique texturing for entire world.

Works well with:

Massive open worlds
Unique texturing everywhere
Terrain

Does not work well with:

Small projects (infrastructure overhead)
Very fast movement (streaming lag)
Memory-constrained platforms

T5: Texture Synthesis

Description: Generate large textures from small exemplars.

Variants:

Patch-based synthesis
Neural texture synthesis
Histogram-matching

Works well with:

Organic materials
Terrain blending
Runtime variety

Does not work well with:

Structured patterns
Real-time performance
Predictable results

T6: Purely Procedural Textures

Description: Compute texture entirely mathematically (no stored data).

Variants:

Noise-based (Perlin, Simplex, Worley, etc.)
Mathematical patterns (checkers, gradients)
Reaction-diffusion
Fractal patterns

Works well with:

G2 (SDFs)
Zero texture memory
Infinite detail

Does not work well with:

Specific authored appearances
Photorealism
Low-end GPU (compute cost)

Engine Compatibility:

Godot: ★★★★☆ - Shader functions, visual shader nodes available
Unreal: ★★★★☆ - Material functions, but editor is verbose/visual-heavy
Unity: ★★★★☆ - Shader functions, Shader Graph nodes

Spectrum Position: D8-D9 (computed per-frame, no stored texture data)

T7: Triplanar Mapping

Description: Project textures from three axes, blend based on normal. No UV unwrapping needed.

Works well with:

Procedural geometry
G4 (Voxels)
Terrain
Quick prototyping

Does not work well with:

Optimal texture usage (3x sampling)
Authored UV details
Performance-critical paths

T8: Palette-Based Textures

Description: Store texture as indices into small color palette.

Variants:

8-bit indexed color
Palette animation
Color LUT post-process

Works well with:

Retro aesthetics
G4 (Voxels)
Very small file sizes
Style consistency

Does not work well with:

Photorealism
Gradients (banding)
Modern expectations

T9: Taylor Series / Polynomial Texture Approximation

Description: Represent textures as polynomial coefficients, reconstruct in shader.

Works well with:

Simple patterns
Extreme compression
Mathematical elegance

Does not work well with:

Complex textures (many coefficients needed)
Sharp features
General-purpose use

T10: Fourier/DCT Texture Encoding

Description: Store texture as frequency domain coefficients (like JPEG internally).

Works well with:

Smooth textures
Progressive loading
Understanding frequency content

Does not work well with:

Sharp edges (ringing artifacts)
Real-time decode at full resolution
GPU-friendly access

T11: Neural Texture Compression

Description: Use neural networks to encode/decode textures.

Variants:

Learned image compression
Neural texture fields
SIREN-based representations

Works well with:

Extreme compression ratios
Complex patterns
Research/future techniques

Does not work well with:

Real-time decode (expensive)
Hardware support (none currently)
Predictable quality

T12: Detail Textures

Description: Tile small detail texture over base, blending at distance.

Works well with:

Terrain
Large surfaces
Adding high-frequency detail cheaply

Does not work well with:

Close-up viewing (tiling visible)
Unique surfaces

T13: Normal Map Compression Techniques

Description: Special encoding for normal maps (2 channels, reconstruct Z).

Variants:

BC5/ATI2N (two channel)
Octahedral encoding
Spheremap transform

Works well with:

Standard PBR workflows
Quality-conscious projects

Does not work well with:

Extremely memory-constrained (still needs texture)

T14: Material ID Textures

Description: Single channel texture indexes into material database.

Works well with:

G4 (Voxels)
Stylized looks
Tiny texture footprint

Does not work well with:

Material blending
Unique surfaces
Photorealism

T15: Emoji/Unicode as Textures

Description: Use system emoji/glyphs as instant free textures.

Works well with:

Jam games
Placeholder art
Specific aesthetics

Does not work well with:

Cross-platform consistency
Professional quality
Most real games

T16: Decals

Description: Project textures onto surfaces dynamically.

Works well with:

Adding variety to base materials
Damage/graffiti
Forward-rendered details

Does not work well with:

Very curved surfaces
Performance at scale
Deferred rendering (complexity)

Rendering Paradigms

R1: Rasterization (Baseline)

Description: Standard GPU triangle rendering.

Works well with:

G3 (Standard meshes)
All standard techniques
Hardware acceleration

Does not work well with:

G2 (SDFs) - requires conversion
Extreme geometric complexity (draw call limits)

R2: Ray Marching

Description: Step along rays, evaluate SDF or volume at each step.

Works well with:

G2 (SDFs)
P4 (Procedural geometry)
Volumetric effects
Demoscene intros

Does not work well with:

G3 (Polygon meshes) - different paradigm
Very complex scenes (performance)
Mobile/low-end

Engine Compatibility:

Godot: ★★★☆☆ - Custom spatial shader or canvas_item fullscreen
Unreal: ★★☆☆☆ - Post-process material (limited), custom pass (complex)
Unity: ★★★☆☆ - Custom RenderFeature, or image effect on camera

Integration notes: All engines expect rasterized depth buffers. Integrating ray-marched content with engine-rendered content (for shadows, reflections, etc.) requires extra work to output compatible depth.

Spectrum Position: D8-D10 (inherently immediate, stateless per-pixel)

R3: Voxel Ray Casting

Description: Cast rays through voxel grids.

Works well with:

G4 (Voxels)
Octree acceleration
Volumetric rendering

Does not work well with:

Non-voxel content
Smooth surfaces
Standard engine integration

R4: Particle Systems

Description: Render many small elements (points, quads).

Works well with:

Effects (fire, smoke, sparks)
G1 (Billboards)
GPU instancing

Does not work well with:

Solid geometry
Precise surfaces

R5: Deferred Rendering

Description: Separate geometry pass from lighting pass.

Works well with:

Many lights
Complex lighting setups
G-buffer effects

Does not work well with:

Transparency
Memory-constrained platforms
MSAA (complexity)

R6: Forward+ / Clustered Forward

Description: Forward rendering with light culling.

Works well with:

Transparency
Many lights
Modern GPUs

Does not work well with:

Very complex per-pixel work
Extreme light counts

R7: Hybrid Ray Tracing

Description: Use RT for specific effects (reflections, shadows, GI).

Works well with:

High-end hardware
Quality-focused projects
Specific effects

Does not work well with:

Older hardware
Performance-critical paths
Full RT scenes (expensive)

R8: Software Rasterization

Description: CPU or compute shader triangle rasterization (Nanite-style for small triangles).

Works well with:

G6 (Nanite virtualized geometry)
Very small triangles
Pixel-sized geometry

Does not work well with:

Large triangles (hardware better)
Simple scenes

R9: Precomputed Radiance Transfer

Description: Bake complex lighting into per-vertex or texture data.

Works well with:

Static scenes
Complex GI cheaply
Last-gen hardware

Does not work well with:

Dynamic lighting
Dynamic geometry
Memory for baked data

Compression & Encoding

C1: Delta Encoding

Description: Store differences from previous frame/value.

Works well with:

A3 (Animation data)
Sequential data
Video compression concepts

Does not work well with:

Random access
Non-sequential data

C2: Quantization

Description: Reduce precision (e.g., 32-bit to 16-bit, 8-bit).

Variants:

Position quantization (vertices)
Rotation quantization (quaternions)
Color quantization
Weight quantization

Works well with:

Nearly everything
GPU-friendly (half precision)
Huge size reductions

Does not work well with:

Precision-critical applications
Very large worlds (precision issues)

C3: Octree / Hierarchical Encoding

Description: Organize spatial data hierarchically for compression and queries.

Works well with:

G4 (Voxels)
Spatial queries
LOD
Sparse data

Does not work well with:

Dense, uniform data
Implementation complexity

C4: Run-Length Encoding

Description: Encode runs of repeated values.

Works well with:

G4 (Voxel runs)
Simple patterns
Terrain layers

Does not work well with:

High-entropy data
Random patterns

C5: Dictionary Compression (LZ-family)

Description: General-purpose compression (gzip, zstd, lz4).

Works well with:

Any serialized data
Network transmission
Storage

Does not work well with:

Already-compressed data
Real-time GPU access

C6: Entropy Coding (Huffman, ANS, Arithmetic)

Description: Optimal bit-level encoding based on symbol frequency.

Works well with:

As final compression stage
Any data with non-uniform distribution

Does not work well with:

Real-time decode (complex)
Random access

C7: Sparse Voxel DAGs

Description: Convert octrees to DAGs by merging identical subtrees.

Works well with:

G4 (Voxels)
Highly repetitive voxel data
Massive worlds

Does not work well with:

Unique voxel data
Implementation complexity

C8: Basis Decomposition (PCA, SVD)

Description: Decompose data into basis components, keep most important.

Works well with:

Animation data
Texture compression
Any high-dimensional data

Does not work well with:

Non-linear patterns
Real-time at scale

LOD & Streaming

L1: Discrete LOD

Description: Multiple pre-authored detail levels, switch based on distance.

Works well with:

G3 (Standard meshes)
Simple implementation
Full control

Does not work well with:

Popping artifacts
Memory for multiple versions

L2: Continuous LOD (CLOD)

Description: Smoothly vary detail based on screen coverage.

Variants:

ROAM (terrain)
CDLOD (terrain)
Geoclipmaps
Progressive meshes

Works well with:

G13 (Height maps)
Terrain
Smooth transitions

Does not work well with:

General meshes (complex)
Simple scenes (overhead)

L3: Hierarchical LOD (HLOD)

Description: Group distant objects into single merged mesh.

Works well with:

Large worlds
City rendering
Reducing draw calls

Does not work well with:

Moving objects
Dynamic scenes

L4: Impostor LOD

Description: Replace distant geometry with billboards.

Works well with:

G1 (Billboards)
Very far LOD levels
Vegetation

Does not work well with:

Close viewing
Lighting consistency

L5: Streaming (General)

Description: Load assets on-demand based on player position.

Works well with:

Open worlds
Memory management
Most asset types

Does not work well with:

Fast movement (pop-in)
Small games (overhead)

Shader-Based Techniques

S1: Domain Repetition (Instancing via Math)

Description: Use modulo/fract to repeat SDF or geometry infinitely.

Works well with:

G2 (SDFs)
R2 (Ray marching)
Demoscene techniques
Infinite worlds

Does not work well with:

Unique instances
Polygon-based rendering

S2: Shader-Based Mesh Deformation

Description: Modify vertex positions in vertex shader.

Works well with:

Wind animation
Water waves
Morph targets
Skeletal animation

Does not work well with:

CPU collision detection (desync)
Physics (needs CPU data)

S3: Parallax / Relief Mapping

Description: Fake depth on flat surfaces via ray marching in texture space.

Works well with:

T1 (Standard textures)
Adding detail to flat surfaces
Walls, floors

Does not work well with:

Silhouettes (still flat)
Extreme angles
Many iterations (performance)

S4: Screen-Space Effects

Description: Post-process effects working on rendered buffers.

Variants:

SSAO (ambient occlusion)
SSR (reflections)
SSGI (global illumination)
Motion blur, DOF

Works well with:

Any rendering paradigm
Adding polish cheaply
Consistent look

Does not work well with:

Off-screen information
VR (reprojection artifacts)

S5: Smooth Blending (SDFs)

Description: Blend between SDF shapes smoothly using polynomial smooth-min.

Works well with:

G2 (SDFs)
Organic shapes
Metaballs

Does not work well with:

Sharp features
Non-SDF rendering

S6: Raymarching Optimizations

Description: Techniques to speed up SDF ray marching.

Variants:

Sphere tracing
Enhanced sphere tracing
Bounding volume checks
Cone tracing
Distance field acceleration

Works well with:

G2 (SDFs)
R2 (Ray marching)
Complex scenes

Does not work well with:

Non-SDF rendering

S7: Shader LOD / Shader Permutations

Description: Simpler shader for distant objects.

Works well with:

Performance scaling
Any shader-based look
Mobile optimization

Does not work well with:

Code maintenance (permutation explosion)

Animation Techniques

A1: Keyframe Animation

Description: Store key poses, interpolate between them.

Works well with:

Standard workflows
Simple implementation
Manual authoring

Does not work well with:

Very long animations
Memory-constrained (many keys)

A2: Skeletal Animation

Description: Animate bone hierarchy, skin mesh to bones.

Works well with:

G3 (Standard meshes)
Characters
Reusable animations

Does not work well with:

G1 (Billboards)
G4 (Voxels) - complex skinning
G2 (SDFs) - different paradigm

A3: Animation Compression

Description: Compress animation curves.

Variants:

Curve fitting
Quantization
Delta encoding
ACL (Animation Compression Library)

Works well with:

A1, A2 (Any keyframe-based)
Large animation datasets

Does not work well with:

Already-minimal animations

A4: Procedural Animation

Description: Generate animation from code (physics, IK, etc.).

Variants:

Inverse kinematics
Physics-based (ragdoll, springs)
Motion matching procedural blending
Noise-based (idle, breathing)

Works well with:

G2 (SDFs)
Zero storage
Reactive animation

Does not work well with:

Specific authored motion
Precise timing

A5: Vertex Animation Textures (VAT)

Description: Bake animation into textures, sample in vertex shader.

Works well with:

Complex simulations (cloth, fluid, destruction)
GPU instancing animated objects
Many identical animated objects

Does not work well with:

Interactive animation
Unique animations per instance
Very long animations (texture size)

A6: Morph Targets / Blend Shapes

Description: Blend between different mesh poses.

Works well with:

Facial animation
Corrective shapes
Simple deformations

Does not work well with:

Full body animation alone
Many shapes (memory)

A7: Bone Baking

Description: Bake complex rig to simpler one.

Works well with:

Mobile
Performance optimization
After authoring in complex rig

Does not work well with:

Runtime rig features

A8: Flipbook Animation

Description: Frame-by-frame sprite animation.

Works well with:

G1 (Billboards)
2D aesthetics
Effects

Does not work well with:

3D rotation
Smooth motion (frame rate limited)

Lighting & Materials

M1: Flat / Unlit Shading

Description: No lighting calculation, albedo only.

Works well with:

Stylized games
Mobile performance
Emissive aesthetics

Does not work well with:

Realism
Depth perception (need other cues)

M2: Simple Lighting Models (Lambert, Blinn-Phong)

Description: Classic simple lighting.

Works well with:

Performance-critical
Stylized looks
Low-end hardware

Does not work well with:

Physical accuracy
Modern expectations

M3: PBR (Physically Based Rendering)

Description: Energy-conserving lighting with roughness/metallic.

Works well with:

Modern engines
Consistent look
Industry standard

Does not work well with:

Ultra-low-end
Extreme stylization

M4: Lightmaps

Description: Pre-baked lighting into textures.

Works well with:

Static scenes
Complex GI cheaply
Mobile

Does not work well with:

Dynamic objects
Dynamic lights
Memory for textures

M5: Spherical Harmonics (SH)

Description: Encode lighting as low-frequency spherical function.

Works well with:

Light probes
Dynamic objects in static light
Compact representation

Does not work well with:

Sharp lighting features
Specular reflections

M6: Light Probes

Description: Sample lighting at points in space.

Works well with:

M5 (SH encoding)
Dynamic objects
Mixed static/dynamic

Does not work well with:

Interior complexity
Placement effort

M7: Toon / Cel Shading

Description: Quantized shading for cartoon look.

Works well with:

Stylized aesthetics
Low texture requirements
Simple implementation

Does not work well with:

Realism
Complex materials

M8: Matcaps (Material Capture)

Description: 2D texture encodes entire material response.

Works well with:

Sculpting preview
Stylized looks
Zero lighting calculation

Does not work well with:

Environment-dependent reflections
Multiple light sources
Viewing angle changes

M9: Shared Material Libraries

Description: Share materials across many objects.

Works well with:

Any rendering approach
Memory savings
Style consistency

Does not work well with:

Unique objects
Per-instance variation (needs instancing)

Audio (Bonus - Related to Asset Size)

AU1: Procedural Audio

Description: Generate sounds from synthesis (no samples).

Works well with:

Retro aesthetics
Tiny size
Infinite variation

Does not work well with:

Realistic sounds
Voice
Specific recordings

AU2: Tracker Music (MOD, XM, IT)

Description: Small samples + pattern data.

Works well with:

Demoscene tradition
Tiny file sizes
Chiptune/electronic

Does not work well with:

Orchestral
Recorded performances

AU3: MIDI + Soundfonts

Description: Note data + shared instrument samples.

Works well with:

Tiny music data
Style variations (swap soundfont)
Interactive music

Does not work well with:

Recorded performances
Modern production quality

AU4: Granular Synthesis

Description: Build sounds from tiny grains of sampled audio.

Works well with:

Ambient textures
Sound design
Variation from small samples

Does not work well with:

Clean tonal content
Predictability

Code Size Reduction

CODE1: Executable Packers

Description: Compress executables with runtime decompression (UPX, kkrunchy, crinkler).

Works well with:

Demoscene intros
Single-binary distribution
Final stage compression

Does not work well with:

Antivirus compatibility (false positives)
Debug builds
Large executables (memory for decompression)

CODE2: Shader Minification

Description: Remove whitespace, shorten names in shaders.

Works well with:

R2 (Ray marching with complex shaders)
Web distribution (GLSL)
Size-coded competitions

Does not work well with:

Debug/development
Readability

CODE3: Code Generation

Description: Generate repetitive code rather than writing by hand.

Works well with:

Shader permutations
Boilerplate
Repetitive patterns

Does not work well with:

Unique code
Debug tracing

CODE4: Minimal Engine / No Engine

Description: Write minimal custom code instead of using large engine.

Works well with:

Extreme size constraints
Learning
Full control

Does not work well with:

Productivity
Complex games
Teams

CODE5: Data-Driven Architecture

Description: Behavior defined in data, interpreted by small runtime.

Works well with:

Content variety
Modding
Separation of concerns

Does not work well with:

Performance-critical code
Complex logic

Hybrid / Advanced Techniques

H1: Nested SDFs

Description: SDFs containing other SDFs at different scales.

Works well with:

G2 (SDFs)
Fractal-like detail
Extreme proceduralism

Does not work well with:

Performance (nested ray marching)
Traditional workflows

H2: Neural Radiance Fields (NeRF) / 3D Gaussian Splatting

Description: ML-based scene representations.

Works well with:

Photogrammetry
View synthesis
Captured content

Does not work well with:

Authored content
Real-time editing
Current hardware (performance)
Game engines (integration)

H3: Mesh Shaders

Description: Modern GPU pipeline with flexible geometry processing.

Works well with:

Procedural geometry
Custom culling
Amplification/culling
Modern GPUs only

Does not work well with:

Old hardware
Simple geometry

H4: Texture-Space Shading

Description: Shade into texture, reuse across frames.

Works well with:

Complex shading
VR reprojection
Temporal stability

Does not work well with:

Dynamic geometry
Memory for textures

H5: Hybrid SDF-Mesh Rendering

Description: Use SDFs for some objects, meshes for others.

Works well with:

Best of both worlds
Terrain (SDF) + characters (mesh)
Complex scenes

Does not work well with:

Unified lighting (different normals)
Intersection handling
Complexity

H6: Streaming Geometry Compression

Description: Progressive mesh refinement over network.

Works well with:

Web delivery
Slow connections
L5 (Streaming)

Does not work well with:

Offline games
Fast local storage

H7: Layered Depth Images (LDI)

Description: Store multiple depth samples per pixel for view synthesis.

Works well with:

Limited viewpoint change
VR reprojection
Image-based rendering

Does not work well with:

Large viewpoint changes
Dynamic scenes

Artistic Constraints (Zero Storage)

ART1: Single Primitive Aesthetic

Description: Entire game uses only cubes, spheres, etc.

Works well with:

G2 (SDFs) - primitives trivial
Distinctive look
Zero model storage

Does not work well with:

Varied aesthetics
Character expressiveness

ART2: Single Color Palette

Description: Entire game uses N colors (e.g., 4, 8, 16).

Works well with:

T8 (Palette textures)
Retro aesthetics
Style consistency

Does not work well with:

Photorealism
Gradients

ART3: Intentional Low Resolution

Description: Render at very low resolution, upscale with filters.

Works well with:

Pixel art aesthetics
Performance (fewer pixels)
Retro style

Does not work well with:

Text readability
Modern expectations
UI

ART4: Outline/Edge-Only Rendering

Description: Only render edges of geometry.

Works well with:

Distinctive aesthetic
Very fast rendering
Wireframe style

Does not work well with:

Filled surfaces
Complex materials

ART5: Silhouette-Based Design

Description: Design all content for readability in silhouette.

Works well with:

High contrast
Gameplay clarity
Simple rendering

Does not work well with:

Detail appreciation
Photorealism

Summary / Quick Reference

For Absolute Minimum Size:

G2 (SDFs) + P1/P6 (Procedural generation) + T6 (Procedural textures)
R2 (Ray marching) + S1 (Domain repetition)
A4 (Procedural animation)
CODE1 (Executable packer)

For Balanced Size/Quality:

G3 (Meshes) + G7 (Draco compression)
T1 (BC7/ASTC) + T2 (Basis Universal)
A2 + A3 (Skeletal with compression)
L1/L4 (LOD with impostors)

For Modern Hardware, Maximum Quality at Size:

G6 (Nanite-style)
T4 (Virtual texturing)
R7 (Hybrid RT)
L1 seamless LOD

Major paradigm splits:

SDF/Ray Marching vs Polygon/Rasterization
Procedural vs Authored
GPU-driven vs CPU-driven

Future Website Features

This document is designed to eventually become an interactive website where users can:

Select techniques they're interested in
See compatibility - other techniques highlight green (works well) or red (conflicts)
Filter by category (Geometry, Texture, Rendering, etc.)
Filter by target (Mobile, Desktop, Demoscene 4KB, etc.)
See combinations - pre-built "recipes" for common goals
Contribute - add new techniques and compatibility notes

Version History

v0.1 - Initial brainstorm and categorization

https://claude.ai/public/artifacts/f6f19ef1-41e7-4c7b-a2e5-936030a93450

Technique Compatibility Matrix

This document provides 2D matrices showing how techniques work together.

Legend:

✅ = Strong synergy (designed to work together)
⚠️ = Possible (can combine with effort)
❌ = Incompatible (fundamentally different paradigms)
➖ = Same technique / not applicable

Core Geometry Techniques

	G1 Billboard	G2 SDF	G3 Mesh	G4 Voxel	G5 Splat	G6 Nanite	G8 Noise	G9 Subdiv	G11 CSG	G13 Height
G1 Billboard	➖	❌	✅	⚠️	⚠️	✅	❌	⚠️	❌	✅
G2 SDF	❌	➖	❌	⚠️	❌	❌	✅	❌	✅	⚠️
G3 Mesh	✅	❌	➖	⚠️	⚠️	✅	⚠️	✅	⚠️	✅
G4 Voxel	⚠️	⚠️	⚠️	➖	❌	❌	✅	❌	✅	✅
G5 Splat	⚠️	❌	⚠️	❌	➖	❌	❌	❌	❌	⚠️
G6 Nanite	✅	❌	✅	❌	❌	➖	❌	⚠️	❌	⚠️
G8 Noise	❌	✅	⚠️	✅	❌	❌	➖	⚠️	✅	✅
G9 Subdiv	⚠️	❌	✅	❌	❌	⚠️	⚠️	➖	⚠️	⚠️
G11 CSG	❌	✅	⚠️	✅	❌	❌	✅	⚠️	➖	⚠️
G13 Height	✅	⚠️	✅	✅	⚠️	⚠️	✅	⚠️	⚠️	➖

Key Observations:

G2 (SDF) is fundamentally incompatible with polygon-based techniques (G3, G6, G9)
G6 (Nanite) works great with traditional meshes, impostors for LOD
G4 (Voxel) bridges SDF and mesh worlds - can convert to either
G8 (Noise) is highly compatible with procedural approaches (SDF, voxel, heightmap)

Geometry × Procedural Generation

	P1 Building	P2 Terrain	P3 Veg	P4 ProcTex	P5 Wang	P6 Compute	P7 Grammar	P8 Fractal
G1 Billboard	⚠️	✅	✅	✅	✅	⚠️	⚠️	❌
G2 SDF	✅	✅	⚠️	✅	❌	✅	✅	✅
G3 Mesh	✅	✅	✅	✅	✅	✅	✅	⚠️
G4 Voxel	✅	✅	⚠️	✅	⚠️	✅	✅	✅
G5 Splat	❌	⚠️	❌	⚠️	❌	⚠️	❌	❌
G6 Nanite	✅	⚠️	✅	✅	✅	❌	✅	❌
G8 Noise	⚠️	✅	✅	✅	⚠️	✅	⚠️	✅
G9 Subdiv	✅	⚠️	⚠️	✅	⚠️	⚠️	✅	⚠️
G11 CSG	✅	⚠️	❌	✅	❌	✅	✅	✅
G13 Height	⚠️	✅	✅	✅	✅	✅	⚠️	✅

Key Observations:

P6 (Compute Gen) is incompatible with Nanite (needs pre-built clusters)
P8 (Fractals) work excellently with SDF and voxels, poorly with traditional meshes
P2 (Terrain) works well with almost everything
G5 (Splats) don't integrate well with procedural generation (captured data)

Geometry × Rendering Paradigms

	R1 Forward	R2 RayMarch	R3 VoxelCast	R4 Particle	R5 Deferred	R6 Forward+	R7 RT	R8 SoftRast
G1 Billboard	✅	❌	❌	✅	✅	✅	⚠️	✅
G2 SDF	❌	✅	⚠️	❌	❌	❌	⚠️	❌
G3 Mesh	✅	❌	❌	⚠️	✅	✅	✅	✅
G4 Voxel	⚠️	⚠️	✅	⚠️	⚠️	⚠️	⚠️	⚠️
G5 Splat	⚠️	❌	❌	✅	⚠️	⚠️	❌	⚠️
G6 Nanite	⚠️	❌	❌	⚠️	✅	⚠️	✅	✅
G8 Noise	⚠️	✅	✅	⚠️	⚠️	⚠️	⚠️	⚠️
G9 Subdiv	✅	❌	❌	❌	✅	✅	✅	⚠️
G11 CSG	⚠️	✅	⚠️	❌	⚠️	⚠️	⚠️	⚠️
G13 Height	✅	⚠️	⚠️	⚠️	✅	✅	✅	✅

Key Observations:

R2 (Ray Marching) is the natural match for SDF, incompatible with most mesh techniques
G6 (Nanite) uses R8 (Software Rasterization) internally
R7 (Ray Tracing) works with traditional geometry, not SDF or pure procedural
G4 (Voxel) is flexible - can be ray cast, converted to mesh, or marched

Geometry × Texture Techniques

	T1 Compress	T3 Atlas	T4 Virtual	T6 ProcTex	T7 Triplanar	T8 Palette	T12 Detail
G1 Billboard	✅	✅	✅	⚠️	❌	✅	⚠️
G2 SDF	❌	❌	❌	✅	✅	⚠️	❌
G3 Mesh	✅	✅	✅	✅	⚠️	✅	✅
G4 Voxel	⚠️	⚠️	⚠️	✅	✅	✅	⚠️
G5 Splat	⚠️	⚠️	⚠️	❌	❌	❌	❌
G6 Nanite	✅	✅	✅	✅	⚠️	⚠️	✅
G8 Noise	❌	❌	❌	✅	✅	⚠️	⚠️
G9 Subdiv	✅	⚠️	✅	✅	⚠️	⚠️	✅
G11 CSG	⚠️	⚠️	⚠️	✅	✅	✅	⚠️
G13 Height	✅	⚠️	✅	✅	✅	✅	✅

Key Observations:

T6 (Procedural Textures) is the natural match for SDF and procedural geometry
T7 (Triplanar) is essential for geometry without UV coordinates (voxels, SDF, CSG)
G5 (Splats) have their own color representation, don't use traditional texturing
T1 (Compression) doesn't apply to pure procedural (nothing to compress)

Geometry × Animation

	A1 Keyframe	A2 Skeletal	A4 Procedural	A5 VAT	A6 Morph	A8 Flipbook
G1 Billboard	✅	❌	⚠️	⚠️	❌	✅
G2 SDF	⚠️	❌	✅	❌	⚠️	❌
G3 Mesh	✅	✅	✅	✅	✅	⚠️
G4 Voxel	⚠️	❌	✅	⚠️	❌	⚠️
G5 Splat	⚠️	❌	⚠️	❌	❌	❌
G6 Nanite	✅	⚠️	⚠️	⚠️	⚠️	❌
G8 Noise	⚠️	❌	✅	❌	⚠️	❌
G9 Subdiv	✅	✅	✅	⚠️	✅	❌
G11 CSG	⚠️	❌	✅	❌	⚠️	❌
G13 Height	✅	❌	✅	⚠️	⚠️	❌

Key Observations:

A2 (Skeletal) only works with deformable mesh representations (G3, G9)
A4 (Procedural) is the natural match for SDF and procedural geometry
G6 (Nanite) has limited skeletal support (world-space evaluation issue)
A8 (Flipbook) is primarily for billboards and 2D content

Geometry × Lighting

	M1 Flat	M2 Phong	M3 PBR	M4 Lightmap	M5 SH	M7 Toon	M8 Matcap
G1 Billboard	✅	⚠️	⚠️	⚠️	⚠️	✅	✅
G2 SDF	✅	✅	✅	❌	⚠️	✅	✅
G3 Mesh	✅	✅	✅	✅	✅	✅	✅
G4 Voxel	✅	✅	⚠️	⚠️	⚠️	✅	⚠️
G5 Splat	✅	⚠️	⚠️	❌	❌	⚠️	❌
G6 Nanite	✅	✅	✅	✅	✅	✅	✅
G8 Noise	✅	✅	⚠️	❌	⚠️	✅	✅
G9 Subdiv	✅	✅	✅	✅	✅	✅	✅
G11 CSG	✅	✅	⚠️	❌	⚠️	✅	✅
G13 Height	✅	✅	✅	✅	✅	✅	✅

Key Observations:

M4 (Lightmaps) requires UV-unwrapped static geometry - incompatible with SDF, noise, CSG
M1 (Flat) and M7 (Toon) work with almost everything
G3 (Mesh) is the most lighting-compatible representation
M8 (Matcap) needs view-space normals, doesn't work with splats

Geometry × LOD

	L1 Discrete	L2 Continuous	L3 HLOD	L4 Impostor	L5 Streaming
G1 Billboard	✅	⚠️	✅	✅	✅
G2 SDF	⚠️	✅	❌	❌	⚠️
G3 Mesh	✅	✅	✅	✅	✅
G4 Voxel	✅	✅	⚠️	⚠️	✅
G5 Splat	✅	✅	⚠️	⚠️	✅
G6 Nanite	✅	✅	✅	✅	✅
G8 Noise	⚠️	✅	❌	❌	❌
G9 Subdiv	✅	✅	⚠️	⚠️	✅
G11 CSG	⚠️	⚠️	❌	❌	⚠️
G13 Height	✅	✅	⚠️	⚠️	✅

Key Observations:

G6 (Nanite) has excellent LOD support - it's the whole point
L3 (HLOD) and L4 (Impostor) need concrete geometry to merge/bake
G2 (SDF) has natural continuous LOD (reduce iterations) but no discrete/baked LOD
L5 (Streaming) works with most approaches that have serializable data

Geometry × Compression

	C2 Quantize	C3 Octree	C5 LZ	C7 DAG	G7 MeshCompress
G1 Billboard	✅	❌	✅	❌	❌
G2 SDF	⚠️	⚠️	❌	❌	❌
G3 Mesh	✅	⚠️	✅	❌	✅
G4 Voxel	✅	✅	✅	✅	❌
G5 Splat	✅	⚠️	✅	❌	❌
G6 Nanite	✅	⚠️	✅	❌	✅
G8 Noise	❌	❌	❌	❌	❌
G9 Subdiv	✅	❌	✅	❌	⚠️
G11 CSG	⚠️	⚠️	⚠️	⚠️	❌
G13 Height	✅	❌	✅	❌	❌

Key Observations:

G8 (Noise) is incompatible with all compression - it IS compression
C3 (Octree) and C7 (DAG) are specifically for voxels
G7 (Mesh Compression) only applies to mesh-based geometry
C2 (Quantization) is nearly universal for any numeric data

Geometry × Precomputation

	PRE2 Light	PRE3 LOD	PRE7 AO	PRE8 SDF	PRE12 Impostor	PRE17 Cache
G1 Billboard	⚠️	⚠️	⚠️	❌	✅	✅
G2 SDF	❌	❌	⚠️	✅	❌	✅
G3 Mesh	✅	✅	✅	⚠️	✅	✅
G4 Voxel	⚠️	⚠️	✅	✅	⚠️	✅
G5 Splat	❌	⚠️	❌	❌	❌	✅
G6 Nanite	✅	✅	✅	⚠️	✅	⚠️
G8 Noise	❌	❌	❌	⚠️	❌	✅
G9 Subdiv	✅	✅	✅	⚠️	✅	✅
G11 CSG	❌	⚠️	⚠️	✅	⚠️	✅
G13 Height	✅	✅	✅	⚠️	⚠️	✅

Key Observations:

PRE2 (Lightmaps) requires UV-unwrapped static meshes
PRE8 (SDF Baking) can convert any geometry to SDF representation
PRE17 (Caching) works with any procedural approach
G8 (Noise) can't be pre-lightmapped, LOD'd, or AO-baked (no surface)

Procedural × Procedural

	P1 Build	P2 Terrain	P3 Veg	P4 ProcTex	P5 Wang	P6 Compute	P7 Grammar	P8 Fractal
P1 Building	➖	✅	✅	✅	✅	✅	✅	⚠️
P2 Terrain	✅	➖	✅	✅	✅	✅	⚠️	✅
P3 Vegetation	✅	✅	➖	✅	⚠️	✅	✅	⚠️
P4 ProcTex	✅	✅	✅	➖	✅	✅	⚠️	✅
P5 Wang Tiles	✅	✅	⚠️	✅	➖	⚠️	⚠️	⚠️
P6 Compute	✅	✅	✅	✅	⚠️	➖	⚠️	✅
P7 Grammar	✅	⚠️	✅	⚠️	⚠️	⚠️	➖	⚠️
P8 Fractal	⚠️	✅	⚠️	✅	⚠️	✅	⚠️	➖

Key Observations:

Procedural techniques are highly compatible with each other - lots of ✅
P2 (Terrain) + P3 (Vegetation) + P1 (Buildings) is a classic combination
P8 (Fractals) is more specialized, harder to integrate with structured generation
P6 (Compute Gen) enables most other procedural techniques at scale

Rendering × Rendering (Hybrid Combinations)

	R1 Forward	R2 RayMarch	R3 VoxCast	R4 Particle	R5 Deferred	R6 Fwd+	R7 RT
R1 Forward	➖	⚠️	⚠️	✅	⚠️	✅	⚠️
R2 RayMarch	⚠️	➖	⚠️	⚠️	⚠️	⚠️	⚠️
R3 VoxelCast	⚠️	⚠️	➖	⚠️	⚠️	⚠️	⚠️
R4 Particle	✅	⚠️	⚠️	➖	✅	✅	⚠️
R5 Deferred	⚠️	⚠️	⚠️	✅	➖	⚠️	✅
R6 Forward+	✅	⚠️	⚠️	✅	⚠️	➖	⚠️
R7 RT	⚠️	⚠️	⚠️	⚠️	✅	⚠️	➖

Key Observations:

R2 (Ray Marching) is difficult to combine with other renderers (different paradigm)
R5 (Deferred) + R7 (RT) is a common hybrid (rasterize G-buffer, trace rays)
R4 (Particles) integrates well with most rasterization approaches
Most hybrids require careful depth/compositing handling

Texture × Texture

	T1 Compress	T3 Atlas	T4 Virtual	T6 Proc	T7 Triplanar	T8 Palette	T12 Detail
T1 Compress	➖	✅	✅	❌	✅	⚠️	✅
T3 Atlas	✅	➖	⚠️	⚠️	⚠️	✅	⚠️
T4 Virtual	✅	⚠️	➖	⚠️	⚠️	⚠️	✅
T6 Procedural	❌	⚠️	⚠️	➖	✅	✅	⚠️
T7 Triplanar	✅	⚠️	⚠️	✅	➖	✅	✅
T8 Palette	⚠️	✅	⚠️	✅	✅	➖	⚠️
T12 Detail	✅	⚠️	✅	⚠️	✅	⚠️	➖

Key Observations:

T1 (Compression) is incompatible with T6 (Procedural) - nothing to compress
T7 (Triplanar) + T6 (Procedural) is a powerful combination for SDF
T3 (Atlas) has mipmap bleeding issues with T12 (Detail)
T4 (Virtual) is a form of atlasing, complex to combine with regular atlases

Animation × Animation

	A1 Key	A2 Skeletal	A4 Proc	A5 VAT	A6 Morph	A8 Flip
A1 Keyframe	➖	✅	✅	⚠️	✅	⚠️
A2 Skeletal	✅	➖	✅	⚠️	✅	❌
A4 Procedural	✅	✅	➖	⚠️	⚠️	⚠️
A5 VAT	⚠️	⚠️	⚠️	➖	⚠️	❌
A6 Morph	✅	✅	⚠️	⚠️	➖	❌
A8 Flipbook	⚠️	❌	⚠️	❌	❌	➖

Key Observations:

A2 (Skeletal) + A6 (Morph) is the standard character animation combo
A4 (Procedural) + A2 (Skeletal) enables IK, physics, layered animation
A5 (VAT) is somewhat isolated - baked simulation doesn't blend well
A8 (Flipbook) is 2D-focused, doesn't combine with 3D techniques

Lighting × Lighting

	M1 Flat	M2 Phong	M3 PBR	M4 Light	M5 SH	M7 Toon	M8 Mat
M1 Flat	➖	❌	❌	⚠️	❌	✅	✅
M2 Phong	❌	➖	⚠️	✅	✅	⚠️	⚠️
M3 PBR	❌	⚠️	➖	✅	✅	⚠️	❌
M4 Lightmap	⚠️	✅	✅	➖	✅	⚠️	⚠️
M5 SH	❌	✅	✅	✅	➖	⚠️	⚠️
M7 Toon	✅	⚠️	⚠️	⚠️	⚠️	➖	✅
M8 Matcap	✅	⚠️	❌	⚠️	⚠️	✅	➖

Key Observations:

M3 (PBR) + M4 (Lightmaps) + M5 (SH) is the standard modern combo
M7 (Toon) + M8 (Matcap) works well for stylized looks
M8 (Matcap) is incompatible with M3 (PBR) - completely different philosophy
Mixing lighting models (M1-M3) on same object looks wrong

LOD × LOD

	L1 Discrete	L2 Continuous	L3 HLOD	L4 Impostor	L5 Stream
L1 Discrete	➖	⚠️	✅	✅	✅
L2 Continuous	⚠️	➖	⚠️	⚠️	✅
L3 HLOD	✅	⚠️	➖	✅	✅
L4 Impostor	✅	⚠️	✅	➖	✅
L5 Streaming	✅	✅	✅	✅	➖

Key Observations:

L5 (Streaming) combines well with everything (orthogonal concept)
L1 (Discrete) + L3 (HLOD) + L4 (Impostor) is a common multi-level approach
L2 (Continuous) is harder to combine (transitions vs discrete swaps)

Spectrum Position × Technique Compatibility

Shows which spectrum positions each technique family works best with.

Geometry Best Positions

Technique	Best D Position	Reason
G1 Billboard	D2-D5	Retained texture, dynamic transform
G2 SDF	D8-D10	Computed per-pixel
G3 Mesh	D1-D6	Retained geometry
G4 Voxel	D5-D8	Can be static or dynamic
G5 Splat	D1-D3	Retained captured data
G6 Nanite	D1	Maximum retention
G8 Noise	D8-D10	Computed per-pixel
G9 Subdiv	D2-D6	Retained control cage
G11 CSG	D2 (baked) / D8 (SDF)	Depends on approach
G13 Height	D2-D7	Retained map, dynamic tess

Rendering Best Positions

Technique	Best D Position	Reason
R1 Forward	D2-D6	Standard retained pipeline
R2 Ray March	D8-D10	Stateless per-pixel
R3 Voxel Cast	D5-D8	Semi-retained voxels
R4 Particle	D3-D7	Mix of retained and dynamic
R5 Deferred	D2-D5	Retained G-buffer approach
R6 Forward+	D2-D5	Retained with compute
R7 RT	D1-D4	Needs retained AS

Full Technique ID Quick Reference

For cross-referencing the matrices:

Geometry: G1=Billboard, G2=SDF, G3=Mesh, G4=Voxel, G5=Splat, G6=Nanite, G7=MeshCompress, G8=Noise, G9=Subdiv, G10=Displace, G11=CSG, G12=NURBS, G13=Heightmap, G14=SpriteStack, G15=StyleTransfer, G16=GeomImage

Procedural: P1=Building, P2=Terrain, P3=Vegetation, P4=ProcTexture, P5=Wang, P6=ComputeGen, P7=Grammar, P8=Fractal

Texture: T1=Compress, T2=Supercompress, T3=Atlas, T4=Virtual, T5=Synthesis, T6=Procedural, T7=Triplanar, T8=Palette, T9=Polynomial, T10=Fourier, T11=Neural, T12=Detail, T14=MaterialID

Rendering: R1=Forward, R2=RayMarch, R3=VoxelCast, R4=Particle, R5=Deferred, R6=Forward+, R7=RT, R8=SoftwareRast, R9=PRT

Compression: C1=Delta, C2=Quantize, C3=Octree, C4=RLE, C5=LZ, C6=Entropy, C7=DAG, C8=PCA

LOD: L1=Discrete, L2=Continuous, L3=HLOD, L4=Impostor, L5=Streaming

Animation: A1=Keyframe, A2=Skeletal, A3=AnimCompress, A4=Procedural, A5=VAT, A6=Morph, A7=BoneBake, A8=Flipbook

Lighting: M1=Flat, M2=Phong, M3=PBR, M4=Lightmap, M5=SH, M6=Probe, M7=Toon, M8=Matcap, M9=SharedMat

Precompute: PRE1=Mipmap, PRE2=Lightmap, PRE3=LOD, PRE4=ShaderCompile, PRE5=NavMesh, PRE6=CollisionSimplify, PRE7=AO, PRE8=SDFBake, PRE9=PVS, PRE10=TexCompress, PRE11=AnimCompress, PRE12=Impostor, PRE13=Cubemap, PRE14=MeshOpt, PRE15=OcclusionData, PRE16=Erosion, PRE17=ProcCache, PRE18=Cluster, PRE19=BVH, PRE20=Voxelize

Mega-Matrix: Core Techniques (Abbreviated)

A condensed view of the most important technique interactions:

	G2	G3	G4	G6	P2	P6	T6	R2	R5	M3	M4	A2	A4	L1
G2 SDF	➖	❌	⚠️	❌	✅	✅	✅	✅	❌	✅	❌	❌	✅	⚠️
G3 Mesh	❌	➖	⚠️	✅	✅	✅	✅	❌	✅	✅	✅	✅	✅	✅
G4 Voxel	⚠️	⚠️	➖	❌	✅	✅	✅	⚠️	⚠️	⚠️	⚠️	❌	✅	✅
G6 Nanite	❌	✅	❌	➖	⚠️	❌	✅	❌	✅	✅	✅	⚠️	⚠️	✅
P2 Terrain	✅	✅	✅	⚠️	➖	✅	✅	⚠️	✅	✅	✅	❌	✅	✅
P6 Compute	✅	✅	✅	❌	✅	➖	✅	⚠️	⚠️	⚠️	❌	⚠️	✅	⚠️
T6 ProcTex	✅	✅	✅	✅	✅	✅	➖	✅	✅	✅	❌	✅	✅	✅
R2 RayMarch	✅	❌	⚠️	❌	⚠️	⚠️	✅	➖	⚠️	✅	❌	❌	✅	⚠️
R5 Deferred	❌	✅	⚠️	✅	✅	⚠️	✅	⚠️	➖	✅	✅	✅	✅	✅
M3 PBR	✅	✅	⚠️	✅	✅	⚠️	✅	✅	✅	➖	✅	✅	✅	✅
M4 Lightmap	❌	✅	⚠️	✅	✅	❌	❌	❌	✅	✅	➖	⚠️	❌	✅
A2 Skeletal	❌	✅	❌	⚠️	❌	⚠️	✅	❌	✅	✅	⚠️	➖	✅	✅
A4 ProcAnim	✅	✅	✅	⚠️	✅	✅	✅	✅	✅	✅	❌	✅	➖	⚠️
L1 DiscLOD	⚠️	✅	✅	✅	✅	⚠️	✅	⚠️	✅	✅	✅	✅	⚠️	➖

Reading the Mega-Matrix

Green diagonal clusters = compatible paradigms:

Top-left (G2, P2, P6, T6, R2, A4): Procedural/Immediate cluster
Bottom-right (G3, G6, R5, M3, M4, A2, L1): Traditional/Retained cluster

Major incompatibilities (❌ patterns):

G2 (SDF) vs G3/G6/R5/M4/A2: SDF vs polygon paradigm
G6 (Nanite) vs P6/G2/R2: Nanite requires pre-built clusters
M4 (Lightmap) vs anything dynamic/procedural

Compatibility Recipes

Recipe: Demoscene 4KB

Techniques: G2 + P4 + P8 + T6 + R2 + M2 + A4 All ✅ compatible - pure procedural, no stored data

Recipe: Mobile Game

Techniques: G3 + G1 + T1 + T3 + R1 + M4 + A2 + L1 + L4 All ✅ compatible - traditional retained, baked lighting

Recipe: Open World AAA

Techniques: G6 + G3 + P2 + T4 + R5 + R7 + M3 + M4 + A2 + L1 + L5 All ✅/⚠️ compatible - Nanite + traditional with streaming

Recipe: Voxel Sandbox

Techniques: G4 + P6 + T8 + R3 + M2 + A4 + C7 All ✅ compatible - voxel-focused stack

Recipe: Stylized Indie

Techniques: G3 + G9 + T6 + T8 + R1 + M7 + M8 + A2 + A4 All ✅/⚠️ compatible - stylized with procedural touches

Incompatibility Patterns Summary

Fundamental Paradigm Splits

SDF/RayMarch vs Polygon/Rasterize
- G2, G8, G11(SDF), R2 ←❌→ G3, G6, G9, R5, R6
Procedural vs Precomputed
- P4, P6, T6, A4 ←❌→ M4, PRE2, PRE3, PRE7
Retained vs Immediate
- G6, L3, L4, M4 ←❌→ D8-D10 techniques
UV-Required vs UV-Free
- T1, T3, T4, M4 ←❌→ G2, G4, G8, G11

Why These Splits Exist

Split	Root Cause
SDF vs Polygon	Different mathematical representation of geometry
Procedural vs Precomputed	Precomputation requires storage, procedural requires compute
Retained vs Immediate	Data flow and state management fundamentally different
UV vs UV-Free	Texture mapping requires surface parameterization

Saturday, January 31, 2026

a shopping we will go

Minimal 3D Game Asset Encoding Techniques

Table of Contents

Data Dynamism Spectrum (Immediate ↔ Retained)

The Spectrum

D1: Fully Retained World Scene Graph on GPU

D2: Retained Scene Graph, CPU Transform Updates

D3: Retained Meshes, Dynamic Materials/Textures

D4: GPU-Driven with CPU Feedback

D5: Mixed Mode - Instanced Static + Dynamic Objects

D6: CPU-Driven Rendering, Retained Buffers

D7: Streaming Geometry (Partial Retention)

D8: Per-Frame Geometry Generation (GPU)

D9: Per-Frame Full Rebuild (CPU → GPU)

D10: CPU Software Rendering

Why Immediate Mode Matters for Development

Immediate Mode Techniques Expanded

IM1: Ray Marching SDFs (Fully Immediate)

IM2: Compute-to-Render Direct Pipeline

IM3: Uniform-Driven Procedural Geometry

IM4: Screen-Space Everything

IM5: Stateless Shader Uniforms

IM6: The "Fullscreen Quad + Math" Pattern

IM7: Instanced Procedural Primitives

IM8: Temporal Statelessness (No Frame Dependency)

IM9: Parameter Space Exploration

IM10: Debug Injection Points

Immediate Mode Performance Patterns

IMP1: Hierarchical Early-Out

IMP2: Level of Detail via Iteration Count

IMP3: Resolution as LOD

IMP4: Shader Complexity Budget

The Immediate Mode Development Loop

When Retained Mode is Actually Necessary

Interactive Shader Development & Debugging

The Problem with Current Shader Debugging

What We Actually Want: Shader REPL/Notebook

DEB1: Pixel-Level Trace Capture

DEB2: Hot-Reload with State Preservation

DEB3: In-Editor Visualization HUDs

DEB4: Value Inspection via Color Mapping

DEB5: Time-Travel Debugging

DEB6: Differential Rendering

DEB7: Shader Profiling Integration

S-Expression Based Shader Language

SEXPR1: Core Language Design

SEXPR2: Compilation Targets

SEXPR3: Example Macro Power

SEXPR4: Domain-Specific Extensions

SEXPR5: Debugging Integration

SEXPR6: Existing Work & Tools

SEXPR7: Minimal Kernel Language Approach

SEXPR8: The REPL Experience

Engine Compatibility Notes

Compatibility Rating Scale

Engine Architecture Summary

Technique Compatibility Matrix

Geometry Techniques

Procedural Techniques

Texture Techniques

Rendering Paradigms

Animation

Immediate Mode & Debugging

Integration Strategies by Engine

Godot 4 Integration

Unreal Engine 5 Integration

Unity Integration

Recommended Engine by Technique Priority

The "Escape Hatch" Approach

Future: WebGPU as Universal Target?

Spectrum Position Affects Compression Strategy

Mapping Other Techniques to Spectrum

Observed Patterns & Principles

Pattern 1: Rightward Dependency (Immediate Can Use Retained, Not Vice Versa)

Pattern 2: Compression Relevance Inversely Correlates with Dynamism

Pattern 3: Debugging Ease Correlates with Dynamism

Pattern 4: Engine Compatibility Inversely Correlates with Dynamism

Pattern 5: The "Goldilocks Zone" is D5-D6

Pattern 6: Procedural Techniques Cluster at D8