Surfacing is everything between a finished model and a validated asset in-engine - and a repeatable pipeline beats per-asset improvisation every time.
What "Surfacing" Actually Means
Ask three studios what "surfacing" means and you'll get three different answers. At one studio it's purely the artistic side: developing materials. At another it includes the technical side too: figuring out which textures need to be created and where they go, running performance tests, setting up the pipeline itself. At others, a programmer handles all the foundational setup and the artist never touches it.
Both models have pros and cons. When the technical side is handled for you, you can focus entirely on the craft but you never get the full picture of what your data is doing, how it's being applied, and it usually means less artistic freedom with the shader: most likely you get handed a black box, built around performance first. It's also why the job is hard to explain when applying elsewhere, the title stays the same, but the expectations shift completely per company.
For this post, surfacing covers the whole span: from reference gathering through authoring, packing, engine setup, and optimization, ending at a validated asset in-engine. That's deliberately wider than "just texturing", texturing is one stage in the middle of it.
This is how I've seen it work across studios and conversations with others in the industry - your mileage may vary.
Inputs and Prerequisites
A shader can't fix what arrives broken. Before you can start authoring, a few things have to be true: clean topology, non-overlapping UVs; an agreed texel density target (coming in one of the future blogposts); a naming convention everyone follows; and reference gathered and approved by art direction. Each of these is cheap to enforce at intake and expensive to fix after twenty or more assets are built.
As an example: I once had an asset where messed-up topology and wonky normals propagated into the bakes, making the curvature read far too extreme and throwing off other features in the shader. It made the real problems hard to see through the noise - a perfect example of a broken input that no later stage could hide.
Reference and Calibration
I've covered the why in Day 11 - 💡 Insight - Why Photo Reference Changes Everything and the how in Day 14 - ⚡️ Quick - Using Gloss Meters for Surface Measurement. In the pipeline, what matters is the when: values and gloss get locked (ideally) before authoring starts, not adjusted afterward to taste. These decisions also depend on where you actually settle with the art style, but the sooner you can lock down the rules, the less you have to keep iterating on assets. If calibration lands when you're already a few assets in, those assets need to be reprocessed to bring them back into the correct ranges.
Calibration also needs a where and a who. The where is a neutral, controlled lighting scene in-engine: PBR standardizes the physics, but every engine has its own roughness curve and tone mapping quirks, so values that look right in Substance can read different when rendered in engine. The who is art direction: a value isn't calibrated because it looks right to you; it's calibrated when it's signed off and becomes a rule the rest of the pipeline can trust.
Material Authoring
The core authoring stage and the one I've written about most, so I'll keep it to the pipeline view: the approach in Day 6 - 🛠️ Behind the process - Approaching Material Creation, the library structure in Day 12 - 🛠️ Behind the process - Building a Material Library. The pipeline question at this stage is reusable vs. bespoke: does this asset pull from the shared library (fast, consistent, one point of update) or does it justify bespoke work (hero assets, unique storytelling surfaces)? The ratio between those two is a budget decision, not an artistic one.
Do you need full texture bake-downs, or can it be composited in-engine? Compositing gives you more flexibility in propagating changes from the material library, but less room for bespoke details or storytelling - things will look a bit more generic, but consistent across the board. My preference is to first build the base materials that will dictate 70-80% of the materials you expect to see in your game; you can still reference those in Painter or Designer when texturing your bespoke bakes, or simply use them directly as composited materials in-engine.
There are always edge-cases that will throw a wrench in your pipeline; that is to be expected. Not all pipelines transfer equally between asset-types; characters need a different setup than your environment kits.
Texture Sets and Channel Packing
The in-tool vs. in-engine packing tradeoff is in one of the upcoming blogposts. What belongs here is the convention itself: which maps go in which channels, and why it must be project-wide rather than per-asset. Resolution decisions follow from texel density targets, not from what looks nice in isolation. And alpha is never free, an alpha channel doubles BC7 block cost considerations and should be a deliberate choice per texture set.
Depending on the quality bar, I would pack the color separately, but pack normals with roughness and the metalness mask in a BC7, it gives me good precision for what I need. If I need custom masks, I can pack them with AO in a BC3 at half resolution. Not everything needs to be at max res; some maps can be lower resolution because no one ever sees them up close, or we cover it up with tricks in the shader. All context- and asset-type dependent.
Shader and Engine Setup
Where the textures meet the renderer. The recurring tradeoff: permutations vs flexibility. Every exposed parameter makes the master material more flexible and the shader more expensive; every hardcoded decision makes it cheaper and more rigid. The same question applies to what needs to change per instance. The pipeline answer is to expose what varies per asset and lock what doesn't. The same goes for where materials get assigned (in the DCC vs. in-engine): which side you land on matters less than that it's decided once, for everyone.
Typically I would expose: tiling rate, color or tint, and settings for parallax occlusion mapping. Some of these are per-instance dependent, some aren't. Exposing certain texture inputs is also helpful - the more code or nodes you can reuse, the better.
Optimization and LODs
By this stage, the work is mostly mechanical if the earlier stages were consistent: compression, mip generation, and fading features out over distance to strip cost - lower-resolution sets or dropped alpha for far LODs, driven by the pixel-coverage math in Day 7 - ⚡️ Quick - Pixel Coverage Calculations and the LOD decisions that follow from it. The point for the pipeline: optimization is a pass, not a rescue. If it's where problems get discovered, the validation gate is in the wrong place.
Validation Pass
The QA gate before anything ships: automated checks for texel density in range, missing or duplicate maps, naming, resolution budget - and human eyes for the things scripts can't judge, like whether a material reads correctly in context. The short version: define what "valid" means, script what's scriptable, and make the gate impossible to skip quietly. I'll be putting this to the test against a real asset set in an upcoming post.
Handoff and Documentation
A pipeline that only works while you're in the room isn't a pipeline - it's a dependency. The principles are simple: document for the person who comes after you, keep it accessible, keep it maintained (a topic that deserves its own post, and will get one). For surfacing specifically that means: when to assign which shader, what are the exceptions in the pipeline, the texture packing methods, the texel density targets, the naming rules, and the validation criteria all written down where a vendor or new hire finds them on day one.
Closing Thought
Every stage of this pipeline gets cheaper when the stage before it is consistent. It's kind of like compound interest: the consistency accumulates, and it pays off in performance and lower development cost because there's less iterating needed. Locked reference makes authoring decisive. Consistent texel density makes packing and resolution decisions automatic. A followed naming convention makes validation scriptable. Consistency upstream is what makes the downstream cheap - improvisation just moves the cost to whoever touches the asset next.
© 2026 Stefan Groenewoud. All views are my own, not those of my employer.