Unity Rendering Pipelines

Pipeline choice, shader authoring, and lighting setup change materially between Unity versions. Prefer the local docs over pre-trained knowledge for pipeline APIs, node names, and Volume override lists. Hand-written HLSL/ShaderLab authoring is covered by the sibling skill unity-shaders-hlsl — this skill covers pipeline choice, Shader Graph, materials, lighting, and Volumes only.

Retrieval Sources

Docs root: /media/artiq/FRESH_DRIVE/Books/Unity6/Documentation/en/Manual/ (all paths below are relative to this root unless marked ScriptReference). Every path in this table was verified with ls/find against the local Unity 6.3 LTS docs before being cited here.

ScriptReference note (verified): the core Rendering.Volume / Rendering.VolumeProfile / Rendering.VolumeComponent scripting API is shipped inside the URP/HDRP packages, not the base ScriptReference/ tree in this doc set — a search for VolumeProfile and Rendering.Volume in ScriptReference/ returned no hits. RenderPipelineAsset, GraphicsSettings.currentRenderPipeline, ReflectionProbe, and LightProbes/LightmapSettings are present in ScriptReference/ (e.g. Rendering.RenderPipelineAsset-defaultMaterial.html, Rendering.GraphicsSettings-currentRenderPipeline.html, ReflectionProbe.html, LightmapSettings.html). When writing Volume-manipulation C# code, cross-check method signatures against the installed URP/HDRP package's API docs (Window > Package Manager > in-package documentation) rather than assuming they live in this Manual/ScriptReference set.

Key Guidelines

Choosing a Pipeline

Pipeline choice is a project-founding decision, not a setting to revisit casually — choose-a-render-pipeline.html and render-pipelines-feature-comparison.html are the two pages to read before starting any new project. Built-in Render Pipeline is legacy and receives maintenance fixes only; only pick it for an already-existing Built-in project or a very small scope where migration cost isn't worth it. URP (universal-render-pipeline.html) is a single Scriptable Render Pipeline that scales from mobile/VR up through mid-range/high-end desktop and console via one Renderer asset with swappable Renderer Features — it is the default choice for the overwhelming majority of new projects because of its platform reach. HDRP (high-definition-render-pipeline.html) targets high-end desktop/console exclusively, trading platform reach for physically based, high-fidelity rendering (volumetrics, path tracing, advanced material models). Check xr-render-pipeline-compatibility.html before committing to HDRP for any XR project — support is narrower than URP's. All three pipelines are mutually exclusive at the project-asset level: exactly one Render Pipeline Asset is active at a time (assigned in Graphics Settings, see srp-setting-render-pipeline-asset.html), and materials authored for one pipeline do not render correctly under another without running the material upgrader (Edit > Render Pipeline > Upgrade). Switching pipelines mid-project means re-authoring or upgrading every material and shader in the project — budget for this explicitly rather than treating it as a quick asset swap.

Shader Graph Authoring

Shader Graph (shader-graph.html, com.unity.shadergraph.html) is Unity's node-based shader editor and the default authoring path for both URP and HDRP — it produces a .shadergraph asset that compiles to the same underlying shader variants as hand-written HLSL but is editable visually, previews live, and is approachable for artists/technical artists without a shader-language background. A graph targets a specific pipeline (URP or HDRP) and a specific Master Stack type (Lit, Unlit, Decal, Sprite, etc. — the exact list depends on pipeline and package version, verify current node/target names in shader-graph.html rather than assuming they match older Unity versions since Shader Graph's target/stack model has changed release to release). Subgraphs let you package a reusable node network as its own asset and drop it into other graphs as a single node — use them aggressively once a node cluster (e.g. a triplanar UV function, a hash/noise utility) is reused across more than one shader, so an update in one place propagates everywhere. Shader Graph is not a superset of hand-written HLSL: custom lighting models outside the built-in Lit/Unlit stacks, precise register-level control, and some advanced compute-adjacent patterns still require a Custom Function node dropping into HLSL or a fully hand-written shader — that authoring path (writing the HLSL/ShaderLab itself) is covered by the sibling skill unity-shaders-hlsl, not here. preferences-shader-graph.html controls only editor node-coloring/display preferences, not shader behavior.

Materials

A material binds a shader (or Shader Graph asset) to a set of property values and is the unit that actually gets assigned to a Renderer. Because materials are pipeline-coupled through their shader, a material authored against the Built-in RP's Standard shader or a URP Lit shader will render as solid magenta/pink under a different active pipeline — this is Unity's visual signal for "shader not found/incompatible," not a lighting bug. The fix is Edit > Render Pipeline > [target pipeline] > Upgrade Project Materials, which remaps built-in shader references where an automatic mapping exists; materials using custom shaders need manual reassignment. When authoring materials for the SRP Batcher (see Performance below), keep per-material property overrides that vary at runtime to material-property-block usage patterns documented in SRPBatcher-Materials.html rather than mutating shared material instances per-object, since per-instance shared-material mutation defeats batching and leaks state across objects using the same material asset.

Lighting & GI

Unity's lighting modes trade runtime cost against flexibility, and the choice is made per-Light via the Mode property plus project-wide Mixed Lighting settings (lighting-mode.html, choose-a-lighting-setup.html): Baked indirect and direct lighting costs nothing at runtime but is fully static — moving a baked light or object at runtime does not update the bake. Realtime lighting updates every frame (direct always; indirect only if a realtime GI system such as Enlighten or Adaptive Probe Volumes with runtime updates is in use) at a continuous runtime cost. Mixed is the common default: indirect lighting is baked once (cheap, and gives static objects high-quality bounce light) while direct lighting stays dynamic (so shadows and direct illumination respond to moving lights/objects); Mixed further subdivides into Baked Indirect, Shadowmask, and Distance Shadowmask sub-modes, documented in lighting-mode.html and lighting-mode-runtime.html, which change how runtime shadows for baked-lit dynamic objects are resolved. Baking itself runs through the Lighting window (lighting-window.html, global-illumination-configure.html) using a Lightmapper (Progressive CPU or Progressive GPU) and writes lightmap textures plus, if Adaptive Probe Volumes or Light Probes are present, probe data. Baked lightmap quality depends on lightmap UVs (a second UV channel, UV2) that don't overlap and have reasonable texel margins — enable "Generate Lightmap UVs" on the mesh's Model Import Settings, or hand-author UV2 for hero assets; LightingGiUvs.html and LightingGiUvs-GeneratingLightmappingUVs.html cover the generation parameters (Hard Angle, Pack Margin, etc.) and are the first stop when a bake looks blotchy or seamed. Realtime GI via Enlighten (realtime-gi-using-enlighten.html) is a Built-in-RP-era system; URP's realtime-updating indirect lighting path is Adaptive Probe Volumes with runtime updates enabled, not Enlighten.

Reflection & Light Probes

Dynamic (non-lightmapped) objects need a separate mechanism to receive plausible ambient/reflected lighting, since they have no lightmap UVs. Light Probes (LightProbes.html, LightProbes-Reference.html) sample baked spherical-harmonics indirect lighting at fixed points in the scene and interpolate between the nearest probes per-object (or, with a Light Probe Proxy Volume, per-texel — LightProbeProxyVolume-landing.html — useful for large dynamic renderers like terrain vehicles where per-object interpolation looks wrong). URP's newer alternative is Adaptive Probe Volumes (APV) (urp/probevolumes-concept.html, urp/probevolumes.html): Unity auto-places probes based on scene geometry density instead of requiring manual Light Probe Group placement, samples per-pixel rather than per-GameObject (better consistency, fewer seams between adjacent objects), supports streaming for open-world scenes, and supports blending between multiple baked lighting states via Baking Sets (urp/probevolumes-usebakingsets.html) — trade-offs are documented in the feature-comparison table inside urp/probevolumes-concept.html (APV: no manual placement, yes streaming, yes multi-bake blending; Light Probe Groups: manual placement only, no streaming, no blending). Reflection Probes (class-ReflectionProbe.html, ReflectionProbes.html, RefProbeTypes.html) capture a cubemap of the surrounding environment for use as specular/reflection input on nearby objects; probe Type is Baked (static, cheapest), Realtime (updates at runtime, most expensive — avoid unless the reflected environment actually changes), or Custom (a manually assigned cubemap, cheapest but static and hand-authored). RefProbePerformance.html is the reference for realtime probe cost before enabling more than a handful in a scene, and URP has its own reflection-probe setup/troubleshooting pages under urp/lighting/reflection-probes.html and urp/lighting/reflection-probes-troubleshooting.html.

Post-Processing Volumes

Post-processing in URP/HDRP is entirely Volume-driven — there is no per-camera effect stack outside this system. The chain is: a Volume component (Global, or Local with a trigger Collider) → a Volume Profile asset assigned to it → one or more Override components added to that profile (Bloom, Tonemapping, Color Adjustments, Vignette, Depth of Field, etc. — the full list is in urp/VolumeOverrides.html / urp/volume-component-reference.html). No Volume in the scene, no Profile assigned, an override left disabled, or an override's blend weight left at 0 are the four ways an override silently does nothing (urp/volumes-troubleshooting.html); a Global Volume with weight 1 is the simplest working baseline. Local Volumes participate in a distance-weighted blend as the camera crosses their trigger Collider's bounds and Blend Distance — multiple overlapping Volumes with different Layer/priority let you build region-specific looks (e.g. an underwater color grade) that blend smoothly rather than popping. Setting this up from C# (urp/Volume-Profile.html, note the ScriptReference caveat above — these types ship in the URP package):

using UnityEngine;
using UnityEngine.Rendering;
using UnityEngine.Rendering.Universal;

public class RuntimeVolumeSetup : MonoBehaviour
{
    void Start()
    {
        var volume = gameObject.AddComponent<Volume>();
        volume.isGlobal = true;
        volume.weight = 1f;

        var profile = ScriptableObject.CreateInstance<VolumeProfile>();
        if (profile.TryAdd(out Bloom bloom))
        {
            bloom.intensity.overrideState = true;
            bloom.intensity.value = 0.6f;
        }
        if (profile.TryAdd(out Tonemapping tonemap))
        {
            tonemap.mode.overrideState = true;
            tonemap.mode.value = TonemappingMode.ACES;
        }
        volume.profile = profile;
    }
}

Every override parameter has its own overrideState bool that must be set true for the value to actually apply when blending — a common bug is setting .value without setting .overrideState, which leaves the parameter inert. The individually documented override pages (Bloom urp/post-processing-bloom.html, Tonemapping urp/post-processing-tonemapping.html, Color Adjustments/Curves/Lookup, Split Toning, White Balance, Channel Mixer, Shadows-Midtones-Highlights for grading; Vignette, Chromatic Aberration, Lens Distortion, Panini Projection, Film Grain for stylization; Depth of Field, Motion Blur for camera/lens simulation) each list their own parameter set and valid ranges — check the specific page rather than guessing values, since ranges and defaults differ per override. SSAO is the one common "post-processing-looking" effect that is not a Volume override — it's added as a Renderer Feature on the URP Renderer asset (urp/add-ssao-renderer-feature-to-renderer.html), because it needs access to renderer-internal depth/normal buffers before the Volume stack runs. post-processing-effect-availability-reference.html lists which overrides exist on which pipeline before assuming HDRP/URP feature parity.

Performance (SRP Batcher / GPU Resident Drawer)

The SRP Batcher (SRPBatcher.html) reduces per-object CPU overhead by caching per-material GPU state and issuing a lighter-weight draw-call setup for consecutive objects sharing SRP Batcher–compatible shaders, without requiring identical materials the way GPU instancing does. Enable it in the Render Pipeline Asset inspector (SRPBatcher-Enable.html) — in Unity 6 it's on by default for new URP/HDRP projects. Compatibility is per-shader: a shader must declare its per-material properties inside a single CBUFFER matching the SRP Batcher's expected layout (SRPBatcher-Materials.html); shaders that don't (including some custom/legacy shaders) silently fall back to the older batching path with no error, so verify actual batching via the Frame Debugger or the dedicated SRP Batcher profiling view (SRPBatcher-Profile.html) rather than assuming it's active. You can intentionally opt a GameObject out of SRP Batcher compatibility (SRPBatcher-Incompatible.html) — either by making the shader incompatible or the renderer incompatible — specifically when you want GPU instancing instead (via Graphics.RenderMeshInstanced or per-material "Enable GPU Instancing"), because GPU instancing and the SRP Batcher are alternative, not additive, batching strategies for the same draw calls; profile both before choosing. The GPU Resident Drawer (urp/gpu-resident-drawer.html) is a newer, more automatic layer on top of BatchRendererGroup that GPU-instances MeshRenderer GameObjects with no per-object opt-in required, but has hard requirements verified from the doc: it only works with the Forward+ rendering path, requires a compute-shader-capable Graphics API/platform (excludes OpenGL ES), and only accelerates GameObjects with a Mesh Renderer (others silently fall back to normal drawing). Enabling it costs build time (all BatchRendererGroup shader variants get compiled in) and, when both Forward+ and the GPU Resident Drawer are active, switches Probe Atlas Blending on by default. Enable steps per the doc: Project Settings > Graphics > Shader Stripping > set BatchRendererGroup Variants to Keep All; confirm SRP Batcher is enabled on the active URP asset; set GPU Resident Drawer to Instanced Drawing on the URP asset; set the Universal Renderer's Rendering Path to Forward+. Analyze results via the Frame Debugger (batched draws appear grouped under "Hybrid Batch Group"), the Rendering Debugger, Rendering Statistics (FPS / CPU time / SetPass call count), and the Profiler — it pays off most on large scenes with many GameObjects sharing meshes, and less in Scene/Game view than in an actual Play/build target.

Common Mistakes

Quick Reference

Advanced Notes

HDRP hardware/platform requirements. HDRP targets compute-shader-capable GPUs on high-end desktop and console only; it is not a viable target for mobile or most VR hardware — always check render-pipelines-feature-comparison.html and xr-render-pipeline-compatibility.html per-target before scoping an HDRP project. This local doc set carries only two HDRP-specific Manual pages (high-definition-render-pipeline.html, com.unity.render-pipelines.high-definition.html); deep HDRP topics (Diffusion Profiles, Path Tracing, Volumetric Fog/Clouds, Decal Projector specifics, Camera physical settings) are not present here in the depth URP enjoys in this archive — treat pretrained knowledge as a starting point for those topics but flag it as unverified against local docs, and prefer Unity's hosted HDRP manual for anything beyond pipeline-choice-level detail.

Custom render passes / Renderer Features. Beyond the built-in Renderer Features (Decal, SSAO, Screen Space Shadows), URP supports fully custom render passes via ScriptableRendererFeature + ScriptableRenderPass, documented starting at urp/renderer-features/intro-to-scriptable-render-passes.html and walked through end-to-end in urp/renderer-features/custom-rendering-pass-workflow-in-urp.html. This is the mechanism for injecting custom full-screen or per-object passes into the URP frame (e.g. outline effects, custom depth/normal passes, a custom post-processing effect that needs to run at a specific injection point) without forking the Universal Renderer source. urp/post-processing/custom-post-processing-with-volume.html specifically covers wiring a custom Renderer Feature pass to react to Volume override parameters, which is the standard pattern for shipping a custom post-processing effect that fits into the existing Volume-blending workflow rather than bypassing it.

SRP Batcher vs GPU instancing vs GPU Resident Drawer — picking one. These three sit at different levels and aren't simply "pick the best one": the SRP Batcher reduces CPU per-object state-change cost for shader-compatible draws regardless of whether meshes/materials are identical; GPU instancing collapses many draws of the same mesh+material into one GPU-side call and is mutually exclusive with SRP Batcher per-draw; the GPU Resident Drawer is a higher-level automatic system built on BatchRendererGroup that effectively generalizes instancing-style batching across Forward+ scenes without manual per-object setup, at the cost of longer build times and a hard Forward+/compute-shader requirement. For a new Forward+ URP project on supported hardware, enabling both SRP Batcher and the GPU Resident Drawer together is the documented recommended baseline; GPU instancing remains the right manual tool specifically for large counts of one mesh+material where you're intentionally opting out of SRP Batcher compatibility.

Baking Sets and multi-scene APV. Adaptive Probe Volumes bake per Baking Set (urp/probevolumes-usebakingsets.html), which groups scenes that share a probe-lighting bake — this is the mechanism for supporting multiple lighting states (e.g. day/night) or multi-scene open-world streaming setups without re-baking probes per scene load. Sky Occlusion (urp/probevolumes-skyocclusion.html) additionally lets APV update sky-contributed indirect light at runtime without a full re-bake, which Light Probe Groups cannot do at all.