Six renderers, one page
The problem
Building a new WebGL scene on every slide change leaks GPU memory and listeners if the old one lingers.
What I did
Gave each scene a create and dispose lifecycle so only the active slide has a renderer.
Case study
WebGL Academic Presentation
A seminar slide deck where every slide runs its own live Three.js scene.
- Next.js
- React
- TypeScript
- Three.js
In the product
Screens are recreated from the app’s real UI with fictional demo data.
The core problem
What needed solving
Slides about WebGL are more convincing when the slides themselves are WebGL, so each technique had to be demonstrated live rather than described.
The solution
What I built
Six slides each pair notes with a live canvas; every slide change disposes the old renderer and builds the next, and /highway and /bunker open straight on their demos for jumping mid-talk.
A Next.js page laid out like a slide deck for a graduate seminar on browser-based 3D visualization. A sidebar carries each slide's points while a full-height canvas runs that slide's Three.js scene: a 30,000-point cloud, a 3D equation plotter, an icosphere point cloud, GLB model loading, a highway driving demo and an FPS target-practice scene. The seminar paper and slides, which review three WebGL research papers, live alongside it.
Integration
How it fits together
One client component drives the deck: each slide pairs sidebar notes with a Three.js renderer created for that slide, and switching slides disposes the old renderer before building the next. The /highway and /bunker routes open the same deck on their slide. The seminar paper and slides sit in docs/.
The flow, step by step
- Start the Next.js dev server and open the deck.
- Step through the six slides with Back and Next.
- On slide 2, pick an equation and orbit the plot with the mouse.
- Open /highway to steer with A/D, or /bunker for mouse-look target practice.
Problems along the way
What got hard, and what I did about it
Controls that fought the page
The problem
The FPS slide listened on the whole window, so using the sidebar turned the camera and Back/Next fired a shot.
What I did
Scoped its input handling to the scene so the rest of the deck works normally.
A legend that vanished
The problem
An unclosed CSS rule swallowed the chart legend and axis-label styles on the plotting slide.
What I did
Closed the rule so the legend and X/Y/Z labels render as designed.
Takeaways
What I learned
- Live demos make a technical talk, but each slide has to be robust enough to run in front of an audience.
- Disposing WebGL resources matters as much as creating them.
Outcome
Where it stands today
GPU point cloud of 30,000 points in a single BufferGeometry.
3D equation plotter with five equations, projected axis labels and OrbitControls.
GLB asset loading with GLTFLoader and a highway driving demo with eased steering.
FPS target practice with raycast hits from the crosshair.
Milestones
- Shipped
Six live slides
Point cloud, equation plotter, icosphere, GLB loading, highway and FPS scenes.
- Shipped
Build and styling fixes
Fixed the TypeScript build error and the CSS rule that hid the chart legend.