Optimizing raymarched and SDF scenes for performance
Learning objectives
- learner can accelerate raymarching with bounding volumes, cone-traced level-of-detail, and hybrid grid traversal
- learner can reason about the compute-vs-bandwidth trajectory that made primitive SDFs competitive
Capstone — one whole task that evidences the objectives
Profile and optimize a raymarched SDF scene: add a bounding-volume early-out, cone-traced view-dependent stepping, and a hybrid grid+SDF traversal for sparse cells, measuring the step-count reduction — then write a short justification of which optimizations to prioritize on future hardware, applying the compute-vs-bandwidth trend that made primitive SDFs competitive.
Prerequisite modules
In a live visual set, a raymarched scene that drops below frame rate is not a rendering bug — it is a dead screen in front of an audience. Shader visuals for club and algorave performance run fullscreen on whatever GPU the venue laptop has, often while the same machine hosts the audio engine, so an SDF scene that burns hundreds of march steps per pixel on empty space will stutter exactly when the crowd is watching. This module builds toward one whole task: take a working but naive raymarched scene, profile where the steps go, and claw the budget back with three complementary attacks.
The arc starts supported. First, wrap the expensive part of the scene in a cheap bound and verify the win — the atom on testing a cheap bounding primitive before the full SDF is your JIT pointer for structuring that early-out. Next, replace the constant hit epsilon following the atom on making the hit threshold proportional to distance, and watch distant geometry both smooth out and terminate early. Then tackle empty space itself: the principle of combining fast grid traversal with local SDF raymarching shows how to leap over sparse cells instead of crawling through them. The capstone repeats all three unsupported, with step-count measurements as evidence, and closes with a written justification of which optimizations to prioritize going forward.
Each required atom gates the capstone directly — skip one and an optimization is missing or unmotivated; the GPU compute-versus-bandwidth history is what the closing justification draws on to argue which trade-offs will keep paying off on future hardware. The supporting atom on ray differentials for antialiasing enriches the picture: a costlier image-quality path you can weigh once the performance work lands.
Runnable examples
Generated from the context/ instrument corpus by concept (redistributable idioms only). Do not edit — regenerate with gen-module-examples.mjs.
raymarch-sdf
vec3 nrm(vec3 p){vec2 e=vec2(.001,0);return normalize(vec3(map(p+e.xyy)-map(p-e.xyy),map(p+e.yxy)-map(p-e.yxy),map(p+e.yyx)-map(p-e.yyx)));}
glsl-0033 · public-domain
Atoms in this module
Required — these gate the capstone
Supporting — enrichment, not gating
Part of curricula
- Shader Artist — real-time GPU craft to a demoscene-grade visual — Lighting, PBR, and optimized raymarched scenes required