Starting without a defined pipeline isn't a problem. It's the first design decision.
Before you build anything, you need to know what you're building toward. A new project without a defined pipeline means a sequence of open questions: where do the meshes live, where do the textures go, what's the naming convention, who owns what. Getting those answered early isn't overhead; it's the work.
In a studio environment some of these decisions are already made. The folder structure exists, the naming convention is documented, the engine integration is handled. That narrows the surface area considerably. This post focuses on the rendering and shading side, which tends to have the most open questions regardless of how much is already set.
Start With Questions, Not Tools
The instinct is to open a tool and start building. Resist it.
The first step is identifying what the pipeline actually needs to answer. For shaders and materials, that usually means:
What's the minimum viable prototype? You don't need a complete system to start a conversation with art direction, creative leadership, or game design. You need something that represents the key decisions: surface type, texture packing approach, shader parameters. Build the smallest thing that gets that conversation started and share it with the teams to get the conversations going and start iterating on the prototype.
How are you packing textures? The two options are packing in your authoring tool (Substance Designer or Painter) or handling it in-engine. Packing in-tool is explicit and portable, but also a little destructive because the maps are 'baked in'. Packing in-engine keeps things more flexible; if channel assignments change downstream, you're not rebaking and reexporting everything. The right answer depends on how stable the shader requirements are expected to be, and how much content you need to touch whenever a change does come in.
Where are materials assigned? Some pipelines export meshes from the 3D package with materials already assigned. Others assign everything inside the engine, Unreal-style, where the material slot assignment lives in the asset. Each has tradeoffs around iteration speed and dependency management.
None of these have universal answers. But you need them answered and documented before anyone else starts building assets against your assumptions.
The Scalability Question
Once the basic structure is clear, the next question is whether it needs to scale and in what direction.
A pipeline built for a linear single-player game has different requirements than one supporting a live-service title with per-instance customization or dynamic changes like seasonal content. For the latter, you need to know upfront: does the material system need to support runtime overrides? Can players or designers tint assets? Does a single mesh need to support multiple material states without duplicating geometry or duplicating a lot of texture data?
These aren't afterthoughts. If a pipeline doesn't account for per-instance variation at the shader level, retrofitting it later means touching every asset that needs to support it.
The questions I use to identify scalability requirements:
- Is the pipeline serving one project or multiple: If multiple, what's shared and what's project-specific?
- Does the system need to support per-instance overrides at runtime?
- What are the exceptions: are there asset types that sit outside the standard pipeline, and how are those tracked?
- How flexible does texture packing need to be: if shader requirements change mid-production?
You won't have answers to all of these at the start. But knowing which questions are open is useful in itself, it tells you where to leave flexibility and where you can afford to commit early.
Getting to a Prototype
For the shading side specifically, I aim to get a working prototype covering the main surface types the project needs; typically one metal, one organic or fabric, one hard surface with standard game wear. Not a complete library. Enough to start the look-dev conversation and validate the shader assumptions.
The prototype also validates the pipeline assumptions. If texture packing in-engine is the plan, a prototype reveals whether that works at the quality level the project actually needs. If it doesn't, better to know before twenty assets are built against wrong assumptions.
The alignment and reference process from Day 6 - 🛠️ Behind the process - Approaching Material Creation applies directly here: talk to art direction first, gather reference, validate in-engine before committing to a direction.
Closing Thought
Pipeline structure isn't glamorous, but it compounds. A well-defined pipeline means every artist who joins after you can get to work faster. A poorly defined one means every new person spends their first week reverse-engineering decisions that were never written down.
Answer the questions early. Document what you decided and why. Leave room for the things you know will change.
© 2026 Stefan Groenewoud - All views are my own, not those of my employer.