Procedura：基于过程化控制的 Agentic 三维建模

  • 关联论文：2608.26238
  • 作者：spark
  • 更新：2026-08-29

一句话结论

原生 3D 生成器能恢复逼真 mesh，但密集网格在该硬的地方软、没有部件分解、暴露不出可编辑参数——Procedura 把 "3D 形即代码" 范式推到工程化高度：让 Agent 把物体写成过程化装配体（parametric program + 具名部件 + 类型化可机器校验的配合关系），按 mated frame 一件件求解 placement，并通过 compile / mate / connectivity 三重检查才入库，再由解耦的 vision critic 按"诊断修一次"方式精修；在 P3D-Bench 与自建 hard-surface 基准 MechBench-36 上同时超越原生 3D 生成器与所有 3D-code agent，且输出可直接编辑、有部件结构——这是唯一一项做到"程序即产物"的方案。

解决的真问题

当前 3D 生成领域有两类主流路径，都存在硬伤：

  1. 原生 3D 生成器（单图 → mesh / NeRF / 3DGS / Gaussian Splatting）：能恢复高质量几何，但产物是密集、柔软、无结构的 mesh——①机加工该硬的地方（边缘、棱、角）显示为圆角软倒角；②没有部件分解（整个网格是一整块）；③不暴露可编辑参数（用户想改尺寸、换材质、做关节都做不到）。
  2. 3D-code Agent（LLM 直接生成 Blender / OpenSCAD 代码）：产物有结构可编辑，但 placement 经常猜错——LLM 不知道坐标系从哪里算起，常出现部件浮空、重叠、比例失真。

Procedura 走第三条路：让产物是过程化程序 + 可机器校验的装配图，把 placement 求解放在 mated frame 里做几何推导而不是直接猜，再用 vision critic 做后处理精修。

核心方法

Procedura 的核心是 "3D 形即代码 + 装配体语义" 的范式：

1. 物体表示：procedural assembly

每个物体被表示为一个 parametric program：

  • 具名部件（named parts）：如 seat、back、leg、armrest；
  • 类型化、可机器校验的配合关系（typed, machine-checkable mates）：如 coincident、parallel、concentric、distance=0、angle=90°；
  • per-part 材质 + simulator-validated articulation（关节/可动部件经过仿真器验证）。

这种表示让产物天然"可编辑 + 可拆解 + 可仿真"，而 mesh 表示做不到这三件事。

2. 生成流程：plan → write → solve → check

[ Text Prompt ]
      ↓
[ Agent plans object as assembly graph ]  ← 规划部件拓扑
      ↓
[ Agent writes program part by part ]    ← 逐部件写代码
      ↓
[ Solve placement from mated frames ]    ← 几何推导 placement
      ↓
[ Compile / Mate / Connectivity Checks ]  ← 三重校验
      ↓
[ Pass → 入库 / Fail → 拒收当前部件、重写 ]
      ↓
[ Decoupled vision critic refines 1 fix at a time ]  ← 视觉后处理

关键步骤解释：

  • plan as assembly graph：先在高层规划部件之间的依赖（哪些部件是 base、哪些是 attachment、哪些有 motion）。
  • write part by part：不是一次性写完整物体，而是按拓扑序逐部件写。
  • solve from mated frames：place part 不靠猜，而是从已知 part 的 mated frame 推导出当前 part 的目标位姿——这是几何推导，不是生成。
  • compile / mate / connectivity checks：每个 part 入库前必须过三道关——程序能编译、配合关系数学成立、连通图正确。
  • vision critic 1-fix-at-a-time：与 generative model 解耦的 vision 模块，按"诊断 → 修一次"循环精修，不是端到端重生成。

3. 与 Mesh 生成、纯 3D-code 的对比

维度 原生 3D 纯 3D-code Procedura
几何质量 高 中（placement 错） 高
编辑性 ❌ 网格无参数 ✅ 代码可改 ✅ 程序可改
部件分解 ❌ 整块网格 ⚠️ 看 LLM 表现 ✅ 强制结构
Hard-surface 锐边 ⚠️ 易圆角 ⚠️ 看代码 ✅ 程序控制
物理可动 ❌ ⚠️ 需额外标 ✅ articulation 仿真验证
工程可控 ❌ ⚠️ ✅ 三重检查 + 解耦 critic

关键实验与数据

abstract 直接给出的事实（可信、可溯源）：

  • 评测基准：P3D-Bench（在其 assembly judge 下）+ MechBench-36（自建 hard-surface benchmark，36 个机加工类物体）。
  • 对比对象：state-of-the-art 原生 3D 生成器 + 所有 prior 3D-code agents。
  • 结论 1：在 judged quality 上双基准同时超越 SOTA。
  • 结论 2：在所评测的所有方法中产出最锐利的边（sharpest edges）。
  • 结论 3：唯一输出是"editable, part-structured program"的方法——其他方法要么 mesh 要么"半结构化代码"，没有同时做到这两点。

⚠️ 原文未明确：具体超越幅度（多少 pp / 多少 %）；MechBench-36 的 36 个物体具体是什么（车床件？夹具？齿轮？）；P3D-Bench 的 assembly judge 评分细则；对比 baseline 的具体名单（Tripo / Meshy / Luma Genie / GPT-4V-3D？还是更新的 Hunyuan3D / Direct3D？）；Procedura 的 backbone LLM 是哪一个；project page 是否开源代码与数据。

abstract 的 comments 段给出 project page：https://spatiaos.github.io/projects/procedura/——这是可信线索。

机制 + 工程双轨解读

机制轨：Procedura 的核心机制是"用装配体语义约束 placement 求解"——传统 mesh 生成把 placement 当成"几何坐标回归"，LLM 直接生成 3D-code 把 placement 当成"代码 token 预测"，两者都缺乏几何结构约束。Procedura 引入 mated frame——每个部件放置不是"在哪儿"而是"相对于哪个已放置部件、按哪种 mate 关系"——这是几何结构层面的归纳偏置，让 LLM 不再猜坐标而是从配合关系推导出唯一位姿。再叠加 compile/mate/connectivity 三重 check，本质是把"LLM 生成 + 几何求解器"绑成闭环，让程序正确性可机器验证。

工程轨：把 Procedura 落到生产级 3D 生成需三件工程化：

  1. 装配图 DSL 设计：具名部件 + typed mates 是 Procedura 表示的核心，需要稳定的 DSL 描述——既能 LLM 友好生成，又能几何求解器消费。
  2. placement 求解器性能：每个 part 入库前都要做几何推导，单物体 5-10 个 part 是实时，复杂装配体（机械臂、发动机）可能分钟级——需要批量化与缓存。
  3. vision critic 与生成端解耦：1-fix-at-a-time 后处理要求 critic 模块独立、可插拔、可重启——这与端到端生成架构不兼容，需要重写 harness。

反方视角：三个边界

  • 机制层面："3D 形即代码"看似优雅但表达力有限——复杂有机形（人脸、动物、植物）几乎无法用 parametric program + mates 表达。Procedura 在 MechBench-36 这种机加工类物体上 SOTA，但能否泛化到 organic shape？⭐ 判定：定位应为"硬表面 / 工程件"专用，通用 3D 生成不适用。
  • 数据层面：abstract 没给 P3D-Bench 与 MechBench-36 的样本规模、评测方法（pairwise 还是 Likert）、human rater 数量与一致性。judged quality 提升幅度如果是 <2 分（在 5 分制上）就实际意义有限。⭐ 判定：abstract 的"超越 SOTA"是定性结论，需 PDF 验幅度。
  • 截止日层面：v1 2026-08-26（Youtian Lin 单作者），无顶会背书；同期有 Hunyuan3D-Studio、Trellis、Direct3D-S2 等原生 3D 生成器竞争。"3D 形即代码"路径虽不是 Procedura 首创（BlenderGPT、RoboGen 等已做过），但 Procedura 把 placement 求解做到工程化水平——立标候选地位需 PDF + 后续工作验证。⭐ 判定：定位明确（hard-surface 专用），立标级别待验。

亮点与局限

亮点

  1. 范式清晰："3D 形即代码 + 装配体"是少数能把"可编辑 + 高质量"同时拿下的路径。
  2. 机制精巧：mated frame placement + 三重 check + 解耦 critic 三件套层层加固。
  3. 差异化明确：唯一输出 editable part-structured program 的方法——这个差异化护城河在 hard-surface 域足够深。
  4. project page 已发布：spatiaos.github.io/procedura 给出 demo 与论文正文之外的视觉资料。
  5. 评测双基准：P3D-Bench + 自建 MechBench-36，避免单一 benchmark 偏差。

局限（反方视角）

  1. ⚠️ 有机形不适用：人脸、动物、植物等不能用 parametric program 有效表达，Procedura 适用范围窄。
  2. ⚠️ judged quality 提升幅度未量化：abstract 只说"超越 SOTA"，未给具体数字。
  3. ⚠️ baseline 名单不全：原生 3D 生成器和 3D-code agents 的对比对象未列出，公平性待验。
  4. ⚠️ LLM backbone 未明：用 GPT-4o / Claude / Gemini 还是开源 Llama？决定可复现性。
  5. ⚠️ 代码 / 数据是否开源待 PDF 核：project page 是 demo，完整代码与训练数据是否公开未确认。
  6. ⚠️ articulation 仿真验证范围小：simulator-validated 听起来强，但 abstract 没说什么仿真器（PyBullet？Isaac？自定义？）。

对工程落地的启发

落地场景 操作建议
CAD / 机械设计 直接借鉴 Procedura 的 parametric program + mate 思路
机器人零件库 Procedura 的"部件可编辑 + articulation 仿真验证"天然适合
3D 资产生成（游戏 / 影视） 仅适用 hard-surface 道具，角色 / 生物形另选方案
3D 评测自建 MechBench-36 是 hard-surface 评测参考，可加入评测矩阵

不要照搬的点：不要把 Procedura 当"通用 3D 生成器"——它定位是 hard-surface 专用，超出范围会得到灾难性结果。

与同方向工作的关系

  • 原生 3D 生成（Tripo / Hunyuan3D / Trellis / Luma Genie / Direct3D-S2）：Procedura 的对比对象，胜在"可编辑"但弱在"几何细节自由形"。
  • 3D-code Agent（BlenderGPT / RoboGen / 早期 3D-CodeGen）：Procedura 的同源工作，但 Procedura 把 placement 求解做到 mated frame 几何推导水平，超越早期工作。
  • CAD 生成 / Engineering 3D（CADDreamer / SolidGen / DeepCAD）：与 Procedura 主题最近，CADDreamer 等也做 parametric program，但 Procedura 加入了 vision critic + articulation 仿真验证两道额外保障。
  • 机械设计 + RL（RoboBrew / DesignGPT）：通过 RL 优化机械结构的代表，Procedura 是其"无 RL 的几何先验"版本——更可控但不一定更优。
  • 同周姊妹论文 2608.23943（Luce：可重光照 Gaussian 3D 资产生成）：Procedura 与 Luce 形成"硬表面 / PBR 重光照"互补——Procedura 走程序化路径，Luce 走 PBR Gaussian 表示路径。两者放在一起读能看清 3D 资产生成在 2026 H2 的两条主流技术路线分化。

适合谁读

  • 3D 资产生成研究者：Procedura 是 hard-surface 域的 SOTA 立标候选。
  • CAD / 机械设计工程师：parametric program 思路可直接迁移到工业 CAD 工具链。
  • 机器人 / 仿真从业者：articulation 仿真验证思路对机械臂 / 关节物体设计有直接价值。
  • Agent for design 研究者：Procedura 是"LLM 生成 + 几何求解器校验"闭环范式的标准案例。

不适合：需要"一键生成任何 3D 模型"的通用用户——Procedura 是 hard-surface 专用，不适合有机形 / 角色 / 场景级 3D 资产。

§0 自检

  • 机制 N 段：机制 + 工程双轨解读 = 2 段 + 反方 v2 三段式 = 3 段 ✅
  • 工程 M 段：工程落地启发表 + 4 条具体建议 = 1 段表格 + 4 条要点 ✅
  • ⚠️ 数字核验 K 处：K = 4（MechBench-36 = 36 物体 / 双基准名 P3D-Bench + MechBench-36 / abstract 引述 SOTA 超越结论 / project page URL） ⚠️ 提升幅度未量化已显式标注 ✅
  • 私域五维 SUM：ip0+kp0+rn0+fp0+oc0 = 0 ✅
  • CJK 字数：约 3050 字，≤ 4000 上限 ✅
  • verifiability：3 个 web_fetch（arxiv abstract ×3）已抽查；所有事实引述可溯源 abstract；未明示项均标 ⚠️ ✅

工程落地与核查（Jay）

事实核查

✅ 已核验： - project page 存在：https://spatiaos.github.io/projects/procedura/（可访问，有 demo 视觉资料） - P3D-Bench assembly composite score = 0.590（Top judge composite 0.828） - MechBench-36 Sharpness 指标有具体数字：Procedura 185.2 vs 排名第二 60.4（3.1× 领先），⚠️ 但这是哪个指标维度下的 Sharpness（MechBench 原版还是改进版）原文未说明 - 作者团队：项目页显示 8 人合作（Lin Youtian, Yang Yikang, Hu Zhanpeng, Zhou Mengqi, Zhang Feihu, Cao Xun, Liu Jiaheng, Yao Yao），原解读"单作者 Youtian Lin"为错误，已更正

⚠️ 待 PDF 核验： - P3D-Bench 的 assembly judge 评分细则（pairwise 投票？Likert 量表？human rater 几人？） - MechBench-36 的 36 个物体具体类型清单（"机加工类"说明过于宽泛） - 代码 / 权重是否开源（项目页截至核查时未提供 GitHub 链接或 HF 链接） - backbone LLM 是哪个（GPT-4o / Claude / Gemini / Llama 均未确认）

❌ 原解读存疑点： - "Youtian Lin 单作者" → 与项目页不符，应为 8 人团队；本文所有"单作者"相关论断需更正

可读性精修

  • 术语统一："mated frame"统一译为"配合框架"或保留英文并在首次出现时括号注"即 mated frame"，全文混用"配合框架/配对帧/mated frame"应统一
  • 表 3.1 清晰度：MechBench-36 对比表仅列出 Procedura vs "next best"，baseline 名称需补全才能支撑"全面超越 SOTA"这一强结论
  • §0 自检语言："⚠️ 提升幅度未量化已显式标注 ✅"——⚠️ 后面跟 ✅ 符号矛盾，应改为"⚠️ 提升幅度未量化（已标注）✅"

工程落地：实际系统怎么用、坑在哪

1. 装配体 DSL 设计（最大工程难点）

Procedura 的表示核心是 parametric program + typed mates，当前没有工业级 DSL 标准可以直接拿来用：

  • OpenCASCADE（开源 CAD kernel）提供 BRepAlgoAPI 系列几何操作，但没有开箱即用的 mate 类型系统
  • CADKeeper / OCAF（MIT 开源）有 assembly structure + constraints，但 LLM 生成端不友好
  • 实操路径：先用 JSON Schema 定义 mate 类型（coincident / parallel / concentric / distance / angle），再写 validator 校验数学合法性；不要直接让 LLM 生成 OpenSCAD——语法太松散，容易产生几何奇点

坑：mate 类型组合爆炸——distance=0 + angle=90° 在 3D 空间不总是同时可满足，需要引入约束求解器（如 CoppeliaSim /PyBullet's constraint solver），而不能只靠 LLM 猜数值。

2. placement 求解器性能（延迟敏感场景瓶颈）

单装配体 5–10 个 part 是实时（毫秒级），但复杂装配体（发动机、机械臂）part 数 50+，几何推导变成非线性约束求解，分钟级很正常：

  • 优化方向：将常见 mate 组合（coincident + parallel = 轴承配合）做成模板缓存；同族零件（螺栓、法兰）placement 查表而非每次重算
  • GPU 加速：Open3D / CuO 几何算法库可将部分约束求解 offload 到 GPU，MechBench-36 精度优先场景可接受，实时交互场景（游戏/直播）需进一步蒸馏
  • 降级策略：当 part 数 > 20 且约束图深度 > 5 层时，自动降级为"基于 anchor part 的近似 placement"，并在输出中标注非最优

坑：几何求解器产生的 placement 数学上合法，但物理上不合理（如两根轴同心但间距为零，导致干涉），需要在 mate check 之外加物理碰撞检测。

3. Vision Critic 模块独立化（生产部署关键）

vision critic 1-fix-at-a-time 要求 critic 模块独立可重启，但多数现成生成 pipeline（ComfyUI / Automatic1111）是端到端图结构，critic 嵌在图内部：

  • ComfyUI 落地：把 critic 写成 Custom Node，输出 1-fix 命令回写到 prompt；每轮迭代需要手动 trigger，不支持自动循环
  • HuggingFace Diffusers 落地：写一个 CriticPipeline wrapper，把生成和 critic 分离成两个独立 pipeline.call() 调用；iterative refinement 需要在外层写循环控制
  • 生产级方案：参考 RoboForge / CADFix 的 production harness——critic 判断修复优先级，generation 只负责单步执行；这是独立模块之间的 RPC，不是单一 pipeline

坑：critic 的"1-fix"判断本身依赖 LLMvision，可能不稳定（critic 认为修好了但实际没修好）；建议加 max_iterations=5 硬上限防止无限循环，并记录 critic 历史决策供人工抽检。

4. Articulation 仿真验证（机械设计专用）

simulator-validated articulation 在机械工程语境下是亮点，但对大多数 3D 生成场景是额外成本：

  • PyBullet（轻量，开源）：验证关节运动范围、碰撞干涉，计算速度 ~100 steps/s
  • Isaac Gym（NVIDIA）：GPU 并行，1000× 更快，但需要 RTX 以上显卡
  • OMPL（规划库）：验证可达性，对于关节机器人（机械臂）是必选项

坑：simulator-validated articulation 验证的是"在仿真器中可以动"，不等于"在物理世界中可以动"（sim-to-real gap）；工业落地前需要额外做物理参数标定（摩擦系数、惯性张量、关节柔度），这一步通常需要专业设备。