企业官网建设流程全解析

很多人第一次接触这四个词，都是在同一个场景里：手上有个三维场景，想把画面变成图或者变成视频，然后发现面前摆着四条路——实时渲染、离线渲染、云渲染、混合渲染。大多数资料会告诉你"实时快、离线好、云渲染省钱、混合渲染兼顾"，这四句话基本等于没说，因为它解释不了一个最实际的问题：我手上这个活，到底该走哪条路，走错要多花多少时间和钱。我带过几个项目，从建筑可视化的漫游程序到几分钟的三维短片，四种方式都实打实跑过一遍，中间因为选错路线返工的次数不少。这篇就把这四者拆开讲透，不讲概念定义，讲它们是怎么被约束条件逼出来的——搞清楚每种方式背后被什么卡着脖子，选型就不再是靠猜。不管你是在做游戏、做产品演示、做影视短片还是做工业仿真，读完应该能自己判断该往哪条路上走。

1. 这四个词说的不是同一个维度的事，先把这个前提理顺

1.1 一张图从提交到出图，中间到底发生了什么

先把链路走一遍，后面所有的差异都藏在这条链路里。你搭好一个场景，里面有几百万个三角面、几十盏灯、一堆带粗糙度贴图的材质。渲染器要干的事情只有一件：算出每个像素最终是什么颜色。听起来简单，实际计算量大得离谱，因为一个像素的颜色取决于打到这个像素上所有光线的来源——直射光、经过墙面反射一次的光、反射两次的光、穿过玻璃折射之后再反射的光，理论上要沿着无数条光路一直追下去。

现实中不可能真追无穷条，所以所有渲染器都在做同一件事：用有限的采样去逼近那个理论上无限的计算。差别就在于，你给它多少时间、允许多大的误差、这个误差是"这一秒必须算完"还是"这一帧可以算八小时"。实时渲染是被卡死了时间的极端情况，离线渲染是把时间放开到极致的另一种极端，云渲染是把"有多少机器能同时算"这个变量单独拎出来卖，混合渲染则是在同一个项目里对不同部分用不同的策略。这四个词不构成一个并列的选择题，它们是三个不同维度上的坐标：时间维度、资源维度、分工维度。

理解这一点很关键。很多人把云渲染当成离线渲染的替代品，其实云渲染只是"算力从哪来"的问题，它既可以跑离线渲染，也可以跑实时渲染的预计算部分。混淆这两个维度，方案设计从第一步就会歪。

1.2 为什么"实时"和"离线"不能简单用"快慢"来区分

最容易被误解的一点：以为实时渲染就是"快速的离线渲染"。完全不是。这两者的算法栈是两套东西，不是同一套东西调了调速度。

实时渲染的核心约束是每帧必须在固定时间内出结果，60 帧每秒意味着 16.67 毫秒，120 帧意味着 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 提到 400（4 倍），误差只降到原来的二分之一；从 100 提到 10000（100 倍），误差才降到十分之一。换成更好懂的说法：你花 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/s，50 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 一个判断口诀，实际用起来比背概念快

最后留一个我自己常用的判断方式，三个问题问完，方向基本清楚。

第一个问题：这东西要不要用户实时操作？要，实时渲染是唯一选项，剩下的是在实时框架内怎么取舍效果。不要，进第二个问题。

第二个问题：最终画面的质量上限，受不受工期约束？如果是一次性的、交付即定稿，那可以把时间给足，走离线。如果是需要反复迭代、每天看十几版，那前期必须有一段实时预览的阶段，不然迭代成本扛不住。

第三个问题：算力需求有没有明显的波峰？有，波峰部分上云，波谷部分本地扛。没有、常年满载，那就老老实实自建，把运维做扎实。

三个问题回答完，剩下的都是执行细节。真到执行阶段，比技术选型更能决定成败的，反而是那些不起眼的东西：贴图路径有没有用相对路径、色彩空间配置有没有统一、渲染输出的命名规范有没有提前定好。这些地方出问题，再好的方案也得推倒重来。我在实际项目里体会到最深的一点是，这四种渲染方式没有优劣之分，只有"匹不匹配"——真正拉开差距的，是你能不能在设计阶段就把最终交付形态想清楚，然后倒推着去选技术路线，而不是先挑一个看起来很酷的方案，再硬着头皮往需求上套。