Blender场景中有大量重复框架、窗户、树木或路灯时，不要先问"哪一种方式最快"，而要先确认编辑和交付要求：每件都要单独改形，可使用普通复制；形状一致但位置不同，可优先考虑共享网格；大量规则重复内容可以评估实例；确实需要减少对象管理开销时，再考虑分区合并。没有一种方式在所有场景中天然最快，也不能只看对象数量判断优化结果。
一、看着重复，不等于数据组织方式相同
画面中的十个框架，可能对应十份独立网格，也可能是十个对象共享一份网格数据、由某种实例系统生成，或者已经被合并为一个对象。它们在当前视角下可以长得一样，编辑、导出和运行行为却可能完全不同。
- 普通复制便于每件独立修改；
- 共享网格适合统一修改形状，同时保留各对象的独立变换；
- 实例适合组织大量重复内容，但编辑入口和导出结果取决于具体机制；
- 合并可以减少对象，却可能牺牲单体点选、剔除和局部加载的粒度。
图注：重复框架适合说明普通复制、共享数据、实例与合并的组织差异；仅凭截图不能判断当前场景采用了哪一种方式，也不能证明性能好坏。
二、动手前，先回答三个问题
1. 这些物体是否需要一起修改几何？
例如，所有框架都要统一加粗，是希望改一次后全部更新，还是每个框架都可能采用不同截面？前者更适合共享源数据，后者更需要独立网格。
2. 位置、旋转和缩放是否需要独立？
共享几何不等于共享位置。多个对象可以引用同一份网格数据，同时拥有各自的位置、旋转和缩放。把每个框架摆在不同位置，并不要求每个框架都保存一份独立网格。
3. 是否需要单独隐藏、点选、导出或卸载？
源文件里可以单独选择，不代表进入Unity、Unreal或网页查看器后仍然保留同样的对象粒度。应把目标端的点选、剔除、LOD和分区加载要求提前写进选型条件。
例如，走廊中的普通框架截面相同，只有入口框架需要更宽，可以让普通框架共享主体网格，再把入口框架改为独立网格。没有必要为了一个例外，让所有框架都复制出独立数据。
三、普通复制与共享网格：用一个小实验分清
在Blender默认键位下，Shift+D通常会创建能够独立编辑网格的副本；Alt+D创建链接副本，多个对象引用同一份网格数据。两者都可以在对象模式中独立移动、旋转和缩放。
这里讨论的是网格数据。材质、图像和其他数据块有各自的引用关系，不能因为网格已经独立，就认定所有关联数据也全部独立。
可以用一个立方体完成最小实验：
- 新建立方体，用
Shift+D创建普通副本； - 回到源立方体，用
Alt+D创建链接副本； - 只选择源对象并进入编辑模式，移动一个顶点；
- 观察链接副本是否同步变化，普通副本是否保持原形；
- 回到对象模式，只移动其中一个对象，确认其他对象的位置不受影响。
实验时不要同时选中多个对象进入编辑模式，否则多对象编辑可能被误认为数据共享。
如果链接副本需要单独改形，可以先将目标网格变成单用户数据。常见做法包括点击对象数据属性中网格名称旁的用户数，或通过 Make Single User 相关命令处理对象数据。不同Blender版本和界面配置可能不同，操作后应检查网格数据名称和用户数，确认引用关系已经改变。
仅修改对象名称或网格名称，不会解除数据共享。
四、实例：先说明使用的是哪一种机制
集合实例、几何节点实例和引擎实例都采用了复用源内容的思路，但它们不是同一种机制。编辑粒度、属性覆盖、层级结构和导出处理可能不同，不能把一种实例的操作步骤套用到所有系统。
通常情况下，修改源内容可以同步影响相应实例。出现单体例外时，可以根据机制选择：
- 使用另一份独立源；
- 使用系统支持的属性或材质覆盖；
- 把目标实例转换为可编辑对象；
- 在几何节点中为例外对象提供不同输入或选择条件。
集合实例的 Make Instances Real 与几何节点中的 Realize Instances 解决的不是完全相同的问题，不能互相当作操作步骤。集合实例被转换成对象后，生成对象的网格数据仍可能共享；"实现实例"不等于"所有对象都变成独立网格"。需要单独编辑时，还要继续检查数据用户数与引用关系。
单个实例能否独立换材质，也取决于实例系统、材质分配方式及目标端支持。看到实例可以单独移动，不能据此推出它一定能单独修改材质或拓扑。
五、合并对象不是一键性能优化
在对象模式中选择多个网格对象，使用 Ctrl+J 可以把它们合并到活动对象中。这个操作改变的是对象组织方式，不会自动焊接相邻顶点，也不是布尔融合，更不会替你完成重叠面、法线或材质清理。
合并时还应注意活动对象的变换、材质槽和修改器等关系。操作前保留副本，并在合并后检查外观、对象原点、材质分配和层级，不能只看大纲视图中对象数量是否减少。
对象少也不等于Draw Call少。Draw Call是一次绘制提交，不是对象计数；材质槽、导入后的子网格、阴影和其他渲染通道都可能影响实际提交量。一个带有多种材质的合并对象，仍可能需要多次绘制。
大范围合并还可能影响剔除。目标端若把整块合并对象作为一个可见性单元，只要其中一小部分进入视野，整块内容就可能继续参与处理。LOD和局部加载的粒度也可能因此变粗。
因此，合并通常应结合实际空间边界评估，例如按房间、楼层、街区或可独立加载的区域组织，而不是把整个场景一次性合成一个对象。
性能判断要固定场景、物体位置、材质、相机路线、构建版本和目标设备，再比较CPU/GPU帧时间、实际绘制提交、内存与加载行为。视口看起来更顺或对象数下降，只能作为线索，不能直接写成优化结论。
六、制作四个小样，检查完整交付链
可以从同一组框架复制四份测试场景：
- A：普通复制；
- B：共享网格；
- C：集合实例；
- D：按空间边界分区合并。
这里明确使用集合实例，避免把集合实例、几何节点实例和引擎实例混成一个测试项。四组应保持框架数量、位置、材质、相机和显示设置一致，每次只改变对象组织方式。
| 检查阶段 | 建议记录 |
|---|---|
| Blender源场景 | 对象数、网格数据块数、用户数、统一改形与单体改形能力 |
| 导出文件 | 格式、导出选项、文件体积、对象层级和数据是否被展开 |
| 空场景回读 | 几何、材质、层级、实例或共享关系是否仍符合预期 |
| 目标端 | 资源引用、单体操作、剔除粒度、绘制提交及CPU/GPU帧时间 |
这是一套测试设计，不是本文已经执行的性能实验。没有真实记录时，结果应填写"待测试"，不能先指定哪种方式胜出。
GLB、FBX等格式的结果会受到软件版本、导出选项和目标端导入器影响。实例可能被展开，也可能需要在导入流程中重新建立。文件扩展名本身不能保证保留实例或共享网格关系。
导出后，先把文件重新导入单位和设置明确的空场景，检查几何与层级；再进入真实目标项目，检查资源引用、点选、剔除和运行表现。"文件重新打开没有报错"只说明部分交接可用，不等于已经通过性能或编辑验收。
需要继续检查Blender与目标端的交接时，可以把模型接入DCC与引擎流程。该入口不能保证实例、层级和共享关系在不同软件之间自动保持一致，仍需用真实文件回读。
七、选型表：把编辑需求与目标端验证放在一起
| 组织方式 | 统一修改几何 | 处理单体例外 | 点选与剔除粒度 | 主要交付风险 | 常见适用场景 |
|---|---|---|---|---|---|
| 普通复制 | 通常需分别修改 | 可直接独立修改 | 源端可单独点选；目标端仍需验证 | 可能重复存储几何 | 各物体形状会分别变化 |
| 共享网格 | 修改共享网格即可同步 | 先转为单用户数据 | 对象可分别变换和点选；目标端仍需验证 | 共享关系可能在导出时改变 | 同形物体独立摆放 |
| 实例 | 通常修改实例源 | 换源、覆盖属性或转换 | 取决于实例机制与目标端 | 可能被展开、烘焙或重建 | 大量规则重复单元 |
| 分区合并 | 修改合并后的几何 | 在编辑模式选局部或重新拆分 | 通常以分区为对象级粒度 | 层级、剔除和加载粒度改变 | 按房间、楼层或街区管理 |
这张表用于缩小选择范围，不是性能排名。真正的结论仍应来自目标端小样。
八、常见问题
1. 为什么对象可以单独移动，编辑顶点时却一起变化？
因为对象变换彼此独立，但多个对象引用了同一份网格数据。需要单独改形时，应先检查网格用户数并建立独立数据。
2. 合并对象一定能减少Draw Call吗？
不一定。材质、子网格和渲染通道仍会影响实际提交量，应查看目标端渲染记录，而不是用对象数量代替。
3. 单个实例能否单独修改材质？
取决于实例机制、材质分配方式与目标端支持。先用一个实例做覆盖和导出回读，不要从"可以移动"推断"可以改材质"。
4. 哪一种方式最节省内存？
没有脱离软件和交付链的统一答案。需要同时检查源端数据复用、导出时是否展开，以及目标端如何组织和加载资源。
九、交付前检查清单
- 已明确哪些构件统一改形，哪些需要单体例外；
- 已核对对象、网格数据及用户数，而不是只看对象名称；
- 实例类型和转换方式已经写清；
- 合并范围遵循实际空间或加载边界；
- 导出后已检查层级、数据共享和资源引用；
- 目标端已测试点选、剔除、绘制提交和帧时间；
- 没有执行的性能项目已明确标记为"待测试"。
你的重复框架究竟需要每件单独改形，还是只需要独立摆放和点选？如果按房间合并，目标端能否保留所需的剔除与加载粒度？先回答这两个问题，再决定使用普通复制、共享网格、实例还是分区合并。