WebGL renderer and authoring tool for procedural fashion
A browser-based 3D renderer for procedurally generated trainers — serving as both the showcase viewer and the authoring tool creators used to build new designs.
Overview
Contract engagement on a digital fashion platform starting with trainers. Footwear was authored as a component system — uppers, soles, decals, add-ons — that could be recombined into a vast space of colourways and styles. The WebGL renderer displayed the results and doubled as the tool creators used to author them, all in the browser.
Problem
A procedurally generated product catalogue only works if the generation space is genuinely large and the results genuinely look designed. That needs a component model expressive enough to combine without producing nonsense, and a renderer good enough that a generated trainer reads as a real product rather than a parameter dump. Both had to run in a browser, on consumer hardware, for an audience that would not install anything.
Constraints
- Browser-only — WebGL, no native client, no plugin
- Same renderer serves two audiences: viewers showing off items and creators authoring them
- Component system had to generate a large space without producing invalid combinations
- Part of a wider platform: collection and trading handled by separate Golang, Rust and Vue services
Approach
Model footwear as composable components with constrained attachment points, so combinations are valid by construction rather than validated after the fact. Build one WebGL renderer with a viewing mode and an authoring mode, sharing the same scene and material pipeline, so what a creator authors is exactly what a viewer sees.
Key Decisions
One renderer serving both viewing and authoring
A separate authoring tool would have meant two rendering paths and a permanent class of bug where the authored result and the displayed result disagree. Sharing the pipeline made what-you-see-is-what-you-get structural rather than something to maintain.
- Desktop authoring tool with a web viewer
- Offline pre-rendered images per combination
Constrained component composition rather than free-form assembly
Attachment points and compatibility rules keep the generated space large while making invalid combinations unrepresentable. Cheaper than validating outputs, and it gives creators a design space rather than a blank canvas.
- Free-form part placement with validation
- Fixed template variants with colour customisation only
Render in the browser rather than serving pre-rendered assets
The combination space was far too large to pre-render, and live rendering is what makes authoring interactive at all. It put the performance burden on the client, which the component model was designed to keep manageable.
- Server-side rendering with cached images per combination
- Fixed camera angles rendered ahead of time
Tech Stack
- JavaScript
- WebGL
- GLSL
Result & Impact
- None — browser onlyInstall required
- Viewer and authoring tool in oneRenderer
Delivered a browser renderer that handled both showcase viewing and creator authoring from one pipeline, over a component system that generated a large space of valid designs. The surrounding collection and trading platform was built on Golang, Rust and Vue with Ethereum-based ownership — the market for which subsequently collapsed, though the rendering and procedural generation work stands independently of it.
Learnings
- Making invalid states unrepresentable in the component model beats validating combinations after generation — it is less code and a better authoring experience
- When the same renderer drives authoring and display, WYSIWYG stops being a feature you maintain and becomes a property of the architecture
- Procedural catalogues live or die on whether output reads as designed rather than generated, and that is a content-modelling problem more than a rendering one