很多人第一次接触这四个词都是在同一个场景里手上有个三维场景想把画面变成图或者变成视频然后发现面前摆着四条路——实时渲染、离线渲染、云渲染、混合渲染。大多数资料会告诉你实时快、离线好、云渲染省钱、混合渲染兼顾这四句话基本等于没说因为它解释不了一个最实际的问题我手上这个活到底该走哪条路走错要多花多少时间和钱。我带过几个项目从建筑可视化的漫游程序到几分钟的三维短片四种方式都实打实跑过一遍中间因为选错路线返工的次数不少。这篇就把这四者拆开讲透不讲概念定义讲它们是怎么被约束条件逼出来的——搞清楚每种方式背后被什么卡着脖子选型就不再是靠猜。不管你是在做游戏、做产品演示、做影视短片还是做工业仿真读完应该能自己判断该往哪条路上走。1. 这四个词说的不是同一个维度的事先把这个前提理顺1.1 一张图从提交到出图中间到底发生了什么先把链路走一遍后面所有的差异都藏在这条链路里。你搭好一个场景里面有几百万个三角面、几十盏灯、一堆带粗糙度贴图的材质。渲染器要干的事情只有一件算出每个像素最终是什么颜色。听起来简单实际计算量大得离谱因为一个像素的颜色取决于打到这个像素上所有光线的来源——直射光、经过墙面反射一次的光、反射两次的光、穿过玻璃折射之后再反射的光理论上要沿着无数条光路一直追下去。现实中不可能真追无穷条所以所有渲染器都在做同一件事用有限的采样去逼近那个理论上无限的计算。差别就在于你给它多少时间、允许多大的误差、这个误差是这一秒必须算完还是这一帧可以算八小时。实时渲染是被卡死了时间的极端情况离线渲染是把时间放开到极致的另一种极端云渲染是把有多少机器能同时算这个变量单独拎出来卖混合渲染则是在同一个项目里对不同部分用不同的策略。这四个词不构成一个并列的选择题它们是三个不同维度上的坐标时间维度、资源维度、分工维度。理解这一点很关键。很多人把云渲染当成离线渲染的替代品其实云渲染只是算力从哪来的问题它既可以跑离线渲染也可以跑实时渲染的预计算部分。混淆这两个维度方案设计从第一步就会歪。1.2 为什么实时和离线不能简单用快慢来区分最容易被误解的一点以为实时渲染就是快速的离线渲染。完全不是。这两者的算法栈是两套东西不是同一套东西调了调速度。实时渲染的核心约束是每帧必须在固定时间内出结果60 帧每秒意味着 16.67 毫秒120 帧意味着 8.33 毫秒而且这个时间是硬上限不是平均值。超了就是卡顿卡顿在交互场景里是致命的。因为有了这个硬上限实时渲染根本不敢用路径追踪那种采样越多越准的思路它必须把光照计算提前算好、缓存起来、或者用近似公式糊弄过去。于是就有了光照贴图、探针、屏幕空间反射这类技术——它们的共同特点是算得不准但算得快而且速度可预测。离线渲染反过来它没有单帧时间上限只有项目总工期。所以它可以放心大胆地做百万级采样、追踪十几次光线反弹、把焦散和次表面散射这些贵得要命但视觉上极其加分的效果全开。它的算法核心是收敛也就是随着采样数增加画面一点点逼近真实解。这带来一个完全不同于实时的思维方式离线渲染的优化不是让每帧更快而是用更少的采样达到可接受的噪点水平思路完全不同。对比维度实时渲染离线渲染时间约束单帧硬上限通常 8~33 毫秒单帧无上限受总工期约束核心算法思路预计算 近似 缓存蒙特卡洛采样 逐步收敛优化目标稳定帧时间、降低单帧开销降低噪点、减少总核时典型失败模式掉帧、卡顿、显存爆掉噪点降不下来、工期失控结果可预测性高同一场景每次跑结果一致中采样不足时噪点分布有随机性这张表里最值得盯的是最后一行。实时渲染的结果是确定性的同样的输入必然得到同样的画面这对需要反复调试、需要各端表现一致的场景特别重要。离线渲染在采样不足时会有随机噪点每次跑出来的噪点图案都不一样这在实际工作中会带来一个很烦的问题你看着预览觉得这片区域好像有点脏但重跑一遍噪点换了个位置你就很难判断到底是模型接缝的问题还是采样不够。这个坑后面还会细说。1.3 云渲染和混合渲染为什么是另一个维度的事云渲染改变的不是算法是算力的获取方式。你把同样一套离线渲染工程丢到本地机器上跑和丢到一堆远程机器上分帧跑出来的画面是一模一样的区别只在多久跑完和花多少钱。所以判断要不要上云本质是一道经济题而不是技术题判断依据是你的算力需求是不是波峰波谷差距极大。一个典型的工作室平时三五个人做前期机器闲得发慌到了交片前两周突然需要同时跑两千帧本地机器全部拉满也不够。如果为了这两周去买机器剩下十个月这些机器都在吃灰折旧和维护成本全砸在手里。云渲染解决的就是这个峰值问题——把固定成本变成可变成本。反过来说如果你是一个常年满载的团队机器天天跑满那自己买机器的单位成本一定比按小时租便宜这时候上云反而是亏的。这个临界点怎么算第 4 节会给出具体的算法。混合渲染则是分工维度的事。它承认一个现实一个项目里不是所有画面都值得用同一种方式做。比如一个产品展示应用用户要能自由旋转视角、实时看到材质变化这部分必须实时但用户点生成宣传图的时候需要一张 4K 精度的海报这时候完全可以后台跑一张离线渲染的结果。一个项目两种策略各取所长。混合渲染的难点从来不是能不能混而是边界画在哪——哪部分必须真算哪部分可以糊弄画错了要么性能崩要么画面出现明显的风格断层。2. 实时渲染16.7 毫秒的预算怎么被一条管线一点点吃掉2.1 把帧预算拆开才知道瓶颈在哪很多人做实时渲染优化第一步就错了看到帧率低第一反应是模型面数太多了然后疯狂减面减完发现帧率没变。因为瓶颈根本不在几何。一帧 16.67 毫秒的预算实际分配大致是这样的CPU 侧要处理逻辑更新、场景遍历、剔除、提交绘制指令这块通常占 3~6 毫秒GPU 侧要跑几何处理、光栅化、像素着色、后处理占 10~13 毫秒。这两部分是串行的虽然现代管线有多帧并行但单帧内的依赖关系还在所以哪一边先顶到上限整帧就被拖住。判断瓶颈在哪最靠谱的办法是看 GPU 时间戳和 CPU 每帧耗时的对比。如果 CPU 侧耗时明显高于 GPU通常是绘制调用次数太多导致的——每次绘制调用都有固定的驱动开销几百次还能扛上万次就会出现 CPU 被拖死、GPU 在一边闲着的情况。这时候该做的是合批把用同一材质的物件合并成一次绘制或者用实例化把几百个相同模型一次性提交。反过来如果 GPU 耗时高那才是像素着色或者几何量的问题该考虑降分辨率、简化着色器、开遮挡剔除。一个具体的经验数字中端 GPU 上单帧绘制调用控制在 2000 次以内比较安全超过 5000 次基本会开始出现 CPU 瓶颈。这个数字跟硬件和驱动都有关但量级上可以参考。延迟渲染这条路径还有另一个隐形杀手带宽。延迟渲染会先把法线、粗糙度、金属度、深度这些信息写进多张渲染目标也就是常说的 G-Buffer然后在第二个 pass 里读回来算光照。4K 分辨率下一张 RGBA16F 的渲染目标是 3840×2160×4 通道×2 字节约 66 MB。如果 G-Buffer 铺了 6 张单帧光写入就是 400 MB 左右60 帧就是 24 GB/s 的写入带宽加上读取还要翻倍。显存带宽是有限的这个数字一旦超过硬件的可持续带宽帧率就会莫名其妙地掉而你从面数和着色器复杂度上完全看不出问题。2.2 实时渲染里那些骗眼睛的技术以及它们的代价实时渲染能看很大程度上靠的是一整套看起来对但其实不对的技术。我列几个最常用的顺便说说它们的代价因为每一个省时间的技术都在别处埋了雷。烘焙光照贴图。把静态物体的间接光提前算好存成贴图运行时直接采样。这招极其有效一个复杂场景的全局光照计算能从每帧几十毫秒直接降到几乎为零。代价是场景里任何东西一动光照就错了。挪一把椅子椅子原来位置的阴影还留在地上。所以烘焙必须配合动态物体用实时阴影、静态物体用烘焙的混合策略接缝处理不好就会出现这个箱子怎么没有影子的问题。屏幕空间反射。用当前帧已经渲染好的画面去反推反射不用真的追踪光线。速度极快效果在大多数情况下够看。但它有个硬伤屏幕外的东西反射不出来。摄像机一转水面反射的内容就突然消失或者变形这在漫游类应用里特别扎眼。规避办法是让摄像机运动幅度别太大或者在反射最明显的地方比如地面配合一张预先生成的环境贴图兜底。基于时域信息的上采样与抗锯齿。这类技术用前一帧的信息补当前帧的不足原理是相邻帧之间画面变化很小。效果惊人能把 1080p 的渲染结果上采样到 4K看起来几乎没差。代价是快速运动的物体会拖影因为前一帧的信息在当前帧已经不准了。所以这类技术必须配合运动向量做重投影运动向量算错了比如蒙皮网格或者粒子系统就会出现鬼影表现为物体边缘一圈模糊的残影。细节层级切换。远处的模型用低模近处用高模。省钱效果显著。代价是切换瞬间的跳变如果 LOD 之间的过渡没做混合你会看到远处的树啪一下换了形状。这个在开阔场景里特别明显处理办法是做淡入淡出的过渡但过渡期要同时渲染两个 LOD反而更贵得权衡。这些技术的共同逻辑是用用户大概率注意不到换性能。所以做实时渲染一半功夫在写代码另一半功夫在理解人眼会注意到什么。这个判断力比任何优化技巧都值钱。2.3 实时渲染做不了什么拿一个对照实验看清楚说实时渲染做得不够真实太笼统了我用一个具体场景说明它到底卡在哪。设想一个场景室内一扇窗阳光进来地上有一块玻璃摆件。你要看到阳光穿过玻璃之后在地板上形成的那道彩色光斑也就是焦散。这个效果在物理上就是光线经折射后聚集需要追踪光路才能算出来。实时渲染做不到因为焦散是非局部的、路径依赖的效果无法用屏幕空间信息近似光斑在地板上折射发生在玻璃里两者在屏幕上可能根本不重叠。离线渲染算这个采样开到够几秒钟就出来了。实时渲染要么预先烘焙成一张贴图贴在特定位置那这个玻璃就不能动、地板也不能动要么干脆放弃。这个例子说明了一个判断标准凡是光线要从 A 点出发、经过 B 点、最后落到 C 点而 A、B、C 在屏幕上不同位置的效果实时渲染基本都要靠预计算或者近似。焦散是这样多次反弹的间接光是这样透过磨砂玻璃的柔和透光也是这样。搞清这个标准你就知道哪些效果在实时管线里必须提前规划哪些可以运行时算。3. 离线渲染时间换收敛采样数不是越大越好3.1 采样翻倍只降三成噪点这个曲线决定了所有优化策略路径追踪的原理是蒙特卡洛积分说人话就是往场景里随机撒一堆光线看它们最后打到什么取平均值当作真实结果。撒得越多平均值越接近真值。关键问题是——逼近速度有多快。数学上蒙特卡洛估计的误差和采样数的平方根成反比。也就是说采样数从 100 提到 4004 倍误差只降到原来的二分之一从 100 提到 10000100 倍误差才降到十分之一。换成更好懂的说法你花 100 倍的机时画面噪点只降 90%。这条曲线直接决定了离线渲染的优化思路——傻堆采样是性价比最低的做法。我见过太多人一看到噪点就把采样数从 128 加到 1024跑了一整夜第二天一看还是有点脏因为按 √n 的关系1024 相比 128 只是误差降到 35%。这时候该做的不是加采样而是找出噪点集中在哪。噪点的分布是不均匀的绝大部分集中在少数几个地方光源采样不足导致的高光噪点、小光源造成的硬阴影边缘、间接光反弹次数不够造成的暗部色块、光泽材质的反射模糊不够。针对性地调比如专门给那个小光源加采样、单独提高光泽反射的采样倍数往往能把 128 采样的画面做到 512 采样都达不到的干净程度机时省一半。这种局部调参的功夫是离线渲染里最值钱的经验工具不会告诉你得自己一帧一帧盯着噪点分布去找。3.2 降噪器的正确用法和三种我见过最多的误用降噪器的出现基本改变了离线渲染的成本结构它能在 1/8 的采样数下给出接近满采样的观感。但它不是万能的用错了比不用更糟。误用一把降噪当采样用。采样数低到一定程度画面里的信息量本身就不够了降噪器只能抹平抹出来的是糊的色块而不是细节。一个粗略的经验路径追踪的采样数不要低于 32低于这个数量级间接光的分布本身就没收敛降噪能糊出来的只是错误的颜色。降噪的合理定位是把 128 采样的画面拉到看起来像 512 采样不是把 8 采样拉到 256。误用二降噪后再做调色。降噪输出通常是经过时域或空域滤波的结果高频信息已经被抹掉一部分了。如果在前一层做完降噪后一层又做大幅度的对比度拉伸或色彩偏移被抹掉的区域会出现色带和斑块因为低采样区域的细微偏差被放大了。正确顺序是先做曝光和白平衡这类全局线性调整再做降噪最后做对比度和风格化。误用三不看 AOV 就降噪。专业降噪器支持分开处理不同通道——法线、深度、反照率、直接光、间接光。如果把这些通道混在一起一次性降噪几何边缘会被颜色差异带偏出现墙角被抹圆的效果。正确做法是提供干净的几何和法线辅助信息给降噪器让它在区分边缘的时候有依据。这一步做不做画面锐度差别肉眼可见。3.3 分层渲染和渲染农场本质都是让返工成本变低离线渲染一个大项目最怕的不是算得慢是改一个东西要全部重算。所以几乎所有成熟的制作流程都会做分层渲染把画面拆成背景、角色、特效、前景几层各自输出带透明通道的序列帧最后在合成软件里叠起来。这么做的理由很实在如果只是角色身上一件衣服的颜色要改你只需要重渲角色那一层背景那几百帧不用动。一个五分钟的短片两千多帧全片重渲可能要两天只重渲一层可能两小时。这个差距在临近交付、每天改十几版的情况下就是能不能按时交片的区别。分层还有一个隐性好处合成阶段的调整空间大得多。可以在不重渲的前提下调整某一层的亮度、色偏、景深强度、运动模糊量。有些效果放在合成里做比在三维里算便宜两个数量级。渲染农场则是把等待时间压缩。这里有个简单的换算值得记住总核时是不变的你能改的只是并行度。一个镜头如果单帧要 2 小时、共 100 帧总核时就是 200 核小时。8 核的本地机器跑25 小时64 个节点并行不到 4 小时。注意这里的单位是核时不是帧数——很多人算成本的时候只算多少帧忽略了每帧本身的耗时差异极大夜景加满屏体积雾的一帧可能是白天空镜的二十倍用帧数估算成本会差出十倍。4. 云渲染卖的不是算力是把峰值切碎了按分钟卖4.1 本地摊销和按需计费的临界点怎么算这道题其实不难只要把隐形成本算进去。本地一台能干活的渲染工作站采购价按配置差异很大加上三年折旧、电费、机房散热、运维人力摊到每小时的成本大概是设备价的某个比例。粗暴估一下一台三万的机器三年大概能用 15000 小时按每天 14 小时算不算电费和运维单纯折旧就是每小时 2 元左右加上电费和运维翻个倍每小时 4~5 元。云上的按小时实例同等算力的价格波动很大按时段和实例类型差异能从每小时几块到几十块。如果按 8 元每小时算单看单价云是贵的。但关键在于利用率本地机器如果一年只满载两个月剩下十个月利用率 20%那有效成本要除以 0.2实际每小时摊到 20 元以上。这时候云就划算了。所以判断公式很简单本地机器年均利用率低于 40%上云大概率更省高于 70%自己买更省。中间地带看你对弹性的需求有多强——能不能接受临时加急的时候没有机器可用。还有一类成本经常被忽略等待的代价。如果本地跑一版要 8 小时你一天只能迭代一次云上跑 1 小时你一天能迭代八次。多出来的七次迭代带来的质量提升很多时候比省下的那点钱值钱得多。这个账在创意类项目里尤其重要。4.2 分布式切帧的三种粒度各有各的坑把任务分到多台机器上切分方式有三种选错了会很痛苦。按帧切分是最常见的一帧一个任务谁先跑完谁领下一帧。简单、可靠、容错好一台机器挂了只丢一帧。坑在于负载不均——如果第 37 帧特别复杂比如那帧有个大爆炸特效它会变成最后完成的那一帧其他机器早就跑完了在等它。整个任务的时长被最慢的那一帧决定。解决办法是提前做耗时预估把预估耗时的帧先派出去让长的任务先跑。按 tile 切分是把单帧画面切成若干块每块一个任务。适合单帧耗时极长、帧数又少的场景比如一张 8K 的建筑效果图。坑在于边缘不一致——相邻 tile 在交界处的采样和降噪可能产生细微差异拼起来能看到一条缝。必须保证 tile 之间有足够的 overlap并且降噪在拼接后整体做一遍不能各做各的。按通道切分是把不同 AOV 分到不同机器。这个用得少因为各通道的耗时差异巨大且互相依赖调度复杂度高收益不明显。一个实践中的细节分布式渲染最大的时间损耗往往不在计算而在任务下发和结果回收。如果每帧的输出文件很大比如多层 EXR回收阶段会变成串行瓶颈。策略是让计算节点直接把结果写到共享存储本地只拉取一份低分辨率预览做检查确认没问题再拉全量。4.3 上传带宽才是真正的隐形瓶颈这条是我踩过最疼的坑。算过一笔账4K 分辨率、32 位浮点、RGBA 四通道的 EXR 单帧3840×2160×4×4 字节约 132 MB。假设一个 200 帧的镜头加起来 26 GB。如果工程文件、贴图、缓存再加进去整个上传量可能是 50 GB 起。上行带宽 100 Mbps 的话理论速度 12.5 MB/s50 GB 需要约 67 分钟——前提是跑满带宽且不中断。实际上家用宽带的上行经常只有下行的几分之一写字楼的共享带宽在白天更是惨不忍睹实际能达到 3~5 MB/s 就不错了这时候 50 GB 要传三四个小时。你省下来的渲染时间全砸在传输上了。规避思路有三个一是只传必要的东西贴图能压就压用无损压缩格式别用 JPG缓存能程序化生成就别传二是先传小样验证用低分辨率、低采样先跑一遍全流程确认工程在云端环境能正常跑起来再传全量三是错峰传输安排在夜间批量推。还有一个隐藏的成本调试往返。本地跑渲染出问题当场改云端跑出问题要等结果传回来才知道改完再传上去一个来回可能半天。所以上云之前本地一定要把工程跑到确定没问题的程度包括所有贴图路径、插件版本、色彩空间设置。云端最常见的失败不是算力不够是路径不对、插件缺失、色彩配置不一致。5. 混合渲染边界画在哪决定了是省钱还是找罪受5.1 三种常见的混合形态适用场景完全不同混合渲染这个词被用得很泛实际上至少包含三种不同的东西混为一谈会导致方案设计跑偏。形态一实时管线内部的混合。同一个实时场景里静态部分用预计算的光照贴图动态部分用实时光照静态阴影用烘焙、动态阴影用阴影贴图。这是最常见的形态几乎每个稍复杂的实时项目都在用。难点在接缝烘焙的阴影边缘是柔和的、有噪点的因为也是采样出来的实时阴影边缘是硬的、清晰的两者挨在一起会很出戏。处理办法是让烘焙的采样足够高、边缘做适当模糊让它和实时阴影的观感对齐。形态二实时预览 离线出图。用实时引擎搭场景、调构图、看效果确认之后切到离线渲染器出最终图。这种方式在建筑可视化和产品渲染里特别普遍因为迭代阶段需要秒级反馈交付阶段需要极致画质。难点在两套渲染器的表现不一致——材质参数不是一一对应的实时里看着刚好的金属反射离线渲染出来可能过曝或者太暗。所以必须在项目早期就做一次对齐测试同一套材质两边各渲一张逐项调参数直到接近。这个测试花半天能省后面几周的反复返工。形态三分区域混合。画面里一部分用实时算一部分用预渲染的序列帧或者全景图。比如一个展厅应用中央的展品是实时渲染的要能转、能拆背景环境和天空是预渲染的高质量贴图。这种做法的性价比极高因为背景往往占了画面 70% 的面积但只需要 10% 的交互性。5.2 烘焙和动态之间的接缝是最容易翻车的地方这块值得单独说因为它的问题特别隐蔽——你在编辑器里看不出来到了实际运行的特定视角才暴露。第一个典型问题漏光。静态物体烘焙了光照一个动态角色走过去角色身上有实时阴影但角色脚下的地面静态、烘焙不会因为角色遮挡而变暗。看起来就像角色飘在地上。处理办法是在角色脚下加一个假阴影——一张跟着角色走的半透明贴图简单粗暴但有效。第二个典型问题光照贴图分辨率不匹配。墙面用了一张低分辨率的烘焙贴图靠近看是糊的色块旁边的动态物体用的是逐像素实时光照锐利清晰。两者放一起墙像是上个世代的画质。解决办法是给近景表面单独提高烘焙分辨率或者在材质上叠一层高频的细节法线把低频的烘焙结果加细节。第三个典型问题光照变化时的错位。场景里有个开关能把主灯从暖色调到冷色。静态部分的烘焙贴图是按暖色算的一切换就露馅了——墙还是暖的动态物体已经变冷了。这种情况要么放弃烘焙、全部走实时要么做两套烘焙贴图做插值显存翻倍。所以场景里如果有可控的光照变化烘焙方案必须在设计阶段就避开这些灯用实时光照处理它们能照到的区域。5.3 实时预览加离线出图的工作流顺序排错了会做无用功这条工作流的正确顺序跟直觉相反先用低质量跑通全流程再逐步提高质量。具体来说第一步不是把场景做得多么精细而是用最粗糙的模型、最基础的材质把实时预览—导出—离线渲染—合成这条链路完整跑一遍输出一张能看的图。这一步的目的是暴露管线问题材质导出丢没丢、摄像机参数对不对、色彩空间有没有偏、分层渲染的通道命名规不规范。这些问题在粗糙模型阶段发现改起来是几分钟的事等到场景精修完了再发现可能要重做一遍材质。第二步才是逐步加细节每加一层就渲一张低采样的小图做对比。这里有个很实用的技巧固定几个检查视角每次改动后都从这几个角度各渲一张小图。人眼对绝对质量的判断很不靠谱但对同一视角的前后对比极其敏感一眼就能看出哪里变了、变好还是变坏了。第三步全片正式渲染之前挑最难的一帧先单独渲。挑那种有大量半透明、有体积雾、有复杂反射的帧。这一帧的耗时乘以总帧数才是比较靠谱的工期估算用简单帧去估最后一定超期。6. 选型决策把需求翻译成参数再对着参数选6.1 一张对照表把常见场景直接对上号前面讲的都是原理落到实际决策我整理了一个对照表按交付形态来分类比按技术分类好用。交付形态首选方案关键理由主要风险需要用户实时交互操作实时渲染唯一能提供即时反馈的方案效果上限受帧预算限制需提前规划哪些效果能开单张高质量静帧离线渲染可配云不计时间成本换极致画质迭代慢需靠分层和局部重渲控制成本视频成片交付期紧离线 云渲染 分层并行压缩工期分层控制返工传输和调试往返耗时需提前验证环境交互应用内附带出图功能混合渲染实时预览 离线出图兼顾交互体验和成品质量两套管线表现不一致需做对齐测试大场景漫游静态为主混合渲染烘焙 实时动态静态部分几乎零开销接缝处理动态物体的假阴影快速概念验证实时渲染低画质预览秒级迭代方向确定后再上质量别拿预览图当最终效果去承诺用这张表的时候有个前提要认清方案可以叠加不是互斥的。一个项目完全可以前期用实时预览做沟通、中期用离线渲染出关键帧给客户确认、后期用云渲染批量出片。真正需要一开始就定死的只有一件事最终交付物的形态。这个定了技术路线基本就锁死了。6.2 几个我踩过的坑说出来省你时间坑一用实时渲染的效果去承诺离线渲染的交付。这个错误犯过一次代价很大。实时引擎里调好的画面因为用了大量的近似和后期观感很讨喜转到离线渲染器之后物理正确的光照反而显得平、显得灰。客户看到成片的第一反应是怎么还不如之前看的那版好看。补救办法是在项目开始时就用最终管线渲几张预期效果图作为基准全程拿这个基准对齐别拿实时预览当基准。坑二以为采样数高就一定干净。前面说过噪点和采样数是平方根关系。更麻烦的是某些类型的噪点加采样根本解决不了。比如场景里有一个极小的光源随机采样命中它的概率极低采样加到一万画面里还是有一堆零星亮点。这种情况必须用光源采样直接对光源表面采样而不是靠随机光线碰运气或者把光源面积调大一点。搞清楚噪点的类型比加采样重要得多。坑三云渲染不先做小样验证。有一次为了赶时间直接把整包工程传上去开跑跑了六个小时回来看前二十帧全是黑的。原因是某个自定义材质依赖的插件版本在云端没有静默失败了。如果先用三帧低分辨率跑一遍十分钟就能发现。这个教训之后我给自己定了条规矩任何远程渲染先跑三帧小样看结果再上量。坑四忽视显存这条线。实时渲染项目在开发机上跑得飞快到目标设备上一卡一卡。查了半天发现开发机显存是目标设备的三倍纹理流送根本没触发实际部署时才暴露出问题。上线前必须在最差配置的目标设备上跑一遍这一步省不了。坑五把混合渲染的接缝留到最后处理。烘焙和动态的接缝问题越晚发现越难改因为它往往涉及场景结构的调整哪些物体必须静态、光照能不能变。这类问题应该在场景规划阶段就确定别等到画面都做完了才发现这个区域怎么都调不对。6.3 一个判断口诀实际用起来比背概念快最后留一个我自己常用的判断方式三个问题问完方向基本清楚。第一个问题这东西要不要用户实时操作要实时渲染是唯一选项剩下的是在实时框架内怎么取舍效果。不要进第二个问题。第二个问题最终画面的质量上限受不受工期约束如果是一次性的、交付即定稿那可以把时间给足走离线。如果是需要反复迭代、每天看十几版那前期必须有一段实时预览的阶段不然迭代成本扛不住。第三个问题算力需求有没有明显的波峰有波峰部分上云波谷部分本地扛。没有、常年满载那就老老实实自建把运维做扎实。三个问题回答完剩下的都是执行细节。真到执行阶段比技术选型更能决定成败的反而是那些不起眼的东西贴图路径有没有用相对路径、色彩空间配置有没有统一、渲染输出的命名规范有没有提前定好。这些地方出问题再好的方案也得推倒重来。我在实际项目里体会到最深的一点是这四种渲染方式没有优劣之分只有匹不匹配——真正拉开差距的是你能不能在设计阶段就把最终交付形态想清楚然后倒推着去选技术路线而不是先挑一个看起来很酷的方案再硬着头皮往需求上套。