From code to catalog: 117 materials, zero handcrafting
A material library is easy to start and hard to keep. The tenth material is fun. The hundredth, hand-tuned at 2am to match the first ninety-nine, is how libraries quietly rot. We took a different route: generate them from code, and let a validator be the gate.
The handcrafting trap
Author materials one by one and every addition is a small negotiation with consistency. Was this powder coat as rough as the last one? Did this normal map get the same strength? Six months in, the library is a museum of slightly different decisions, and nobody wants to touch it.
The fix is to stop treating each material as a artefact and start treating it as the output of a recipe.
Templates, not files
Behind the library sits a small set of procedural templates: powder coat, brushed metal, galvanised, hammered, woven composite, print filament, textured glass, and a handful more. Each is a bit of code that bakes its detail (the orange-peel of a coating, the spangle of galvanising, the layer lines of a 3D print) into clean textures at build time.
A material is then just a few parameters on a template: a colour, a roughness, how much wear. Change a number, rebuild, done. Nobody edits a node graph by hand.
A hundred variants from a matrix
Once a template exists, breadth is nearly free. A single line describing "powder coat, these ten RAL colours, fresh and lightly worn" expands into twenty finished materials, each with a proper name and metadata. That is how ten templates become well over a hundred materials without a hundred files to maintain, and how a new RAL colour is a two-minute job instead of an afternoon.
Validation as the gate
Generating quickly is only safe if something catches mistakes. Every material runs through an automated check before it is allowed into the library: is it strict glTF, is it under the texture budget, does the metallic-roughness and occlusion share one image the way the exporter needs, is the alpha mode explicit. If a material does not pass, it does not ship.
The validator is the quality floor. It is why the hundredth material is exactly as trustworthy as the first, and why we can keep adding without fear.
Ingesting the real world where procedural stops
Some surfaces are genuinely photographic: a specific diamond tread plate, a scanned finish. For those we pull CC0 texture sets from open libraries, normalise them into the same format every other material uses, and pin them by checksum so a build is always reproducible. Procedural where it wins, photographic where it wins, one consistent output either way.
The payoff
The reference pack we set out to match ships ninety materials. The library now holds a hundred and seventeen, plus parametric hardware and HDRI environments, and it is still cheap to grow. More importantly, it stays coherent: every asset looks like it belongs to the same set, because it does. It came off the same line.