Free Digital Art learning guide

Intermediate 3D Texturing and Shading Roadmap

Name: Intermediate 3D Texturing and Shading Roadmap
Author: Tanmay Kalbande

Intermediate 3D Texturing and Shading Roadmap — a free intermediate-level guide covering intermediate 3d texturing and shading techniques. Learn with...

121 min read13 chaptersintermediate

What you will learn

Fundamental Review: UVs and Basic Materials
Advanced UV Techniques and UDIM Workflows
Physically-Based Rendering (PBR) Deep Dive
Procedural Texturing with Substance Designer
Hand-Painted Detail Maps and Masking
High-Poly Baking and Advanced Normal Mapping
Node-Based Shader Construction (Unreal/Unity/Blender)
Real-Time Optimization: Atlasing, LODs, and Mipmaps
Custom Shader Programming Basics (HLSL/GLSL)
Advanced Shading Effects: Anisotropy, SSS, and Clear Coat
Texture Painting Workflow in Substance Painter & Mari
Look Development, Color Grading, and HDRI Integration
Pipeline Integration, Asset Management, and Version Control

1. Fundamental Review: UVs and Basic Materials

The Moment the Texture Tears Imagine you’ve just imported a freshly modeled sci‑fi helmet into your engine. The geometry looks clean, the normals are baked, and the material slots are ready. You drop a simple diffuse map onto the shader—and the whole thing looks perfect—until you rotate the camera. Suddenly a large stretch ripples across the visor, the painted logo is smeared, and the once‑sharp edge appears blurry. The culprit isn’t the texture file; it’s the UV layout. That split‑second “aha!” moment—realizing that a 2‑D image is being forced onto a 3‑D surface—highlights why solid UV fundamentals are non‑negotiable. In this chapter we’ll: Refresh how UV coordinates map textures onto geometry. Spot the most common distortion pitfalls and apply quick fixes. Build a minimal set of diffuse, specular, and normal maps and wire them up in a real‑time engine. By the end, you’ll be able to diagnose a stretched texture, correct the UVs, and see a clean, lit result without having to rebuild the model from scratch. --- UV Coordinates and Texture Space What UVs Are U and V are the horizontal and vertical axes of a 2‑D texture space, analogous to X and Y in Cartesian coordinates. Each vertex of a mesh stores a pair of UV values that tell the renderer where on the texture to sample color data for that point. Key point: UVs are normalized—they typically range from 0.0 to 1.0—so a value of (0.5, 0.5) samples the centre of the image regardless of the image’s pixel dimensions. UV Layout Conventions | Convention | Meaning | Typical Use | |------------|---------|-------------| | 0‑1 UV space | Full coverage of the texture | Most game engines; easy to tile | | UDIM (not covered here) | Multiple tiles per object | Advanced pipelines | | Mirror/Repeat | UVs outside 0‑1 wrap or mirror | Tileable surfaces, procedural textures | Keeping all islands inside the 0‑1 square prevents unintended tiling and ensures that mip‑mapping behaves predictably. How UVs Relate to 3‑D Geometry When the GPU rasterizes a triangle, it linearly interpolates the UVs across the face. The fragment shader then looks up the texture using those interpolated coordinates. If the UVs are non‑uniformly spaced, the interpolation will produce stretch or compression in the final image. A quick mental model: imagine stretching a rubber sheet (the texture) over a wireframe (the mesh). Where the sheet is pulled tighter, the image appears stretched; where it’s slack, the image compresses. --- Common UV Distortion Issues 1. Stretch & Compression Stretch occurs when the distance between two UV points on the texture is larger than the corresponding edge length on the mesh. Compression is the opposite—texture pixels are crammed into a small area …

2. Advanced UV Techniques and UDIM Workflows

When a Single UV Island Isn’t Enough Imagine you’re tasked with creating a hero character for a next‑gen RPG. The model has a sculpted face, intricately detailed armor, and a flowing cloak. The art director demands 4 K texture resolution for the face, 2 K for the armor, and a seamless pattern on the cloak that can repeat without visible seams. A single UV island, even with perfect packing, would force you to share the same texel budget across the entire mesh, leading to blurry facial features and stretched fabric. The solution? UDIM tiling — a workflow that lets you allocate texture space where it matters most, while keeping the UVs organized in a grid that modern texturing tools understand natively. Below we’ll dive straight into the mechanics that turn that “single island” limitation into a flexible, high‑resolution canvas. We’ll cover how to set up UDIM layouts, exploit advanced packing algorithms, and keep seams under control so your tiled textures stay clean and artifact‑free. --- 1. UDIM vs. Traditional UV Islands 1.1 What Makes UDIM Powerful Tile‑based organization – Each tile (U V 0‑based) is a 0‑1 UV square that maps to a separate texture file (e.g., characterdiffuse1001.png). Independent texel density – You can give the face a 10 texels/pixel density while the boots sit at 2 texels/pixel, all within the same object. Seam‑friendly workflow – Texturing tools treat each tile as a separate “canvas,” letting you paint detail without worrying about UV bleeding across distant parts of the mesh. Scalability – Adding more tiles is just a matter of extending the grid; you never run out of UV space as you would with a single 0‑1 island. 1.2 When to Prefer UDIM | Scenario | Reason to Use UDIM | |----------|-------------------| | High‑poly characters with facial detail | Allocate dedicated tiles for the head, eyes, and teeth | | Large props (vehicles, architecture) | Split long surfaces into sequential tiles to avoid stretching | | Materials that repeat (fabric, metal panels) | Keep repeatable UVs on their own tiles for clean tiling | | Multi‑material assets | Separate tiles per material to simplify shader setups | If your asset fits any of the above, you’re already looking at a more efficient texture pipeline. --- 2. Setting Up a UDIM Layout 2.1 Choosing a Tile Grid 1. Start with a logical numbering scheme – Most pipelines use the Maya/Arnold convention: tile 1001 is the bottom‑left (U 0‑1, V 0‑1), 1002 is one step right, 1011 is one step up, etc. 2. Reserve tiles for each logical group – 1001 – Base body (low‑detail) 1002 – Face (high‑detail) 1003 – Eyes 1011 – Upper armor 1012 – Lower armor 1013 – …

3. Physically-Based Rendering (PBR) Deep Dive

Metallic‑Roughness vs. Specular‑Glossiness: Two Paths to the Same Goal When you drop a polished steel sphere onto a street‑level HDRI, the glint that races across its surface is instantly recognizable. Yet that same visual cue can be produced by two mathematically different pipelines. Understanding why the pipelines differ—and when each is preferable—is the first step toward mastering PBR shading. | Aspect | Metallic‑Roughness (M‑R) | Specular‑Glossiness (S‑G) | |--------|--------------------------|---------------------------| | Primary scalar maps | Metallic (0 = dielectric, 1 = metal) + Roughness (0 = smooth, 1 = rough) | Specular (color/reflectivity) + Glossiness (inverse of roughness) | | Base color handling | Albedo stores diffuse for dielectrics and reflectance for metals (no separate specular) | Albedo stores pure diffuse, while specular map carries the reflective component | | Industry adoption | Dominant in real‑time engines (Unreal, Unity, Godot) | Common in offline renderers (Arnold, V-Ray) and some legacy pipelines | | Data size | 2‑channel (metallic + roughness) can be packed into a single texture (e.g., R=metallic, G=roughness) | 2‑channel (specular + glossiness) similarly packable | Both pipelines obey the same energy‑conservation principle: the sum of reflected and refracted light cannot exceed the incoming light. The difference lies in where the reflectivity information lives. In the metallic‑roughness model, the metalness flag determines if the surface uses the albedo as a Fresnel term (for metals) or as a diffuse color (for dielectrics). In the specular‑glossiness model, a specular color directly supplies the Fresnel reflectance for every pixel, allowing subtle variations (e.g., a painted metal with a slightly tinted specular). When to Choose Which Pipeline 1. Real‑time pipelines – Most game engines expose a metallic‑roughness workflow; using it avoids costly texture swaps and aligns with engine defaults. 2. Artistic control over non‑metallic specular – If you need to vary specular tint across a ceramic tile (e.g., a glaze that is slightly pink), the specular‑glossiness map gives you that nuance without fiddling with metallic masks. 3. Legacy assets – Older production pipelines may already contain specular‑glossiness maps; converting them to M‑R can introduce artifacts if not done carefully. Practical tip: When starting a new asset for a real‑time engine, default to the metallic‑roughness workflow. Reserve specular‑glossiness for cases where you need per‑pixel specular tint that cannot be expressed via a simple metal mask. --- Building a Complete PBR Texture Set A full PBR material typically consists of five texture maps: | Map | Purpose | Typical channel layout | |-----|---------|------------------------| | Albedo / Base Color | Diffuse reflectance (dielectrics) or combined reflectance (metals) | RGB = color, A = optional opacity | | Metallic | Binary or grayscale mask for metal vs. dielectric | R = metallic (0‑1), G/B = unused | …

4. Procedural Texturing with Substance Designer

From a Single Tile to a Whole World You’ve just received a high‑poly fantasy sword that will be the centerpiece of a game‑ready asset pack. The model’s UVs are clean, the UDIM layout is already split into three tiles (Base‑Color, Roughness, Normal). Instead of painting every detail by hand, you want a material that can instantly generate variations—rust‑streaked steel, weathered leather straps, and a hint of grime—while still fitting any future meshes that share similar UV conventions. This is exactly where Substance Designer’s node‑based procedural workflow shines: a single reusable graph can produce a complete texture set, be tweaked on‑the‑fly with parameter masks, and be packaged as a Smart Material that automatically respects the target mesh’s UV layout. Below is a step‑by‑step guide that walks you through building such a material, adding controllable wear, and turning the result into a smart asset ready for export to any engine. The techniques assume you have already internalised UV fundamentals (see Fundamental Review), UDIM handling (Advanced UV Techniques), and the basic PBR concepts (PBR Deep Dive). --- 1. Constructing a Base Procedural Material 1.1. Setting Up the Graph 1. Create a new Substance – File ► New Substance. Choose “2D (Baking)” as the template; the default output nodes (Base Color, Roughness, Normal, Height) match the PBR workflow you studied earlier. 2. Rename the graph to something descriptive, e.g., SwordMetalProcedural. Good naming habits pay off when you build libraries later. Tip: Keep the graph “Untitled” until you’ve decided on a final name; renaming later forces the system to update internal references. 1.2. Building the Core Tile The core of a metal material can be assembled from a handful of classic nodes: | Node | Purpose | Typical Settings | |------|---------|------------------| | Noise | Generates a base grain pattern | Type: Perlin‑Fractal, Scale: 0.5, Seed: 42 | | Directional Warp | Introduces anisotropic streaks that mimic brushed metal | Input 1: Noise, Input 2: Noise (offset), Warp: 0.2 | | Levels | Controls contrast of the grain | Input: Warp output, In Low: 0.3, In High: 0.8 | | Blend (Normal) | Mixes a subtle bump map into the normal channel | Mode: Overlay, Opacity: 0.15 | 1. Noise → Directional Warp → Levels → connect to Base Color (as a greyscale texture). 2. Duplicate the Levels output and feed it into a Normal‑From‑Height node; connect that normal to the Normal output. 3. For Roughness, use a Histogram Scan on the same Levels output, then invert (1‑x) to keep bright areas smoother. The result is a clean, repeatable metal tile that can be tiled across any UV space without obvious seams—thanks to the mirror/repeat tiling mode you learned in the UV chapter. 1.3. Adding a …

5. Hand-Painted Detail Maps and Masking

Why Hand‑Painted Details Still Win the Day When you look at a high‑resolution screenshot of a game asset, the first thing that catches the eye is often the subtle grit on a worn edge or the way light rolls off a dent. Those “tiny” cues are rarely the product of a single procedural node; they are the result of an artist’s intent, captured by hand‑painted detail maps. Imagine you are tasked with creating a rusty, weathered barrel for a first‑person shooter. The barrel’s base material is a clean, baked‑metal PBR texture, but the scene demands that the bottom edge be heavily scraped, the sides show a thin film of oil, and a few random rust patches appear where water has pooled. Procedural generators can give you a decent base, but achieving the precise storytelling nuance—where a bullet impact leaves a fresh scar—requires you to paint directly onto the mesh. This chapter shows you how to: Paint high‑frequency normal detail with a graphics tablet, bypassing the need for a high‑poly sculpt. Generate and refine Ambient Occlusion (AO) and curvature maps that amplify shading contrast without inflating texture memory. Combine hand‑painted masks to drive wear, rust, and edge‑wear effects, giving you granular control over where each secondary material appears. All of this builds on the UV fundamentals from Fundamental Review: UVs and Basic Materials and the UDIM workflow discussed in Advanced UV Techniques and UDIM Workflows. Let’s dive in. --- Preparing the Mesh for Direct Normal Painting Before you open your favorite painting application, the mesh must be ready to receive high‑frequency detail. 1. UV Layout Review Verify that the mesh’s UV islands occupy the 0‑1 UV space cleanly (see Fundamental Review: UVs and Basic Materials). Overlapping islands or severe stretch will cause uneven normal detail. If you notice compression in high‑detail areas, use Smart UV Project or Angle‑Based Unwrap to redistribute texel density, ensuring the texel‑to‑world‑unit ratio stays roughly constant across the surface you’ll paint. 2. Create a Low‑Poly “Detail” UV Channel Add a secondary UV channel (often called UV2) dedicated to detail maps. This isolates the high‑frequency normal from the base color UVs, allowing you to keep the base UVs clean for tiled textures. Keep the secondary UVs non‑mirrored and uniformly spaced; mirroring can flip normal directions unexpectedly. 3. Set Up a Blank Normal Canvas Export a flat normal map (RGB = 128, 128, 255) using the secondary UV layout. This serves as the canvas on which you’ll paint. In your painting software, set the color space to Linear and the output bit depth to 16‑bit (or 32‑bit Float) to preserve subtle normal variations. --- Toolchain & Tablet Configuration A responsive tablet and correctly tuned brush settings are the backbone …

6. High-Poly Baking and Advanced Normal Mapping

Why Bake? – A Real‑World Prompt Imagine you’re tasked with creating a sci‑fi weapon that will appear up close in a first‑person shooter and far away in a large‑scale cinematic cut‑scene. The high‑poly artist has sculpted a dense mesh packed with panel ribs, engraved logos, and micro‑scratches. Rendering that mesh in real‑time would crush the frame budget, but the silhouette and silhouette‑level silhouette detail must stay true across all distances. The solution? Bake the high‑poly surface detail into normal maps for a low‑poly proxy and layer additional normal maps to inject wear, grit, or procedural variation. This chapter walks you through that exact pipeline, from setting up a clean bake to polishing the final look and squeezing performance out of compressed normal textures. 1. Setting Up a High‑Poly → Low‑Poly Bake 1.1 Preparing the Meshes 1. Finalize the low‑poly mesh Apply all modifiers (except the ones you intend to keep as separate detail layers). Ensure the mesh has a clean, non‑overlapping UV layout—refer to the UV layout checklist from the Fundamental Review chapter. Verify that the low‑poly UVs occupy the full 0‑1 UV space with minimal stretch; any distortion will be amplified in the baked normal map. 2. Prepare the high‑poly source Keep the high‑poly mesh sealed: no open edges, no internal faces that could leak rays. If the high‑poly contains multiple objects (e.g., separate armor pieces), join them before baking or use a cage that encloses the entire low‑poly surface. 3. Create a cage (optional but recommended) Generate a slightly inflated copy of the low‑poly mesh (scale by ~1‑2 %). Apply a solidify modifier or use a shrinkwrap to push the cage outward. The cage prevents ray‑casting from “seeing through” thin geometry and reduces bleed‑through artifacts. 1.2 Baking Settings Overview | Parameter | Typical Value | Why it matters | |-----------|---------------|----------------| | Ray Distance / Max Ray Length | 0.05 – 0.15 m (scene dependent) | Controls how far a ray can travel to find the high‑poly surface. Too short → missing detail; too long → capture of unintended geometry. | | Anti‑Aliasing Samples | 8 – 32 | Higher samples reduce noise in the normal map, especially for sharp creases. | | Margin / Padding | 2 – 4 px (in texture space) | Prevents seams from leaking when mip‑mapping. | | Output Format | 16‑bit EXR → 8‑bit PNG/TGA | 16‑bit preserves subtle slope data; convert to 8‑bit for engine consumption. | Tip: If you’re using Blender’s Bake panel, enable Clear Image before each bake to avoid ghosting from previous attempts. 1.3 Common Artifact Checklist | Artifact | Typical Cause | Quick Fix | |----------|---------------|-----------| | Black or Purple spots | High‑poly geometry missing behind the low‑poly …

7. Node-Based Shader Construction (Unreal/Unity/Blender)

A Real‑World Problem: The Rusty Crate Imagine you are populating a post‑apocalyptic level with a handful of wooden crates that have been left out in the rain for years. The artist has supplied three texture sets: | Set | Content | |-----|---------| | Base | Diffuse (albedo) and normal map of clean wood | | Wear | Grunge mask (black‑white) and a subtle rust detail texture | | Detail | High‑frequency wood grain (detail albedo & normal) | Your goal is to turn these assets into a single material that: Shows clean wood where the crate is untouched. Blends in rust only on the metal hinges and where the grunge mask indicates wear. Adds a repeating wood‑grain detail that respects the underlying surface curvature. All of this must be achieved without writing a single line of shader code, using only node graphs in Unreal Engine, Unity’s Shader Graph, and Blender’s Shader Editor. The following sections walk you through the process, highlight reusable patterns, and demonstrate conditional blending with logical nodes. --- 1. Node‑Graph Foundations 1.1 Data Flow, Types, and Naming Conventions Data flow in a node graph is unidirectional: outputs feed inputs. Keep the direction consistent (left‑to‑right or top‑to‑bottom) to make the graph readable. Node categories you’ll use most often: Texture Samplers – fetch image data (already covered in Fundamental Review). Math & Logic – arithmetic, comparisons, conditional selection. Material Output – the final PBR channels (Base Color, Metallic, Roughness, Normal, Ambient Occlusion, Emissive). Adopt a naming scheme that mirrors the texture set names (e.g., BaseAlbedoTex, WearGrungeMask, DetailGrainNormal). Consistent names reduce the cognitive load when you revisit the graph later. 1.2 Best‑Practice Checklist | ✔️ | Recommendation | |---|----------------| | Group related nodes | Use material functions (Unreal), sub‑graphs (Unity), or node groups (Blender) to keep the main graph tidy. | | Expose only what needs tweaking | Promote masks, tiling, and blend factors to parameters; hide internal math. | | Document with comments | Most editors allow comment nodes – write short notes like “Blend rust onto metal only”. | | Maintain a 0‑1 range | All masks and blend factors should be clamped between 0 and 1; this keeps the PBR values physically plausible (see PBR Deep Dive). | --- 2. Core PBR Nodes in All Three Engines Regardless of the engine, the fundamental PBR channels are supplied by the same set of nodes. Below is a quick reference that assumes you have already laid out UVs correctly (see Advanced UV Techniques). | Channel | Typical Nodes | |---------|----------------| | Base Color | Texture Sample → Linear‑to‑sRGB (if needed) → Base Color input | | Metallic | Texture Sample (R channel) → Multiply (if you want a scalar) …

8. Real-Time Optimization: Atlasing, LODs, and Mipmaps

When One Hundred Trees Turn Into One Draw Call Imagine a mobile game that streams a dense forest: 10 000 billboarded trees, each with its own diffuse, normal, and specular texture. On paper the visual quality looks great, but the frame‑time spikes the moment the camera sweeps past a cluster. The culprit? Every tree triggers a separate draw call and the GPU must sample many distinct texels at varying mip levels, causing texture cache thrashing. A simple rearrangement—packing all tree textures into a single texture atlas, swapping high‑resolution textures for lower‑detail variants as distance increases, and letting the hardware generate optimal mipmaps—can collapse those 10 000 calls into a handful, shaving milliseconds off each frame. This chapter walks you through the three pillars of that transformation: atlasing, level‑of‑detail (LOD) material design, and mipmap/anistropic configuration. --- 1. Texture Atlasing: From Many Textures to One 1.1 Why Atlases Matter for Real‑Time Rendering Draw‑call reduction – Modern GPUs are efficient at processing large batches of triangles that share the same material. Every unique texture forces a state change; an atlas eliminates most of those changes. Cache coherence – When adjacent texels reside in the same memory page, the texture cache sees fewer misses, especially important on mobile GPUs with limited cache size. Batching with instancing – Instanced meshes (e.g., foliage, crowds) can reuse a single material, and atlases let each instance address a different region of the same texture. 1.2 Building a Robust Atlas 1. Collect source textures – Gather all diffuse, normal, roughness, and metallic maps that will be used by a given draw group (e.g., all foliage). 2. Normalize UVs – As covered in Fundamental Review: UVs and Basic Materials, all UVs must be normalized to 0‑1 space. When packing, each texture occupies a sub‑rectangle of the atlas; its UVs are scaled accordingly. 3. Choose packing algorithm – MaxRect and Shelf are popular for their speed. Rotations (90°) can increase packing efficiency but require UV rotation in the shader. 4. Add padding – Insert a 2‑pixel (or more, depending on mip level) gutter around each tile to prevent bleeding when mipmaps are sampled. 5. Create a UV remap table – Store the UV offset and scale per tile (often in a Shader Storage Buffer or as a material parameter). This table drives the shader’s UV transformation. 1.3 Dealing with Sampling Artifacts Mip‑bleed – When a lower mip level samples texels from neighboring tiles, visible seams appear. Padding (step 4) mitigates this; you can also enable border color in the sampler to clamp to a neutral value. Anisotropic distortion – At steep viewing angles, the anisotropic filter spreads samples across multiple tiles. Keep tile edges aligned with the principal axes of the …

9. Custom Shader Programming Basics (HLSL/GLSL)

Why Custom Shaders Matter Imagine you’re iterating on a character’s costume in a game prototype. The artist has built a detailed texture atlas, but the engine’s stock “lambert” material makes the fabric look flat and lifeless. You need a quick way to highlight the seams, test how light wraps around the folds, and experiment with a stylized color ramp—without waiting for the full PBR pipeline to be rebuilt. A tiny custom shader that draws a live gradient over the mesh gives you immediate visual feedback and lets you validate UV layout, normal direction, and lighting interaction in minutes. This chapter shows you how to go from that “quick‑look” shader to a real‑world lighting model that can be dropped into the engine’s material system, giving you the flexibility to prototype, debug, and eventually ship custom shading effects. --- Getting Started: Toolchain & Shader File Basics HLSL vs. GLSL – A Quick Reference | Aspect | HLSL (DirectX) | GLSL (OpenGL/Vulkan) | |--------|----------------|----------------------| | File extension | .hlsl, .fx | .glsl, .vert/.frag | | Entry point qualifier | VSMain, PSMain (or void main) with technique blocks | void main() in separate vertex/fragment files | | Constant buffers | cbuffer blocks | uniform blocks | | Semantics | : POSITION, : TEXCOORD0 | layout(location = X) | | Matrix ordering | Row‑major by default (can be changed) | Column‑major (GLSL spec) | Both languages share the same core concepts—attributes, varyings, uniforms, and the graphics pipeline stages—so the code examples below will be shown side‑by‑side to illustrate the mapping. Project Setup 1. Create a shader folder in your engine’s source tree, e.g., Shaders/Custom/. 2. Add two source files: Gradient.vert / Gradient.frag (GLSL) or Gradient.hlsl (HLSL with vertex and pixel functions). 3. Configure the build pipeline: For a DirectX‑based engine, ensure the HLSL compiler (dxc or fxc) runs on the .hlsl file and outputs a compiled shader object (.cso). For an OpenGL/Vulkan engine, compile GLSL to SPIR‑V (glslangValidator) or let the driver compile at runtime. 4. Expose the shader to the material editor by adding a new material type (e.g., CustomGradientMaterial) that references the compiled shader and declares the required uniform parameters. Tip: Most engines already ship a “Shader Manager” that watches a directory for changes and hot‑reloads shaders. Enable that feature while you experiment—the engine will re‑compile the file the moment you save it. --- Vertex Shader – From Object Space to Clip Space Input Layout The vertex shader receives per‑vertex data that you defined in the mesh asset. For a gradient test we need only position and UV: Remember: Earlier chapters on UV layout emphasized that UVs live in a normalized 0‑1 range. The vertex shader will simply forward that range to the …

10. Advanced Shading Effects: Anisotropy, SSS, and Clear Coat

Anisotropic Reflection: Fabric, Hair, and Metallic Finishes Why Anisotropy Matters A quick glance at a satin dress or a glossy hair strand reveals a shimmering streak that moves with the light source. Traditional isotropic BRDFs (the Lambertian and GGX models covered in the PBR Deep Dive) assume surface roughness is uniform in every direction, which fails to capture that characteristic “brushed” look. Anisotropic reflection adds a directional bias to the micro‑facet distribution, letting you reproduce: Silk and satin fabrics – long‑run fibers create a stretched highlight. Hair – each strand behaves like a tiny cylinder, scattering light more along its length. Brushed metals – machining marks orient the micro‑facets, producing a directional sheen. When the lighting changes, the highlight slides, providing a cue that the material is not flat plastic. This visual cue dramatically raises realism for characters, costumes, and props. Core Theory Recap (Brief) The anisotropic GGX distribution replaces the single roughness value α with two orthogonal roughness parameters, αₓ and αᵧ, aligned to a tangent and bitangent vector defined per‑pixel. The half‑vector h is evaluated against these axes, producing an elongated lobe that follows the fiber direction. Key point: The tangent space is already available from the normal map pipeline discussed in High‑Poly Baking and Advanced Normal Mapping; you only need to feed a tangent direction into the shader. Implementing Anisotropy in Node‑Based Shaders Unreal Engine (Material Editor) 1. Create a Tangent Vector Use the Vertex Normal WS node as the base. Add a Custom node to rotate the normal around the world up axis, exposing a Rotation scalar that artists can drive per‑material. 2. Define Anisotropy Parameters Anisotropy (0‑1) – controls the strength (0 = isotropic). Anisotropy Rotation – rotates the fiber direction. Roughness X / Roughness Y – split the standard roughness using a Lerp node driven by the anisotropy value. 3. Connect to the Anisotropic Specular Model Set the Material Domain to Surface and Blend Mode to Opaque. In the Material Attributes panel, enable Anisotropic and plug the computed vectors into the Anisotropic Direction input. Tip: Use a Texture Sample (e.g., a grayscale “fabric direction” map) to drive the anisotropy rotation per‑texel, giving you spatially varying fiber orientations—perfect for patterned textiles. Unity (Shader Graph) 1. Add a Tangent Space Node – Unity provides a Tangent node; combine it with Normal to build a TBN matrix. 2. Separate Roughness – Use two Float properties (RoughnessX, RoughnessY) and a Lerp node controlled by an Anisotropy slider. 3. Anisotropic Specular Block – Unity’s PBR Master node includes an Anisotropic slot. Feed the rotated tangent vector and the split roughness values. Blender (Shader Editor) – Cycles/Eevee 1. Vector Math – Use a Vector Rotate node to offset the Normal …

11. Texture Painting Workflow in Substance Painter & Mari

A Real‑World Challenge: From Concept Sketch to Game‑Ready Asset Imagine you’ve just received a high‑poly concept model of a sci‑fi plasma rifle from the art department. The model is already clean, its UVs are laid out in a series of UDIM tiles (see Advanced UV Techniques and UDIM Workflows), and the high‑poly sculpt is ready for baking. Your task is to turn this raw geometry into a fully textured asset that can be dropped into both a Unity‑based game prototype and a cinematic render in Maya. The workflow you’ll follow relies on the strengths of Substance Painter for rapid PBR‑oriented painting and Mari for high‑resolution projection work and film‑grade output. The following sections walk you step‑by‑step through that pipeline, covering project setup, texture‑set configuration, projection painting, smart masks & generators, and finally exporting two optimized atlases—one for real‑time use and one for a film pipeline. --- 1. Setting Up the Project 1.1. Preparing the Mesh 1. Validate the UV layout – Open the mesh in your DCC tool (Maya, Blender, etc.) and double‑check that the UDIM tiles are sequential, non‑overlapping, and free of stretch or compression beyond the tolerances discussed in Fundamental Review: UVs and Basic Materials. 2. Export a low‑poly version – If the high‑poly contains details that will be baked into normal maps, generate a low‑poly proxy (e.g., using a 2‑× decimation or a custom retopology). Export both meshes as OBJ or FBX; keep the naming convention clear (e.g., PlasmaRifleHigh.obj and PlasmaRifleLow.fbx). 1.2. Starting a New Substance Painter Project 1. Launch Substance Painter → File ► New. 2. Select the low‑poly mesh (PlasmaRifleLow.fbx). 3. Choose the appropriate template – For a PBR workflow, the Metallic/Roughness template is the default. This automatically sets up the base channels (Base Color, Metallic, Roughness, Normal, Height, etc.) that you explored in the PBR Deep Dive. 4. Enable “Use UDIMs” – Painter will detect the UDIM tiles from the mesh and create a matching number of texture sets. Each UDIM becomes its own texture set, allowing you to work on them independently while preserving the logical grouping of materials (e.g., metal barrel, polymer grip). 1.3. Configuring Texture Sets - Rename texture sets to meaningful identifiers (e.g., BarrelMetal, GripPoly). - Assign appropriate material IDs – If your mesh contains multiple material assignments (via vertex colors or a material ID map), map those IDs to the corresponding texture sets. This step ensures that any baked maps (normals, AO) line up correctly. - Set resolution – Real‑time pipelines typically use 2048 px per UDIM; film pipelines may demand 4096 px or higher. In Painter’s Project Settings ► Texture Set Settings you can override the default per‑set resolution, which will be respected during export. --- 2. Projection …

12. Look Development, Color Grading, and HDRI Integration

1. Setting the Scene – A Quick Case Study Imagine you’ve just finished a high‑poly sci‑fi hovercraft, baked its normal map, and built a PBR material in Substance Painter. The asset looks great in isolation, but when you drop it into a desert sunset shot the metal gleams wrong, the sky feels “off”, and the overall mood doesn’t match the concept art. The missing piece? A disciplined look‑development pipeline that ties HDR environment lighting, color grading, and tone‑mapping together. The following sections walk you through exactly that pipeline, building on the UV, PBR, and node‑shader foundations you’ve already mastered in earlier chapters. --- 2. HDRI Fundamentals for Look Development 2.1 Picking an HDRI that Serves the Narrative Dynamic range matters – A true HDRI captures luminance from deep shadows to bright sun‑flecks (often 10 EV). For a desert sunset, choose an HDRI with a warm color temperature and clear sun‑disk. Resolution vs performance – 4 K HDRIs are a sweet spot for real‑time previews; 8 K+ is reserved for final renders or baked lighting. Geographic relevance – Even subtle differences in sky turbidity or horizon line can cue the viewer’s subconscious. Use reference photography to validate the chosen map. Tip: Keep a HDRI library (e.g., HDRI Haven, Poly Haven) organized by climate, time of day, and exposure. Tag each file with metadata (EV, sun direction) so you can search quickly during look‑dev. 2.2 Mapping HDRIs in Different Engines | Engine | Node/Setup | Typical Controls | |--------|------------|------------------| | Unreal Engine | SkyLight → Cubemap + Directional Light (optional) | Intensity, rotation, source type (Static vs Movable) | | Unity (HDRP) | Volume → Sky → HDRI Sky | Exposure, rotation, multiplier | | Blender (Cycles/Eevee) | World → Background → Environment Texture | Strength, rotation, color space (sRGB vs Linear) | All three platforms expose the same core parameters: rotation, intensity, and exposure. Adjust them early—before you start grading—to ensure the HDRI’s lighting direction matches the asset’s silhouette. 2.3 Controlling Intensity & Rotation 1. Set rotation first – Align the sun direction with the key light you intend to use. A mis‑aligned HDRI will produce confusing specular highlights. 2. Normalize intensity – Most engines let you scale the HDRI’s contribution. A good rule of thumb: start at 1.0 (engine default) and dial down only if the scene feels “over‑lit”. 3. Use exposure sliders – When you need a brighter sky without altering the HDRI’s rotation, increase exposure. Remember that exposure is a logarithmic control; a jump of +1 EV doubles the brightness. 2.4 HDRI Baking vs Real‑time Baking (light‑probe generation, irradiance maps) is ideal for static environments or performance‑critical games. It captures the diffuse component of the HDRI, letting you …

13. Pipeline Integration, Asset Management, and Version Control

Naming Conventions: The Silent Contract in a Shared Pipeline Imagine this: you hand off a folder of 40 textures to the lighting artist, all named generically like wood001.png, wood002.png, and so on. Three weeks later, they email you frantically asking which texture set belongs to which asset—because the naming doesn’t tell them. Worse, someone overwrites your high-res albedo with a low-res placeholder, and Git doesn’t catch it because the file name is identical. Naming conventions aren’t just about tidiness; they’re the silent contract that keeps a team from collapsing under ambiguity. Why Naming Conventions Matter in a Team Environment - Clarity under pressure: During crunch time, no one has time to open every file to confirm what it does. - Automation reliability: Scripts rely on predictable names to route textures, generate LODs, or update materials. - Version control efficacy: Git, Perforce, or any VCS can only track changes, not intent. If two people name files differently, merge conflicts and silent overwrites become inevitable. - Cross-discipline handoffs: Texture artists, lighters, riggers, and technical artists all need to understand what a file is before they open it. Key point: File names are the first layer of documentation. If they’re unclear, the entire pipeline breaks down. Anatomy of a Robust Naming Convention A good naming convention balances specificity, consistency, and machine-readability. Avoid spaces, special characters, and case sensitivity issues. Instead, use underscores, hyphens, or camelCase. Here’s a proven structure for texture assets: Let’s break it down: | Segment | Purpose | Example | |--------|--------|--------| | AssetID | Unique identifier for the model/mesh | woodenchesta | | MapType | Core texture type (from PBR: albedo, metallic, roughness, normal, etc.) | albedo, metallic, normal, ao | | Variant | Optional: alternate set (dirt, clean, weathered) | dirty, clean | | Resolution | Dimensions in pixels (e.g., 1K, 2K, 4K) | 2K, 4K | | Revision | Version identifier (often with leading zero) | v003, v01 | So a full example might be: Note: Avoid using dates or timestamps in names—use version numbers instead, as they’re machine-readable and easier to compare. Special Cases: UDIMs and Atlases For UDIM workflows (covered in Advanced UV Techniques and UDIM Workflows), include the UDIM tile number in the name: For atlased textures, use a naming scheme that reflects the atlas sheet and tile: Key point: UDIM and atlas names should be parseable by scripts. Avoid sheet1tileA.png—use sheet01tile05.png so tools can sort numerically. Folder Structure: Where Naming Begins Naming conventions start with the directory tree. A well-structured folder hierarchy prevents "where did I save that file?" moments and enables automation. Here’s a production-grade structure: Key point: Group by asset, not by texture type. This matches how artists and tools think—"Find all …