引子小明的画面从哪来小明已经玩转了协程也摸清了引擎主循环的脉络。可有一天一个更本源的问题突然攫住了他我在场景里摆了个方块给它上了个材质点下运行——‘唰’,屏幕上就出现了一个有光影、有颜色、有质感的方块。可是……这幅画面,到底是’谁’画出来的?引擎是怎么把我场景里那些抽象的’物体、灯光、材质、摄像机’,变成屏幕上一个个实实在在的、五彩斑斓的’像素’的?这中间,一定有一套流水线、一套’作画的流程’。它到底长什么样?小明摸到的正是游戏引擎最核心、也最神秘的领域——渲染管线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 后来推出了革命性的SRPScriptable Render Pipeline可编程渲染管线,并基于它衍生出两条新管线URPUniversal Render Pipeline通用渲染管线定位为 Built-in 的现代化替代者兼顾性能与画质适用面广尤其适合移动端和中端平台;HDRPHigh 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 那个古老而稳定的选项时——愿你不仅看到一套即将退场的技术更能看到那份曾经照亮时代、如今从容交棒的、属于所有元老的荣光与豁达。理解旧事物的伟大你才能真正读懂新事物的可贵懂得为过去的光鼓掌你才能更从容地走向未来的光。这或许就是这位沉默的元老画师在它渐渐落幕的身影里为我们画下的、最后也最深刻的一幅画。
引子小明的画面从哪来小明已经玩转了协程也摸清了引擎主循环的脉络。可有一天一个更本源的问题突然攫住了他我在场景里摆了个方块给它上了个材质点下运行——‘唰’,屏幕上就出现了一个有光影、有颜色、有质感的方块。可是……这幅画面,到底是’谁’画出来的?引擎是怎么把我场景里那些抽象的’物体、灯光、材质、摄像机’,变成屏幕上一个个实实在在的、五彩斑斓的’像素’的?这中间,一定有一套流水线、一套’作画的流程’。它到底长什么样?小明摸到的正是游戏引擎最核心、也最神秘的领域——渲染管线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 后来推出了革命性的SRPScriptable Render Pipeline可编程渲染管线,并基于它衍生出两条新管线URPUniversal Render Pipeline通用渲染管线定位为 Built-in 的现代化替代者兼顾性能与画质适用面广尤其适合移动端和中端平台;HDRPHigh 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 那个古老而稳定的选项时——愿你不仅看到一套即将退场的技术更能看到那份曾经照亮时代、如今从容交棒的、属于所有元老的荣光与豁达。理解旧事物的伟大你才能真正读懂新事物的可贵懂得为过去的光鼓掌你才能更从容地走向未来的光。这或许就是这位沉默的元老画师在它渐渐落幕的身影里为我们画下的、最后也最深刻的一幅画。
)
双梁正问题 【 torch 实战】（Python代码实现）)
