一个带着自身资源一起走的 Blender 场景。

Pli 项目：一份场景配方，边界清晰

Pli 是为本次练习虚构的一只瓶子：紫色瓶身、棱角柔和，缎面橙色领圈，人字纹标签，陶土底座。生成器预设了影棚灯光和左侧留白的构图。它负责构建对象和材质；唯一的外部图像是一张 512 × 512 像素的原版 PNG 图案，并附带可重新生成它的程序。无需任何模型、HDRI、字体或客户文件。

目标是 Blender 4.5.x LTS 配合 Cycles。该文件夹针对单张静帧，不含模拟或扩展。生成器会拒绝其他 Blender 分支，让这一选择保持明确。Python 3.10 或更高版本即可校验文件；而要构建场景，则需要 Blender 内置的 Python。

Pli 提供一个需用 Blender 4.5.x LTS 运行的生成器。文件和错误情形已在 Python 3.14.6 下校验；场景的创建、打开与渲染仍待在 Blender 中测试。不提供任何 .blend 文件或渲染结果。

复制之前，先确定项目应还原出什么

先明确交付物：单张静帧、动画还是系列变体。记下软件及其版本、引擎、活动摄像机、场景、尺寸和质量参数。若是动画，还要加上帧率和闭区间端点。一个能打开的场景，并不一定能还原出相同的纹理、相同的缓存或正确的取景。

请在一个冻结版本上工作，并保留原始文件。把用到的资源与放弃的尝试分开；两张名字几乎相同的纹理可能正是材质差异的原因。同时核对模型、图像和库的转移权限。Pli 包为其自有脚本、文档、图案和所述几何体提供 MIT 许可证；你添加的内容可能有其他条件。

在 Pli 中，scene.json 充当起始清单：目标版本、十个对象的清单、图形依赖、引擎、图像 1 以及输出目标。它还标明了本项目并不存在的东西：链接库、字体、缓存和动画。明确声明不存在，能避免把一个空文件夹误当作被遗忘的资源。

一套让每个文件都有明确职责的目录结构

保留一个带版本号的根目录，这里是 blender-v1，并在开始工作前解压归档。下面的划分能帮你追溯某张图像的来源、可编辑的项目和待交付的结果。它并不强加一套通用约定：更重要的是采用接手此文件夹的人无需你的聊天记录也能看懂的命名。

分发的源文件列在 manifest.sha256.json 中，含其大小和指纹。清单会自我排除，以避免循环引用。未来的 .blend、PNG 和报告属于输出：它们需在验证后纳入你自己的交付清单。

启动 Blender 前检查解压出的 ZIP 内容

从解压后的文件夹根目录开始，使用独立的 Python 运行验证器。它将十三个文件与清单进行比对，检查配方、路径和 PNG，然后分析四个脚本的语法。完整无损的资源包预期结果为 ok: true 且退出码为 0。此检查不会导入 bpy，也不会生成任何 3D 图像。

我们的测试从解压到另一位置的 ZIP 开始。验证过程仅允许在该副本和所用 Python 所在目录中进行读取；任何试图访问原始配方的操作都会被明确拒绝。因此，成功与否并不依赖于在创作文件夹中悄悄找到的纹理。

返回码 1 时，必须阅读错误列表。不要通过重写指纹来消除警告。请使用完整无损的压缩包，或者，如果您想修改场景，请创建一个单独的工作版本。指纹相同只能证明文件相对于清单的完整性，并不能证明其视觉质量或作者身份。

python validate_pack.py --root . --json

重建瓶身并请求小型 CPU 渲染

以下命令是在装有 Blender 4.5.x LTS 的机器上执行的流程；本次准备过程中并未实际执行过它。请在一个专用进程中运行它：该脚本从一个空场景开始。在 Windows 上，如果 blender 不在 PATH 中，请使用可执行文件的完整路径；在 PowerShell 中，请在该带引号的路径前加上 &。

生成器会先检查资源包，创建对象，从副本加载纹理，将其整合并保存 02_projet/renderparcel_pli_v1.blend。保存的文件预设为 Cycles CPU、1 200 × 750 像素、64 采样以及图像 1。随后 --render-preview 选项会请求生成一张 480 × 300 像素、16 采样的 PNG，且不进行降噪。这些数字是设置值，而非性能测量值。

报告 reconstruction.json 会在操作成功完成后写入，并说明渲染是否真正执行过。若只想构建 .blend，请去掉 -- --render-preview。脚本拒绝覆盖已存在的输出：第二次尝试会在新的解压目录中进行。--python-exit-code 1 选项可通过进程的退出码来识别脚本异常。

blender --background --factory-startup --python-exit-code 1 --python generate_scene.py -- --render-preview

相对路径：描述位置时别漏掉副本

在 Blender 中，以 // 开头的路径是相对于 .blend 文件所在位置的。由于 Pli 项目将位于 02_projet 中，其纹理可以表示为 //../03_ressources/pli-chevron.png。资源文件夹会随项目一起移动。不过，生成器会先使用在副本中解析出的绝对路径，纳入该图像，然后在保存前写入相对路径。

对于已有项目，请先将 .blend 保存到传输文件夹中。在 File → External Data 中，Make Paths Relative 会转换这些引用；此操作不会复制资源。Report Missing Files 有助于找出断开的链接。Find Missing Files 会在所选文件夹中查找文件，并可将引用修复为绝对路径：转移前请再次检查这些路径。

不要混淆“在这台机器上找到”和“存在于文件夹中”。仍然能在下载文件夹中访问的纹理会掩盖遗漏。复制后，请在一个旧位置无法再满足链接的环境里打开项目，同时保留一份独立的备份。

嵌入符合条件的资源，清点其余资源

Pack Resources 可将符合条件的资源包含进 .blend 文件；保存后，这一操作才会在传出的文件中生效。它并不会把全部依赖项都收拢进来：视频就是一个有据可查的反例。链接的库有单独的嵌入命令。因此，请列明哪些内容会被嵌入，哪些内容必须留在项目旁边。

对于 Pli 而言，保留外部的 PNG 便于修改，而将其嵌入则应当能在保存后的文件中找回该图案。修改纹理后，必须更新实际使用的资源，然后保存正确的版本。仅仅替换旁边的一个同名 PNG，并不能证明 .blend 使用了它的新像素。

在第二个进程中重新打开并填写一份真实的验收单

重建成功后，inspect_scene.py 会在第二个 Blender 进程中打开该 .blend，并禁用其内部脚本的执行。它会检查清单、摄像机、输出设置、AgX 变换、嵌入的纹理及其相对路径。它的报告描述打开过程与数据，并不证明渲染质量。

在图像查看器中打开生成的 PNG。检查瓶子是否完整保持在画面内、标签是否显示出奶油色、紫色和橙色的图案、与底座的接触是否清晰可辨，以及是否没有出现洋红色的纹理。这些标准是验收意图；我们不针对此包发布计算好的 Blender 参考图。

将 06_livraison/modele-reception.csv 复制为 06_livraison/reception-executee.csv，然后填写这份新表单。保持模板不变：它属于清单的一部分。验证器接受已填写的副本，而不会修改源文件的指纹，我们的验收测试已验证了这一点。随后，请将这份表单和已批准的输出一并列入你的交付归档。

blender --background --factory-startup --python-exit-code 1 --python inspect_scene.py

缺失的依赖项必须中止检查

该包的反向练习会从一份试运行副本中移除 pli-chevron.png，而不触碰源文件。此时验证器返回代码 1，并同时指出清单中缺失的文件和配方中缺失的依赖项。生成器也从同一项检查开始：它必须拒绝在这份不完整的副本上继续。

另一项测试会改动 PNG 的第一个字节；检查会发现指纹不同以及图像签名无效。第三项测试将其路径替换为一个指向文件夹之外的引用，同样被拒绝。这些测试验证的是具体的传输缺陷。它们既不模拟 Blender 的打开过程，也不模拟动画中缓存的消失。

若要重做该练习，请仅在额外的解压副本上操作，并保留一份完好的副本。修正的方法是找回正确的资源及其预期位置。同名但内容不同的纹理会通不过完整性检查。

添加动画会改变检查范围

Pli 场景只有一张图像，不需要任何缓存。如果为它添加烟雾、布料或模拟，请记录缓存类型、计算版本、存放位置以及全部有效范围。预计算机制取决于物理系统；不要把某一种缓存的行为推广到其他所有缓存。

复制前先冻结结果。对于序列，要检查开头、结尾、场景或模拟的变化，还要检查每个中间文件是否存在。三张视觉上正确的图像并不能证明 1 到 96 的动画中那 96 个文件都可用。要明确说明缓存是随包交付还是需要重新计算，以及使用哪些参数和哪些输入。

对纹理、体积、声音和剪辑媒体序列应用同样的逻辑。不要在创建 ZIP 后删除唯一的源文件：请保留它们，直到副本打开、输出经过检查并完成回收。

颜色、内存和时长：衡量真实项目

Pli 图案用于基础颜色，声明为 sRGB。描述法线或置换的贴图作用不同；其解释必须与数据相符。比较输出时还要保留显示变换和曝光设置。颜色差异可能来自显示管线，与计算能力无关。

ZIP 的大小并不代表 GPU 内存需求。评估后的几何体、实际加载的纹理和渲染步骤，比压缩包里的文件数量更重要。一个小的 CPU 预览既不能预测内存峰值，也不能预测最终 GPU 渲染的时长。在选择配置之前，请以最终分辨率测量一次有代表性的完整输出。

3D 工作坊有助于框定这项检查。然后根据兼容性和观测到的峰值比较GPU 配置，并留出适合项目的余量。在配置器中选择 3、7 或 30 天，以涵盖打开、测试、返工、计算和回收；这些时间窗口中的任何一个都不单独保证渲染期限。导出指南将工作延伸到可交付文件。

已验证的内容，以及仍需执行的部分

以下七项检查已在 Windows 上使用 Python 3.14.6 执行。压缩包包含十四个文件，其中包括清单；其中十三个文件由其指纹覆盖。纹理已在此环境中重建并逐字节比对。这种 PNG 相等并不证明不同版本或硬件之间的 3D 渲染完全一致。

这些检查针对文件、其依赖项和传输错误。.blend 的生成、场景检查以及 CPU 或 GPU 渲染尚未测试。README 给出了在 Blender 4.5.x LTS 中验证它们的步骤。