企业官网建设流程全解析

上一轮用四台笔记本搭渲染农场，结果输给了自己的笔记本。问题不在 GPU，而在文件分发：农场大部分时间都在通过 5 Mbit/s 的家庭上行带宽下载一个 115 MB 的 .blend 文件。所以第二轮要解决的不是找更多显卡，而是找一种方式，把文件交出去一次，让它在别处扩散，不占用我的上行带宽。

这次我没有搭农场，而是加入了一个社区。SheepIt 是免费的、由社区驱动的 Blender 渲染农场。规则很简单：在电脑空闲时安装客户端，帮别人渲染帧，赚取积分；再用积分让社区渲染自己的帧。每个人既出机器，也消费别人的机器。我需要维护的基础设施只有一个会自我更新的 Java jar 客户端，以及一个上传 zip 的网页。没有 Samba，没有 tailnet，没有 NAT 考古。文件交到一个地方，分发到上百台机器是对方要解决的问题。

积分机制不需要钱，只需要渲染时间的进出。我注册后让客户端跑了两天七小时，为陌生人渲染了 6981 帧，随后下单了 17 个项目的 18651 帧。下单量几乎是渲染量的三倍，积分余额仍有 126 万。我无法给出 SheepIt 精确的兑换率，只能把它当作观察而非公式：轻量的 360p 帧便宜，沉重的 1080p 光线追踪帧更贵，更强的 GPU 赚积分更快。这更像一个以物易物的经济，同一台白天剪片的笔记本，晚上在替别人渲染。

把场景交给陌生人，只有一个硬性要求：你的 .blend 必须在一台你从未见过的机器上无人值守地运行，而且没有你的项目文件夹。我的场景不是为此建的。它们由 Python 脚本加载城市、重定向动画、给成千上万个值打关键帧，并烘焙结果。在我的笔记本上，这个文件依赖整个项目目录：纹理的绝对路径、城市里动画屏幕的图片序列、旁白的音频条、渲染时由脚本应用的设置。陌生人的机器没有这些，也跑不了我的脚本，所以代码里设置的参数永远不会生效。

于是我写了一个打包脚本，把构建好的场景变成自包含的文件：把所有图像打包进 .blend，让纹理随文件走；把图片序列复制到旁边并使用相对路径，因为 Blender 无法打包序列，文件夹随 zip 一起走，路径变成相对路径；删掉音频条，旁白和音效本来就会在后期用 ffmpeg 混合，农场不需要它们；把设置烘焙进文件，1920x1080、100%、64 采样、全分辨率光线追踪、运动模糊开启、PNG 输出。最后把 .blend 放在 zip 根目录。我的包在 130 到 240 MB 之间，SheepIt 上限 2 GB，空间充裕。

把场景发给陌生人，如果包是坏的，你要等几个小时后才知道，那时陌生人的机器已经用你的积分烧出一百帧全黑画面。所以每个包在离开笔记本前都要过一道检查。关键一步是解压：我不测试原始 .blend，而是把包解压到一个全新的临时文件夹，模拟农场看到的样子，在那里运行检查。每个外部文件必须存在且是相对路径；不能有音频条残留；分辨率、采样、光线追踪、运动模糊和 PNG 格式必须与预期一致。然后从解压后的副本渲染一两帧真实画面。如果这些帧看起来对，包就是对的。在我的 GTX 1650 上，1080p 测试帧需要 7 到 35 秒，这能在别人花积分之前快速判断任务是“一天”还是“一周”。检查按部件逐条命令运行，遇到第一个问题就大声报错停止，而且从不删除任何东西：旧包会被移到一边，而不是覆盖。

第一次运行新打包脚本时，它在 zip 步骤报错，说 zip 根目录缺少 .blend。我打开 zip，文件就在那里，还是第一个条目。检查代码用 grep 管道查找匹配，grep 找到匹配后立即退出，剩下的文件列表写入一个没人读取的管道，触发 SIGPIPE。而 pipefail 让整个管道失败，于是文件明明找到了，检查却报告缺失。修复方法是停止使用管道。如果你在 set -euo pipefail 下写脚本，记住这一点：它能工作，直到生产者输出超过管道缓冲区，然后在最关键的一天失败。

电影不是一镜到底。部分 Blender 场景被剪掉，第三部分的 2D 产品板根本不在 Blender 里渲染。如果上传整个场景并请求“从第一帧到最后一帧”，社区会免费渲染所有这些，然后你扔掉一半，这对出机器的人不礼貌。所以每个包只上传电影实际需要的帧范围。第 0 部分一个范围，458 帧；第 1 部分三个范围，因为三个场景被剪掉，跳过约 535 帧；第 2 部分一个范围，2441 帧；第 3 部分同一个 zip 上传两次，分别是 1 到 664 帧和 2150 到 3661 帧，中间的产品板由笔记本上的 Python 脚本几分钟生成。整部电影 8229 帧，4 分 34 秒。上一篇文章我说 7300 帧，电影变长了，电影总会变长。

每个部分回来都是一个 PNG 帧的 zip，1080p 部分在 2 到 4 GB 之间。我不信任来自陌生人农场的任何东西。所以在一帧进入视频之前，检查脚本会看 zip：压缩包是否完整；帧数是否与构建记录完全一致，从第一帧到最后一帧编号，没有缺口也没有多余；每个 PNG 是否能解码，尺寸是否精确；是否有整帧全黑。全黑帧是农场在告诉你，某个工作节点出了问题。如果全部通过，帧会被硬链接到一个编号文件夹，不复制，所以 4 GB 的集合不额外占空间；ffmpeg 编码基础视频，组装脚本混入旁白、音效、音乐、字幕和帧号烧录。帧号是给团队看的，当有人说“1201 帧附近有问题”，我能找到它。

渲染脚本会跳过已存在的帧，这在长渲染中断时很好，但在场景改变后很糟。旧版本的残留帧留在文件夹里，渲染器说“已完成”，新电影里就混进了旧镜头。我现在的规则是：场景改变时，把旧帧文件夹移到一边，不删除、不清空，渲染从干净文件夹开始。

项目的工作流已经定下来。草稿在本地：360p、EEVEE、无光线追踪、无运动模糊，每帧约 0.7 秒，第 2 部分的 2441 帧大约 30 分钟，整部电影约两小时。煮杯茶回来，看 Miles。终稿在农场：1080p、64 采样、光线追踪反射、运动模糊，一天的笔记本时间分散在一个不需要我盯着的社区里。两者之间是团队能打开审阅的版本。

Miles 拿到 1080p 了吗？拿到了。四个部分中已有两个从社区农场回来，开场是 2 GB 的 PNG zip，第 2 部分是 3.7 GB。然后团队的修改意见到了，电影在它们下面变了。所以现在有一组新的包，已经验证并准备好发给社区，每个包都从解压副本渲染了测试帧。

如果要对上周的我说点什么：社区已经在跑农场时，不要自己搭。四台笔记本教会我很多网络知识，社区教会我的是，我一直在解决错误的问题。先让场景自包含，再让它变快。如果文件只在你机器上能用，它就只在一台机器上能用。验证包，而不是原始文件：解压到干净文件夹，从那里渲染一帧。保留一个便宜的草稿循环，它让队友说“这个词错了”时，不需要花掉你一天。最后，谢谢那些陌生人的 GPU，它们将渲染最终版本。