book/01-introduction.md

01. Big picture: Unity rendering pipeline and SRP

Based on Unity 6.3 (6000.3), we summarize the general flow and version sense of SRP/URP/RenderGraph.

01. Big picture: Unity rendering pipeline and SRP

This chapter organizes “How does rendering work in Unity?” from an architectural perspective. All terms in later chapters (Pass, Renderer, RenderGraph, RTHandle, Forward+) originate here.

1.1 Unity 6.3 (6000.3) and package version sense

In Unity 6, the editor version is displayed as 6000.x series. “Unity 6.3” usually refers to the 6000.3.* series of releases.

  • You can check for patch releases on the Unity 6000.3 release (e.g. 6000.3.6f1) archive page.
  • URP has a package version (e.g. URP 17.x) separate from the editor version, and the actual API/implementation depends on this package version.

This set of documents is based on “Unity 6 (6000.x) + URP 17.x series + RenderGraph-centric”. The URP package version may be different for each project, so if the API introduced in this text looks different, check package version first.

1.2 Built-in Render Pipeline vs SRP(URP/HDRP)

Key differences

  • Built-in (old pipeline): Unity internal fixed pipeline (expansion limited, CommandBuffer-based expansion)
  • SRP: Define the rendering loop/path configuration itself in C# (extension and replacement are structurally possible)

Reasons for studying SRP (graphics developer perspective)

  • “Where to draw what” can be controlled at the code level (path insertion, buffer management)
  • Structure can be tuned to suit platform/performance needs (mobile/console/PC)
  • Shader/lighting/post-processing pipelines can be configured project-customized

1.3 Big flow of URP rendering (summary)

In URP, a normal frame (based on the default renderer) goes like this.

  1. Camera-specific settings/culling preparation
  2. Draw in cue order, such as Opaque → Skybox → Transparent.
  3. Create and consume Depth/Normal/Color textures if necessary
  4. Post-processing (volume-based) and final output

“Where” this flow is extended is RendererFeature/Pass. (For detailed structure, refer to 03. URP 아키텍처)

1.4 Why is RenderGraph important?

RenderGraph declares “resource dependencies between passes” as a graph, allowing you to reliably manage resource lifetime/reuse and execution order.

  • Advantages: Reduce texture/buffer allocation, clearly declare pass dependencies (strong in debugging/optimization)
  • Practical point: URP actively uses the RenderGraph path, and the Compatibility Mode path becomes less and less advanced.

Creating a RenderGraph-based custom pass starts from 04. RenderGraph.

Further reading (official/authoritative sources)