基于代码 / 脚本的 3D 生成¶

这条路线的共同点是让模型输出一种可执行的程序表示，再由 Blender、几何节点系统、场景 DSL 或引擎 API 把程序执行为 3D 几何、场景或动画。

从表示角度看，这类方法把“3D 结果”换成了“生成 3D 的程序”。因此它们讨论的核心问题也随之变化：

程序是否可执行
程序是否保留结构和语义
程序参数是否便于后续编辑
程序执行后的结果是否满足空间、物理或布局约束

详细对比矩阵

关于该领域核心工作（GeoCode, VIGA, VoxelCodeBench, Infinigen 等）在模型角色、平台、是否开源等方面的横向比较，请查看 程序化与代码驱动 3D 路线对比矩阵。

1. 代表工作¶

工作	任务与输入输出	程序表示	方法角色
`GeoCode` (2025)	点云/草图 -> 可解释 3D 形状	Blender 几何节点程序参数	形状程序反演
`MeshCoder` (2025)	点云 -> 结构化 3D 网格程序	Blender Python 脚本	开放 API 的对象级代码生成
`VIGA` (2026)	单图 -> 3D/4D 场景	Blender 场景脚本 + 工具调用	视觉反馈驱动的程序改写
`VoxelCodeBench` (2026)	文本 -> 体素场景代码	Unreal Engine 体素 API	空间推理评测基准
`Infinigen` (2023)	无约束 / 随机种子 -> 自然场景	数学规则 + 节点图 + Python	纯程序化自然世界生成
`Infinigen Indoors` (2024)	布局约束 -> 室内场景	Python DSL + 约束求解器	约束驱动的程序化场景生成

这些工作看上去都在“写代码”，但实际可以分成几类不同问题。

2. 几类主要问题¶

2.1 从观测反推程序¶

GeoCode 和 MeshCoder 都属于这一类：输入是点云、草图或已有几何，输出是可执行的程序表示。

二者的差别在于程序空间的设计方式不同。

GeoCode 先人工设计一套较强约束的程序空间。程序由曲线、triplet、对称和附着关系组成，重点是结构有效性和高层参数可解释性。网络学习的是参数恢复，而不是开放式代码续写。
MeshCoder 直接把目标语言换成更开放的 Blender Python API。它不再把表示限制在少量几何 primitive 或 DSL 指令里，而是利用大规模“点云-代码”配对数据训练多模态 LLM 输出脚本。

这说明 code/script 路线内部也有两种不同取向：

一种是先约束程序空间，再学习参数反演
一种是直接学习开放 API 的代码生成

前者更容易保证结构稳定，后者表达力更强，但也更依赖数据覆盖和执行环境的一致性。

2.2 用视觉反馈不断修改程序¶

VIGA 讨论的是如何把逆向图形写成一个持续修正程序的过程，而不是一次性从输入恢复出正确脚本。

它的核心做法是把基础 VLM 放进 Blender 工具链中，让模型反复执行以下步骤：

写脚本
执行并渲染
从多个视角检查当前结果
用自然语言总结差异并修改代码

因此，VIGA 更像“agent 化的 inverse graphics”。在这条线上，程序不仅是输出结果，也是模型后续思考和修正的工作记忆。

2.3 直接把世界生成写成程序¶

Infinigen 系列与前两类不同：它从一开始就把世界本身写成程序。

Infinigen (2023) 关注自然世界。地形、植物、动物、天气、材质都由随机数学规则生成，不依赖外部静态资产。
Infinigen Indoors (2024) 把这件事扩展到室内场景，并额外引入 Python DSL 和约束求解器，用来表达对称、可达性、物理稳定性、数量关系和语义布局。

这类方法更看重“程序系统有没有足够的生成覆盖、控制接口和执行效率”，而不是“模型有没有学会 3D prior”。

2.4 把代码生成当成空间推理测试¶

VoxelCodeBench 的角色又不同。它是一个评测框架，不是新的 3D 生成器。

论文把文本到代码到体素场景的流程拆开，专门问一个问题：

大模型能否真正写出空间上正确的 3D 场景代码？

它构建了 220 个任务、47 个 API 函数的 Unreal Engine 体素环境，并把任务分成：

symbolic reasoning
geometric construction
artistic composition

论文的结论很直接：代码能执行并不等于空间结果正确。多物体组合、几何构造和复杂空间关系仍然是当前模型的薄弱环节。

3. 这些工作共享的优点¶

3.1 输出天然可编辑¶

如果结果是脚本、节点参数或 DSL，后续编辑就不必总是回到 mesh 顶点层或 latent 空间。用户可以直接修改：

尺寸
对称关系
阵列数量
零件参数
布局约束

GeoCode、MeshCoder 和 Infinigen Indoors 都明显利用了这一点。

3.2 结构信息更容易暴露¶

程序表示通常显式包含：

零件划分
附着关系
层级结构
布局约束
生成顺序

这使它比“直接给一个最终 mesh”更适合做结构问答、规则检查和后续装配修改。

3.3 更接近可验证工作流¶

程序可以被执行、检查、重跑，也可以插入额外规则，例如：

碰撞检测
可达性检查
数量守恒
几何合法性检查
多视角渲染比对

这一点也是 VIGA 和 VoxelCodeBench 特别强调的地方。

4. 这条路线目前的边界¶

4.1 还不等同于 CAD 级参数化建模¶

虽然这条路线比直接输出 mesh 更接近“可编辑、可复现、可验证”的目标，但当前公开工作大多仍建立在：

Blender Python
几何节点参数
Unreal 体素 API
场景 DSL

它们更适合视觉资产、程序化场景和逆向建模研究，还不等同于严格的 CAD 内核、装配树、公差约束或制造规则系统。

4.2 程序空间决定了可覆盖范围¶

GeoCode 的优势来自精心设计的程序空间，但这也意味着覆盖范围受限于已有程序模板。MeshCoder 改用开放 API 后表达力更高，但训练数据和执行稳定性又会成为新的瓶颈。

4.3 结果质量依赖执行器而不只依赖模型¶

在这条路线上，最终质量不仅来自模型本身，还来自：

API 设计
执行器稳定性
几何节点/脚本模板质量
约束求解器
资产库或外部导入模块

这与直接比较一个 diffusion backbone 的质量并不是同一类问题。

5. 放到整个 3D 生成版图里怎么看¶

如果把当前 3D 生成研究粗略分成两类：

面向视觉资产生产的概率式生成
面向可编辑程序表示的 code/script 生成

那么 CLAY、TripoSG、Hunyuan3D、TRELLIS 更接近前者；GeoCode、MeshCoder、VIGA、Infinigen 更接近后者。

后者更强调：

表示能否执行
参数能否解释
结构能否检查
场景能否复现

因此，这条路线与我们在 Mesh Generation Models 中提到的“工业生成更可能需要输出可编辑、可验证表示”这一判断是吻合的。不过，当前公开论文离严格 CAD 还有一段距离，更多仍处在 Blender/程序化场景/逆向工程这一层。

6. 一句话总结¶

基于代码 / 脚本的 3D 生成，是把 3D 当成可执行程序的运行结果来建模，而不只是把它当成最终几何结果来预测；它更适合讨论可编辑性、结构控制、空间推理和约束执行，而不是只比较一次前向生成的观感质量。