BimAnt

three.js 成了 AI 生成 3D 的默认输出：四条路，验收还缺一把尺

admin -

最近两周，"用大模型直接生成 3D 场景"这条线上集中出了几件东西：一个 4B 的开源模型（Hugging Face 上 31.9 万次下载）、Google 把 three.js 当编译目标、Blender 侧出现可训练的 bpy 编辑框架、AR 侧用 GPT-5.2 现场生成 pixel shader。

它们的共同点是：输出的是代码，不是模型文件。几何、材质、灯光全部由代码构造，没有一个外部资产。

这也是为什么值得单独拎出来看——代码意味着可 diff、可回归、可进 CI；但也意味着你需要一把尺子回答"改成什么样算对"，而那把尺子刚刚才有人开始造。

下面按四条路径拆。

一、先说清"全用代码"到底省了什么

用生成模型（Trellis、Meshy 那一类）出 3D，产物是一个网格文件：好看，但改起来只能重新生成。

用代码出 3D，产物是一段程序：参数化、可读、可版本控制。同一句话让模型改"把灯换成暖色、桌子往左 20 厘米"，它改的是几行参数，而不是重新采样一遍网格。

代价也很明确：代码能跑通，不代表画面是对的。这和写软件是同一类问题——所以这一轮的进展都集中在"怎么验收"上。

二、路径 A：three.js 当场景语言

这是目前最主流的一条，因为模型本来就最会写前端代码。

Qwen3.5-4B-3D-Coder（CCORE 的独立微调，基于 Qwen3.5-4B，Apache 2.0）是这个方向的标志性结果：输出是一个 HTML 文件，引入 three.js、用程序化代码搭出场景，浏览器打开就能转。它在 HF 上有 31.9 万次下载、967 个赞；配套数据集 ThreeJS-3D-Scenes 也公开了。

真正要看的是它的规模：4B。也就是说这条流水线不需要前沿大模型，Q4/Q8 的 GGUF 可以在本地跑；模型卡还提供了可选的视觉投影（644 MiB），挂上之后能照着参考图生成体素场景。

模型卡里的输入参考图。配上"create this scene using voxels 3d"这句提示，4B 模型生成了封面那张体素小岛——几何、配色、陈设全是代码算出来的。

同一作者还有 GLB 变体（4.3 万下载）：把 three.js 场景导出成 GLB 交给 Godot。这一步很关键——它把"代码"重新折回了资产格式，代价是也丢掉了代码的可编辑性。

Google 走的是另一头：Three-Live 不信任 LLM 写的代码直接进 webview，而是把 three.js 的一个声明式子集当 DSL，在沙箱里执行、2–5 毫秒序列化成 GLB / USDZ。它的立论是"代码不可信，所以把代码当编译器的输入"。

这条路径我们站内已经拆过：Three-Live：把 AI 写的 three.js 变成可交付的 GLB。

三、路径 B：Blender 的 bpy

three.js 解决"网页里能看"，Blender 解决"能交付、能渲染、能进流水线"。

3 天前挂出来的 BlenderFORGE（arXiv 2611.10768）是目前最完整的一份：让开放权重的多模态模型用 bpy 代码直接编辑显式场景，并且把任务做成状态可验证的四类：

  • 物体摆放（object placement）
  • 形态键编辑（shape-key editing）
  • 灯光调整（lighting adjustment）
  • 材质修改（material modification）

它的出发点很直接：现有系统大多依赖闭源模型 API，而且缺少确定性、状态可验证的执行环境，所以训不出来也评不出来。

论文的框架图（arXiv 2611.10768）。注意中间那个 Blender Sandbox：两个工具——代码执行器和预览渲染器——模型每改一次都要"跑一遍、看一眼、再判断"。这不是一次性生成，是迭代编辑。

这条路径的工程做法在社区里也跑得通：bpy + 后台命令行 + MCP，agent 能建场景、渲染、截图、再改。我们那篇《Claude Code 改 Blender 场景：靠截图自纠》记的就是这条路。

四、路径 C：连几何都不生成，只写 shader

如果只需要"改变看到的样子"（而不是改变模型），最省的做法是只生成着色器。

ShadAR（arXiv 2610.19998，10-15）是这条路上最硬的：用户说一句"把所有的人都变模糊"，它用 GPT-5.2 解析意图、YOLOv26 在画面里定位目标、然后生成一个 pixel shader，实时注入到 AR 的透传画面里。

它证明的是：光照与后处理这一层，代码生成已经能进实时管线——不是离线渲染一张图，是每帧都在跑。工程侧也有同样的路子：Claude Code 加一个 shader 技能，能把一段 AI 视频翻成可交互的 GLSL demo；也有人拿 Claude 与 GLM 从零写一整套 Minecraft shader pack 做对比。

五、路径 D：工业场景要的是尺寸，不是气氛

到了工业，问题立刻变形：要精确的尺寸与定位。

SceneGenAgent（ACL 2025）就是为这个做的：用 C# 代码生成工业场景。它把难点定在"空间布局的规划"上——不是画得像，而是位置、间距、朝向都得对，所以走的是"结构化规划 → 生成代码 → 验证"的闭环。

这条对我们做产线/工厂的人最有参考价值：工业场景的"对"，是可以写成约束的。

六、四条路共同的缺口：改成什么样算对

上面四条都在解决"怎么生成"，但真正卡住落地的是验收。

3 天前 EMNLP 2026 有一篇直接点破这件事：《Apples on the Table?》 指出，现有的文生 3D 场景评测要么只比"整体像不像"，要么完全不验证空间推理——没人管"X 必须以 Y 的方式出现在场景里"这种细粒度约束。他们做了 LEGO 基准，专门做细粒度约束校验。

BlenderFORGE 那篇的失败案例，正好是这类约束没被满足时的样子：

论文的失败分析（arXiv 2611.10768）。(A) 模型判断"床头柜在床的左边"，于是往左上挪，结果越挪越远；(B) 模型算错了 90° 与 180°，把扶手椅多转了一倍。红字是失效的推理句——代码执行成功了，画面是错的。

这张图是全文最值得记的一页："能生成"和"生成对了"之间，隔着的不是模型能力，是验证。

七、我们的整理：四条路怎么选

路径 产物 可编辑 确定性 验收方式 适合谁
A. three.js 单页 HTML / GLB ✅ 强（代码可 diff） ✅（同一段代码永远出同一画面） 截图比对 + 约束检查 Web/XR、要嵌进产品、要 CI
B. bpy .blend + 渲染 ✅ 强 ✅ 状态校验（摆放/灯光/材质可量化） 出图、出视频、要进 DCC 流水线
C. shader GLSL / pixel shader ⚠️ 中（只看像素，不看几何） ✅ 实时 逐帧视觉回归 后处理、AR 滤镜、风格化
D. C# / 参数化 工业场景代码 ✅ 强 ✅ 尺寸与布局约束求解 产线、工厂、数字孪生

三条判据，可以拿去问任何一条流水线：

  1. 产物是代码还是文件？ 是文件，改一次要重生成一次；是代码，改一个字就够。这条决定了它能不能进你的版本管理。
  2. 验收能不能自动化？ 能写成约束（位置、尺寸、材质、灯光参数），就能进 CI；只能"看着还行"，就只能当灵感工具。
  3. 它知不知道自己在改什么？ 迭代编辑（BlenderFORGE 那种"跑一遍、看一眼"）比一次性生成的可靠性高一个量级——因为每次编辑都有反馈。

八、边界

  • 我们没有跑本地验证：文中的下载量、参数、任务定义都取自各自原文（HF 模型卡 / arXiv / ACL / Google 博客），不是我们的实测。想看实测，得等有人把 4B 的 GGUF 跑一遍。
  • 四条路不是互斥的：Three-Live 就是"路径 A + 编译"，BlenderFORGE 是"路径 B + 强化学习"，ShadAR 是"路径 C + 目标检测"。真实产品的形态是组合。
  • 规模都还小：4B 模型、四类编辑任务、单场景演示。没有一条做过"整栋楼"或"整条产线"级别的规模测试。
  • 图片来自论文与模型卡（Apache 2.0 / 论文插图），已按原图注明出处。

来源