元老的画卷:深入理解 Unity Built-in（内置）渲染管线框架
引子：小明的"画面"从哪来？
小明已经玩转了协程，也摸清了引擎主循环的脉络。可有一天，一个更"本源"的问题，突然攫住了他：
"我在场景里摆了个方块，给它上了个材质，点下运行——‘唰’,屏幕上就出现了一个有光影、有颜色、有质感的方块。
可是……这幅画面,到底是’谁’画出来的?引擎是怎么把我场景里那些抽象的’物体、灯光、材质、摄像机’,变成屏幕上一个个实实在在的、五彩斑斓的’像素’的?
这中间,一定有一套流水线、一套’作画的流程’。它到底长什么样?"
小明摸到的，正是游戏引擎最核心、也最神秘的领域——渲染管线（Render Pipeline）。而他默认使用的那套、Unity 陪伴了无数开发者十几年的"元老级"作画系统，就叫做Built-in Render Pipeline（内置渲染管线）。
今天，我们就来认识这位"元老画师"。我们要看清：它是如何把一个三维的场景，一步步"画"成你屏幕上那幅二维画面的；它的框架结构是怎样的；它有哪些独门绝技，又有哪些时代的局限。
准备好了吗？我们要走进 Unity 那间运转了十余年的"画室"了。
一、什么是"渲染管线"？——从"场景"到"画面"的流水线
在认识 Built-in 之前，我们得先明白"渲染管线"这四个字到底意味着什么。
想象一下你的游戏场景：里面有一堆 3D 模型（一串串顶点和三角面）、几盏灯光、若干材质、一台摄像机。这些，都是抽象的、三维的数据。
而你的屏幕，本质上只是一块由几百万个像素点组成的、二维的平面。
渲染管线，就是那条"神奇的流水线"——它负责把"三维的、抽象的场景数据",经过一道道加工工序,最终"翻译"成"二维的、屏幕上每个像素该显示什么颜色"。
这个过程，就像一位画师作画：
- 先确定"从哪个角度看"（摄像机）;
- 再把三维物体"投影"到二维画布上（顶点变换）;
- 然后逐个像素地计算"这里该是什么颜色"——要考虑材质、贴图、光照、阴影……（光栅化与着色）;
- 最后叠加各种效果（后处理），交出成品。
而 Built-in Render Pipeline，就是 Unity 内置的、开箱即用的这样一位"画师"。你什么都不用配置，新建一个 Unity 项目，它就默默地在背后为你作画了。这也是它名字"Built-in（内置）"的由来——它是与引擎深度捆绑、天生就在那里的"默认画师"。
二、Built-in 的作画流程：一帧画面是如何诞生的
让我们跟随一帧画面的诞生，看看这位元老画师，究竟是按怎样的流程挥毫的。
2.1 第一步：摄像机——决定"画什么、从哪看"
一切从**摄像机（Camera）**开始。摄像机是这幅画的"眼睛"，它决定了：
- 视角与位置：从哪个角度、哪个位置看世界;
- 视锥体（Frustum）：一个像"金字塔"形状的可视范围，只有落在这个范围内的物体，才会被画出来;
- 裁剪（Culling）：引擎会先做一步"剔除"——把视锥体之外的物体、被完全遮挡的物体统统扔掉，“看不见的，就不画”，这是渲染的第一道省力工序。
在 Built-in 里，如果你有多个摄像机，它们会按depth（深度）值的顺序，一台一台地渲染，层层叠加。
2.2 第二步：排序与批处理——决定"先画谁、后画谁"
被摄像机"选中"要画的物体，不是杂乱无章地画的。引擎会给它们排序：
- 不透明物体（Opaque）：通常从前往后画（近的先画），这样后面被挡住的部分可以借助"深度测试"跳过，省力;
- 半透明物体（Transparent）：必须从后往前画（远的先画），因为半透明需要正确的颜色混合，顺序错了就会出错。
同时，引擎会尝试批处理（Batching）——把材质相同的一批物体"合并"成一次绘制，减少与 GPU 打交道的次数（这就是所谓的减少 Draw Call），从而提速。
2.3 第三步：核心秘密——Built-in 的"渲染路径（Rendering Path）"
这是 Built-in 框架里最核心、最需要理解的概念——它究竟"如何处理光照"，取决于你选择的"渲染路径"。
Built-in 主要提供两条截然不同的作画路线：前向渲染（Forward Rendering）和延迟渲染（Deferred Rendering）。这是理解 Built-in 的重中之重，我们必须讲透。
三、两条作画路线：前向渲染 vs 延迟渲染
3.1 前向渲染（Forward）——“边画物体，边算光”
前向渲染是 Built-in 默认、也最常用的路线。它的逻辑非常直观：
对每一个要画的物体，在画它的时候，就"当场"把打在它身上的所有光照，一盏一盏地计算进去。
比如画一个方块，场景里有3盏灯，前向渲染就会在处理这个方块时，逐一计算这3盏灯对它的影响，累加起来，得出最终颜色。
它的特点：
- 优点：简单、直接；对半透明物体支持良好；对硬件要求低，兼容性极好，尤其适合移动端；支持**多重采样抗锯齿（MSAA）**这种高质量抗锯齿。
- 缺点：光照数量一多，性能就急剧下降！因为它的开销大致是"物体数量 × 光照数量"。10个物体、10盏灯，就要算 100 次光照。灯越多，越吃不消。
前向渲染的比喻——“逐个上门的画师”:
前向渲染像一位一丝不苟的画师,他画每一个物体时,都要跑遍全城,把每一盏灯都"请"到物体面前,问一遍:"你照到它了吗?照了多少?"物体少、灯少时,他游刃有余。可一旦物体和灯都成百上千,他就要跑断腿了——"物体 × 灯光"的组合爆炸,让他不堪重负。
为了缓解灯多的问题，Built-in 的前向渲染做了一个很实际的妥协：它会挑出对物体影响最大的几盏灯做"逐像素"的精细计算，其余的灯，则用"逐顶点"或"球谐光照（SH）"这种更粗糙、更廉价的方式近似处理。这是一种"抓大放小"的智慧，但也意味着画面精度上的取舍。
3.2 延迟渲染（Deferred）——“先画好物体信息，最后统一算光”
延迟渲染，则是一套完全不同的、更"工业化"的思路：
先不急着算光！第一遍，把所有物体的"基础信息"（颜色、法线、深度、金属度等）画到几张special的"信息图"上（这几张图合称 G-Buffer）；等所有物体的信息都画好了，第二遍，再拿着这些信息图，"统一地、一次性地"计算所有光照。
它的特点：
- 优点：光照的开销与物体数量解耦了！开销大致是"屏幕像素数 × 光照数量"，与场景里有多少物体无关。所以它能轻松支持"大量光源"——这是它最大的杀手锏。
- 缺点：不擅长处理半透明物体（因为半透明无法简单地写入 G-Buffer，得单独用前向补画）；占用较大显存带宽（要存好几张全屏信息图）；对旧硬件、移动端不友好；不支持 MSAA（抗锯齿得用别的办法）。
延迟渲染的比喻——“流水线工厂”:
延迟渲染像一座现代化工厂。它不逐个物体地折腾光照,而是先开动第一条流水线,把所有产品的"基础规格"(颜色、朝向、深度)统一记录到几张"规格表"(G-Buffer)上。等规格表填满了,再开动第二条流水线,拿着规格表,"批量地、集中地"给所有产品统一打光。无论产品有多少,打光只在"最终的屏幕"上进行一次——灯再多,也不怕了!
3.3 如何选择？
- 移动端、对性能敏感、光源不多→前向渲染（这也是绝大多数移动游戏的选择）;
- PC/主机、场景里有大量动态光源→延迟渲染可能更划算。
理解这两条路线的取舍，是掌握 Built-in 框架的关键。它体现了渲染世界永恒的主题——没有免费的午餐，一切都是权衡（Trade-off）。
四、Built-in 的"后处理"与整体框架图
物体和光照都画好后，还没结束。往往还要加一道后处理（Post-processing）——在这幅"半成品"画面上，再叠加各种全屏特效：
- Bloom（泛光）：让亮的地方"发光"，营造氛围;
- 色调映射与调色（Color Grading）：调整整体色彩风格;
- 景深（Depth of Field）：模拟相机的虚化效果;
- 运动模糊、抗锯齿、暗角……
在 Built-in 里，后处理主要通过Post-Processing Stack（后处理栈）这个独立的包来实现。
现在，我们可以画出 Built-in 渲染管线的整体框架图了：
┌──────────────────────────────────────────────────────┐ │ Built-in 渲染管线一帧流程 │ ├──────────────────────────────────────────────────────┤ │ │ │ ① 摄像机剔除（Culling） │ │ └ 剔除视锥外、被遮挡的物体（看不见的不画） │ │ ↓ │ │ ② 排序（Sorting） │ │ └ 不透明：前→后；半透明：后→前 │ │ ↓ │ │ ③ 渲染物体 + 光照【核心！选一条路线】 │ │ ├ 前向渲染：边画物体边算光（灯少时高效） │ │ └ 延迟渲染：先填G-Buffer，再统一算光（灯多时高效） │ │ ↓ │ │ ④ 天空盒、半透明物体补画 │ │ ↓ │ │ ⑤ 后处理（Post-Processing） │ │ └ Bloom、调色、景深、抗锯齿…… │ │ ↓ │ │ ⑥ 输出到屏幕（呈现最终画面） │ │ │ └──────────────────────────────────────────────────────┘这，就是那位"元老画师"从接到场景、到交出画面，完整的作画流程。
五、Built-in 的"性格"：一位功勋卓著、却渐显疲态的元老
理解了流程，我们再来给 Built-in 这位元老，画一幅"性格肖像"——它的优点、局限，以及它在今天所处的历史位置。
5.1 它的功勋：开箱即用、兼容性王者
Built-in 之所以能陪伴 Unity 十余年、成为无数游戏的基石，靠的是两大过硬的本事：
- 开箱即用，零配置：新建项目它就在，你什么都不用设置，摆个物体就能出画面。对新手极其友好。
- 兼容性无敌：它支持极其广泛的平台和硬件，从最新的高端显卡，到多年前的老旧移动设备，它几乎都能跑起来。这份"普适性"，是它最宝贵的遗产。
5.2 它的"心病"：一个"黑盒子"，难以定制
然而，随着时代发展，Built-in 一个根本性的"心病"日益凸显——它是一个高度封装的"黑盒子"。
它的整个渲染流程，是引擎在底层写死的。你作为开发者，只能在有限的几个"开关"和"参数"上做调整，却无法真正地介入、修改、定制那条渲染流水线本身。
想在渲染流程的某个特定环节，插入一个你自己的特殊效果？想为你的特殊美术风格，深度改造光照模型？想针对你游戏的特点，极致地优化某个渲染步骤？——在 Built-in 里，这些都极其困难，甚至不可能。因为你打不开那个黑盒子。
比喻:Built-in 像一台"傻瓜全自动相机"——开机就能拍,谁都会用,兼容各种场景。但摄影师想手动调整光圈、快门、感光度,去创作独特的作品时,却发现这些旋钮被焊死了。它给了你便利,却拿走了你"深度掌控"的自由。
5.3 时代的接力：SRP 的诞生
正是为了解决这个"黑盒子"的心病，Unity 后来推出了革命性的SRP（Scriptable Render Pipeline，可编程渲染管线）,并基于它衍生出两条新管线：
- URP（Universal Render Pipeline，通用渲染管线）：定位为 Built-in 的现代化替代者，兼顾性能与画质，适用面广，尤其适合移动端和中端平台;
- HDRP（High Definition Render Pipeline，高清渲染管线）：追求极致画质，面向高端 PC 与主机。
SRP 的核心革命在于：它把那个"黑盒子"打开了！它用 C# 代码，把渲染流程"暴露"给开发者，让你能够自己编写、定制、掌控整条渲染管线。这，正是 Built-in 所缺失的、这个时代最需要的"自由"。
所以，Built-in 如今的历史位置是：一位功勋卓著、依然坚守岗位（老项目、追求极致兼容性的项目仍在用它），但已渐显疲态、正在被 URP/HDRP 逐步接棒的"元老"。理解它，不仅是理解一套技术，更是理解 Unity 渲染技术演进的起点——你只有懂了 Built-in 的"封闭"之痛，才能真正体会 SRP"开放"之可贵。
六、给学习者的建议：该不该学 Built-in？
小明可能会问：“既然 Built-in 正在被取代，我还有必要学它吗？”
答案是：非常有必要，但要摆正心态。
- 它是理解渲染的最佳"启蒙教材"：前向/延迟渲染、剔除、排序、批处理、后处理——这些核心概念是所有管线共通的。在结构相对简单直接的 Built-in 上学懂它们，再迁移到 URP/HDRP，事半功倍。
- 海量的老项目、教程、资源仍基于它：你会大量遇到它，绕不开。
- 对极致兼容性的需求依然存在：某些面向超广泛低端设备的项目，Built-in 仍是务实之选。
但同时要清醒：如果你是开新项目、要面向未来，URP 往往是更值得优先考虑的现代选择。学 Built-in，重在"理解原理、打好地基"，而非"押注未来"。
尾声：每一位"元老"，都曾是照亮时代的光
我们认识了 Built-in 这位 Unity 渲染世界的"元老画师"——看清了它从摄像机剔除、到排序批处理、到前向/延迟渲染、再到后处理的完整作画流程；也读懂了它"开箱即用、兼容无敌"的功勋，与"黑盒封闭、难以定制"的心病，以及它正被 SRP 时代温柔接棒的命运。
而当我们凝视这位渐显疲态的元老，心中涌起的，不该是"它过时了"的轻慢，而应是一份深切的敬意与思考。
你要知道——Built-in 那个如今被诟病的"黑盒子",在它诞生的那个年代,恰恰是它最大的优点!在那个开发者更需要"开箱即用、不必操心底层"的时代，它的"封闭"，正是它的"贴心"；它的"不可定制"，正是它的"简单可靠"。它用一套写死的、稳定的流程，为一代开发者屏蔽了渲染的复杂，让无数人得以轻松地做出自己的游戏。它，是照亮过一整个时代的光。
只是，时代变了。当开发者的需求，从"能出画面就好"进化到"我要极致的、独特的、可定制的画面"时，它那份曾经的"贴心封闭"，才变成了今天的"束缚"。于是，它功成身退，把舞台交给了更开放的 SRP。
这,何尝不是世间一切"新旧交替"的缩影?
我们身边，无论是一项技术、一套制度、一种方法，还是一位曾经引领潮流的前辈——当我们评判一个"正在被取代的旧事物"时，最浅薄的姿态，是嘲笑它的"落后"；而最成熟的智慧，是理解它曾经的"伟大"。
因为，几乎每一个今天看来"过时、封闭、局限"的旧事物，在它诞生的那个特定时代、面对那个时代特定的问题时，往往都曾是最优雅、最先进、最闪耀的答案。它的局限，不是它的"错"，而是时代前进后，才显现出来的"边界"。
懂得这一点的人，看待世界会多一份温柔与深刻：他不会因为一个事物"旧了"就全盘否定它，而会去汲取它沉淀下来的、跨越时代的智慧内核（就像前向/延迟渲染这些永恒的概念）；他也不会因为一个事物"新了"就盲目崇拜，而会看清，任何"新"，都是站在"旧"的肩膀上、为了解决"旧"的局限而生的。
新旧之间，从不是"对错"，而是"接力"。
所以，当你下次在 Unity 里，看到 Built-in 那个古老而稳定的选项时——愿你不仅看到一套即将退场的技术，更能看到那份"曾经照亮时代、如今从容交棒"的、属于所有"元老"的荣光与豁达。
理解旧事物的伟大，你才能真正读懂新事物的可贵；懂得为过去的光鼓掌，你才能更从容地，走向未来的光。
这，或许就是这位沉默的"元老画师"，在它渐渐落幕的身影里，为我们画下的、最后也最深刻的一幅画。