SceneCode：面向含铰接物体的可编辑室内场景的可执行世界程序

原文链接：https://arxiv.org/pdf/2605.19587
项目链接：https://scene-code.github.io

图1：SCENECODE 整体框架。给定自然语言场景提示，本框架将其编译为代码驱动、可执行的交互式室内场景。

摘要

室内场景合成是具身智能、机器人操作与基于仿真的策略评估的基础支撑。一个实用的场景不仅需要描述环境的视觉外观，还需要明确物体的结构组成。然而，现有生成流程通常将生成结果表示为静态网格，仅能从整理好的资产库中继承铰接属性，这限制了物体层面的可控性，也无法按需生成全新的可交互资产。

为填补这一空白，本文将具备物理交互能力的室内场景合成建模为程序化世界生成问题，提出 SceneCode 框架：该框架将自然语言提示编译为可执行、代码驱动的室内世界，而非一组不透明的网格。框架首先通过房间级智能体主干将输入提示转化为结构化的房屋布局，并经由“规划器-设计器-评估器”循环输出逐个物体的资产请求（AssetRequest）。每个请求会被分配至五种代码生成策略之一，转换为逐部件生成的 Blender Python 程序，并通过执行引导的修复-精化循环完成校验。最终生成的程序被编译为仿真就绪资产，并导出为 SDF 格式以用于物理仿真。

持久化场景状态注册表将物体请求、可执行程序、渲染几何与仿真资产关联起来，使场景组装成为可追溯、支持局部编辑的世界构建过程。本文在场景级合成、物体级资产质量、人工评测与下游机器人交互四个维度对 SceneCode 进行评估。结果表明，可执行世界程序提升了室内场景生成的提示忠实度，生成的资产网格结构更清晰，且附带可直接加载至仿真器的铰接元数据。项目主页：https://scene-code.github.io/

1 引言

室内场景合成是具身智能[10, 25]、机器人操作[18, 19]与基于仿真的策略评估[29, 12]的核心基础。通过生成多样化的室内环境，这类系统能够提供可扩展的虚拟世界，用于训练智能体、测试操作技能、采集合成交互数据，而无需昂贵的人工建模[4, 24]。

因此，室内场景合成的目标不仅是生成由摆放合理的物体组成的视觉可信房间。对具身智能体而言，室内场景必须具备物理结构与交互机制。换言之，一个实用的生成场景不仅要说明环境“看起来是什么样”，还要明确物体的结构组成、运动方式，以及智能体如何对其施加物理作用。

现有方法从不同方向推进了这一目标。基于检索与大语言模型引导的系统可利用大型资产库构建多样化环境[6, 39]；以布局为核心的方法通过优化提升空间合理性[21, 14, 28]；近期的智能体系统则能够生成具备密集物体分布与物理属性的仿真就绪环境[22, 23]。尽管如此，绝大多数生成流程仍将生成内容表示为静态网格。即便场景中存在铰接物体，其部件结构与关节语义通常也继承自整理好的数据集[38, 36]，而非作为场景表示的一部分生成。

也就是说，可交互物体的选择受到限制：这类物体无法按需定制，且面临“数据集缺失即无法生成”的问题。这限制了物体层面的可控性，也制约了新型可交互资产的规模化生成。

为应对这一挑战，本文将具备物理交互能力的室内场景合成建模为程序化世界生成问题，提出 SceneCode：该框架以可执行程序的形式生成室内场景，而非静态视觉资产。如图1所示，SceneCode 在多个层级上呈现生成的场景：可渲染的房间、持久化的场景状态，以及具备明确部件与交互机制的物体级程序。

代码天然适合作为可交互场景的表示形式，因为它能够以统一的形式显式定义物体几何、部件分解、材质分配、物理属性与运动机制。这一表示形式也与视觉语言模型（VLM）[20, 15, 32]从自然语言描述生成结构化程序的新兴能力高度契合[1, 13, 26]。由此，生成的三维物体不仅是视觉可信的家具，更是具备可控状态的结构化物体。

通过将交互作为生成程序的固有组成部分，SceneCode 实现了可交互物体的按需生成，而非仅能从整理好的铰接资产库中选取，或通过繁琐的人工建模制作，为具备物理依据的室内场景合成奠定了基础。

本文将 SceneCode 实现为一套智能体式的文本到场景生成管线，可将自然语言提示编译为可执行的室内世界。具体而言，给定输入提示，系统首先推导房间级规划，包括房间几何结构、语义描述、物体需求与空间约束。SceneCode 并非通过从固定库中选取资产或生成不透明网格来满足这些物体需求，而是将每个需求转化为结构化的物体规格，并调用基于视觉语言模型的程序综合器生成 Blender Python 代码[24, 27, 8]。

生成的程序从几何基元出发逐部件构建物体，为每个语义部件分配材质与UV坐标，并在对应位置附加物理属性、碰撞代理与移动关节（棱柱关节或旋转关节）。执行完成后，每个物体程序都会被注册到持久化的 house_state 文件中，该文件记录布局、房间几何、物体变换、支撑面、几何路径、包围盒与交互元数据。最终输出的场景附带物理标注与可交互物体，且保持可编辑性与局部重生成能力，支持约束修改与下游仿真中的物体级交互。

本文在 30 条自然语言提示上对 SceneCode 进行评估，涵盖 6 类室内场景。场景级对比基线包括 SceneSmith[22]、HSM[23] 与 LayoutVLM[28]，资产级对比基线为 SAM 3D Objects[33]。实验结果显示，在所有场景级基线中，SceneCode 的语义保真度最优，物体数量与属性得分最高，同时在可通行性、碰撞与地面贴合度指标上表现更优。人工评测表明，在配对比较组中，SceneCode 的提示忠实度均高于各基线。在物体层面，SceneCode 生成的资产可用性优于 SAM 3D Objects[33]。最后，MuJoCo[34] 演示验证了生成的铰接资产保留了独立可动连杆与可执行关节，可支持基于接触的机器人交互。

综上，本文的核心贡献分为三点：

• 提出 SceneCode，一种用于室内场景合成的可执行代码表示，以代码格式显式刻画布局与物体属性。
• 提出一种由视觉语言模型驱动的物体合成流程，将家居物体生成为显式程序，实现可交互资产的按需生成，而非仅能从固定的铰接物体数据集中选取。
• 在场景级合成、物体级资产质量、人工评测与机器人交互四个维度对 SceneCode 进行全面评估，验证了其生成高提示忠实度场景、提供交互就绪铰接物体资产的能力。

2 相关工作

室内场景合成。 基于学习的场景合成器通过自回归Transformer或去噪扩散模型，从带标注的房间数据集中建模物体布局分布[21, 31]。基于大语言模型与检索的管线则通过查询已整理的三维资产库填充房间：代表性工作包括Holodeck[39]、LayoutVLM[28]、HSM[23]，以及智能体式的SceneSmith[22]——后者融合数据集检索与图像到三维生成技术，生成仿真就绪场景；附录A中综述了更多基于大语言模型/检索的系统与程序化生成系统。与之不同，SceneCode 将物体本身生成为可执行程序，摆脱了对固定资产库的依赖，并将每个物体的部件与关节显式纳入场景表示。

代码驱动与程序化三维生成。 程序为三维内容提供了紧凑、可编辑的表示形式。Infinigen[24]利用手写程序化规则生成照片级真实感的世界；ShapeAssembly[9]学习形状上的部件程序先验；近期的视觉语言模型驱动系统（如SceneCraft[8]与MeshCoder[3]）可从自然语言或点云合成Blender Python代码；附录A中讨论了更多代码生成系统。这些工作大多针对单物体建模或场景级视觉布局，对下游物理交互的支持有限。SceneCode 通过带路由、可验证的物体规划驱动逐部件Blender程序生成，并编译为注册在持久化场景状态中的URDF/SDF资产，将基于程序的生成拓展至可交互室内场景。

3 方法

给定自然语言场景提示，SceneCode 生成可渲染场景，同时输出场景状态元数据与仿真就绪资产文件。本系统将室内场景合成问题拆解为两个耦合的层级：房间级智能体决定需要哪些物体、放置在何处；代码驱动的资产生成器决定每个物体的构建方式，并编译为可渲染与仿真就绪的产物。

图2展示了完整管线的整体框架。3.1节简要介绍提供上下文物体请求的房间级主干，3.2节重点阐述可执行物体程序的构建过程，3.3节介绍仿真就绪资产编译，3.4节介绍场景组装与状态序列化。

图2：SCENECODE 整体框架：从房间级规划到代码驱动物体生成、仿真就绪编译，再到场景状态注册。

3.1 房间级智能体场景主干

房间级主干将场景提示转化为一组逐房间的物体规格，驱动后续的程序合成。具体而言，它生成结构化的房屋布局 $H$，以及有序的物体请求序列 { A ˙ ( t ) } t = 1 T \{\dot{A}^{(t)}\}_{t=1}^{T} {A˙(t)}t=1T​。在每个房间内，请求按四个语义阶段输出：大型家具、壁挂式物体、顶置式物体与可操作物品。

每个阶段由“规划器-设计器-评估器”循环驱动：规划器选择下一个放置任务，设计器调用工具创建或修改物体，评估器从渲染视图、场景状态信息与几何一致性校验三个维度评估中间场景。第 $t$ 阶段的输出并非最终资产，而是一条资产请求
$$\mathcal{A}=(c,\tau ,d,\sigma ,T,\rho ),$$
其中 $c$ 为物体类别，$\tau$ 为文本描述，$d\in {\mathbb{R}}^3$ 为目标尺寸，$\sigma$ 为风格上下文，$T\in SE(3)$ 为放置变换，$\rho$ 为支撑关系。序列 { A ( t ) } t = 1 T \{A^{(t)}\}_{t=1}^{T} {A(t)}t=1T​ 将作为约定输入物体级程序合成阶段。

3.2 代码驱动的物体生成

本节将每个资产请求转化为可执行的Blender程序，输出经过部件分解、可渲染的网格。管线分为五步：将请求分配至对应构建策略、提升为结构化物体规划、校验规划、合成逐部件Blender程序，以及通过执行验证生成的代码。

资产请求与策略路由

直接提示单个视觉语言模型根据 $\mathcal{A}$ 输出Blender脚本，在多样室内物体上可靠性不足——不同物体族需要不同的构建先验：壁挂艺术需要带图像材质的薄画布，而铰接物体必须保留可移动部件，以供后续关节编译使用。

因此，SceneCode 引入路由器 $r:A\mapsto s$，将每个请求分配至五种基于视觉语言模型的代码生成策略之一（WALLART、STATICFURN、SIMPLEMANIP、STRUCTMANIP、ARTIC），或分配至固定代码模板THINCOVER（用于地毯、地垫等薄覆盖物，无需自由式视觉语言模型合成）。五种基于视觉语言模型的策略覆盖了室内物体的主要构建先验：

• WALLART：海报、装裱艺术品及其他印刷类壁挂物体。
• STATICFURN：无功能性运动部件的大型刚性家具，如床、书架、沙发。
• SIMPLEMANIP：结构简单、以单一形状为主的刚性物体，如碗、盘子。
• STRUCTMANIP：包含多个可见部件但无铰接的刚性物体，如马克杯、手机。
• ARTIC：带功能性运动部件的物体，如橱柜、冰箱，后续将编译为连杆-关节结构。

每种基于视觉语言模型的路由都搭配专用的构建提示，编码对称性、重复结构与曲线构建等几何感知编码约束；例如，曲面形状由显式采样点与解析基元构建，而非无约束的贝塞尔曲线。完整提示列表见附录B。

基于参考条件的物体规划构建

除THINCOVER外，对所有策略，$\mathcal{A}$ 首先被提升为结构化的物体规划 $\mathcal{P}$，以降低代码合成的歧义性。系统根据描述-风格对 $(\tau ,\sigma )$ 生成参考图像 $I_{ref}$，物体规划器接收 $(\mathcal{A},I_{ref})$ 并输出
$$\mathcal{P}={\left\{\left(p_i,s_i,T_i^{loc},m_i,{\pi }_i,{\mu }_i\right)\right\}}_{i=1}^N,$$
其中 $p_i$ 为语义部件， s i ∈ { BOX, CYL, SPH, TORUS, CURVE } s_i \in \{\text{BOX, CYL, SPH, TORUS, CURVE}\} si​∈{BOX, CYL, SPH, TORUS, CURVE} 为其基元类型，$T_i^{loc}$ 为其在物体局部坐标系下的位姿，$m_i$ 为其材质，${\pi }_i$ 为其对称性标签， μ i ∈ { 0 , 1 } \mu_{i} \in \{0,1\} μi​∈{0,1} 为可移动标记。对于分配至ARTIC的请求，${\mu }_i=1$ 的部件（如门、抽屉）后续将被编译为关节模式。

物体规划校验

自由生成的规划可能遗漏功能部件、提出不合理的部件尺寸，或部件摆放与物体主体不一致，因此在代码合成前应用校验器 $V:P\to P^{\ast }$。实际实现中，校验器结合轻量的基于规则的验证与基于大语言模型的修正步骤，面向四个目标：

• 部件完整性：移除冗余组件，补充与请求类别 $c$ 相符的缺失功能部件。
• 尺寸合理性：修正不合理的部件尺寸 $s_i$，使部件与请求类别、目标尺寸 $d$ 保持一致。
• 空间一致性：修正局部位姿 { T i l o c } \{T_{i}^{loc}\} {Tiloc​}，使部件遵循物体局部坐标系，与主体连贯整合。
• 可动部件独立性：${\mu }_i=1$ 的部件保持为可独立寻址的组件，而非与父部件融合，这是3.3节下游关节编译的前提。

校验后的规划 $P^{\ast }$ 将作为后续代码生成必须遵循的约定。

逐部件Blender程序合成

给定 $(P^{\ast },I_{ref})$，部件构造器为每个部件合成一段Blender Python程序 ${\pi }_i$，返回物体局部坐标系下基于基元的网格 $M_i$ 以及程序化材质。随后，组合脚本通过合并部件网格组装物体网格 $M$，并将每个 $M_i$ 保留为独立命名的Blender对象，使可动与不可动组件保持语义可分解性，而非融合为单一不透明网格。完整的部件级代码列表见附录J。

执行引导的程序验证

每段 ${\pi }_i$ 都在无界面Blender中执行，并通过双预算循环进行验证，其中执行修复预算 $K_{exec}=3$，精化预算 $K_{ref}=2$：

1. 执行：运行 ${\pi }_i$ 以生成 $M_i$。
2. 修复：若执行失败，将回溯信息与出错代码一并返回合成器；每个部件最多允许 $K_{exec}$ 次修复尝试。
3. 精化：执行成功后，评估智能体检查组装后物体的渲染图像，判断是否满足请求的类别、结构与材质要求，触发最多 $K_{ref}$ 次精化迭代。

这种执行引导的循环提升了代码可靠性，避免无效资产进入场景级组装阶段。

3.3 仿真就绪资产编译

本阶段将生成的视觉物体转换为兼容仿真器的资产文件，将刚性物体打包为单刚体SDF，将铰接物体转换为带推断关节的连杆-关节结构。形式上，SceneCode 应用编译映射 $C$，连接视觉几何与物理交互。

对于刚性请求，$C:M\mapsto \text{SDF}$ 生成附带碰撞与惯性属性的单刚体资产。对于铰接请求，$C:(P^{\ast },M)\mapsto (J,\text{SDF})$ 额外返回关节模式 $J$——由视觉语言模型辅助的铰接编译器基于 $P^{\ast }$ 中 ${\mu }_i=1$ 的部件推断得到：对每个可动部件，编译器输出父连杆、关节类型（铰链对应REVOLUTE、滑动对应PRISMATIC），以及合理的关节原点、轴线与运动范围，覆盖室内两种主要机构类型。

为支持基于接触的交互，每个连杆 $\dot{z}$ 都被赋予近似物理属性：根据物体与部件级语义估计的质量 $m_i^{phy}$，由 $(M_i,m_i^{phy})$ 计算得到的惯性张量 $I_i$，以及由简化几何包络得到的碰撞代理 $C_i$。最终生成的资产导出为SDF文件，用于下游物理仿真。

3.4 场景组装与状态序列化

场景组装闭合了房间级规划与代码驱动物体生成的循环，确保每个物体的视觉网格、可执行程序与仿真产物通过共享标识符保持关联。

具体而言，每个生成的物体都作为场景对象注册到场景级注册表中，共享标识符id关联其所有内容（如请求、程序，铰接物体还包括关节模式）。放置操作包括：将 $M$ 缩放至目标尺寸 $d$，应用规划的变换 $T\in SE(3)$，并使物体与其支撑关系 $\rho$ 对齐。

共享id是场景组装可追溯、支持局部编辑的核心：渲染网格、可执行程序 { π i } \{\pi_{i}\} {πi​} 与仿真产物 $(J,\text{SDF})$ 均引用同一个物体实例，支持参数级编辑与局部重执行。

4 实验

4.1 实验设置

基线方法。 本文将 SceneCode 与三种最新的文本到场景基线方法进行对比：SceneSmith[22]、HSM[23] 和 LayoutVLM[28]。SceneSmith 是一套智能体式的仿真就绪场景生成系统，HSM 与 LayoutVLM 则代表了当前以布局和主题为核心的室内场景生成方法。这些基线共同覆盖了互补的场景合成策略，包括智能体场景构建、分层主题放置与视觉语言布局优化。

输入文本描述。 本文在从 SceneEval-100[30] 中选取的 30 条房间级提示上评估所有方法。提示集涵盖六类室内房间：卧室、客厅、餐厅、厨房、地下室与浴室，描述长度从简短的物体列表到详细的指令不等。完整提示列表见附录 C。

自动评估。 本文采用 SceneEval[30] 的场景级指标：CNT（物体数量）、ATR（物体属性）、OOR（物体间关系）、OAR（物体与建筑关系）、SUP（支撑）、ACC（可达性）、NAV（可通行性）、COL（碰撞）、OOB（越界）与 OPC（开口净空）。对于物体级评估，本文使用一组反映下游可用性的网格与材质级指标：材质槽数量（MAT）、PBR 通道覆盖率（PBR）、非流形边数量（NME）、总面数（FAC）、总顶点数（VTX）与 UV 岛数量（UVI）。详细的指标定义见附录 D。

用户研究。 本文开展了一项用户研究，共 9 名参与者，平均分为三组：A 组对比 SceneCode 与 SceneSmith，B 组对比 SceneCode 与 HSM，C 组对比 SceneCode 与 LayoutVLM。评估主要考察提示忠实度，即生成场景是否符合输入描述；更多偏好与真实度评分结果见附录 G。由于 SceneCode 在三组中均接受评估，而每条基线仅在对应组中被评估，本文报告组内差值 $\Delta =\overline{\text{SceneCode}}-\overline{\text{Baseline}}$，以保证跨评分者与提示子集的比较公平性。

图3：房间级定性对比。与基线相比，SceneCode 展现出更优的提示忠实度。更多示例见附录 I.1。

4.2 房间级场景合成

定性对比。 图 3 表明，SceneCode 渲染的场景与提示描述的氛围、物体集合与空间布局高度匹配。SceneSmith 能够生成合理的家具，但无法定制铰接物体。HSM 在每个主题子树内可生成局部连贯的放置，但由于其主题仅在独立子树内运作，“书桌朝向床”这类跨子树关系无法可靠实现。这一定性差距与表 1 报告的 CNT 和 ATR 指标优势一致。

表1：房间级定量结果。本文报告 30 条房间级提示的场景级 SceneEval[30] 指标（单位为%，均值旁以较小字体标注 95% 置信区间）。最后一列（∆PF）报告逐样本配对的提示忠实度差值（SceneCode − 基线），以 5 分制量表的百分比表示。↑表示数值越高越好，↓表示数值越低越好。每列最优结果以粗体标注。

定量总结。 SceneCode 是唯一同时在语义保真度（CNT、ATR）与物理可用性（NAV、COL、OOB）上领先的方法：其逐物体代码在构建时直接实现提示属性，而非通过检索网格进行近似；由此生成的清晰、贴合包围盒的几何结构，使放置器能够精确推理碰撞与地面贴合情况。

用户研究（最后一列）从人工评分角度提供了支撑证据：评分者认为 SceneCode 的提示忠实度优于所有基线，相较于 SceneSmith、HSM 与 LayoutVLM，$\Delta \text{PF}$ 分别为 +2.8%、+13.2% 与 +24.6%（5 分制）；且对于缺乏显式属性实现阶段的布局导向基线，差距进一步拉大。

关于 SceneCode 未领先的指标（OOR、OAR、SUP、ACC、OPC）、偏好损失率与真实度评分的逐指标数据与分析，将放在附录 F 中展开。总体而言，对物体进行编程而非检索或塑形，生成的场景同时具备高提示忠实度、物理可用性与结构连贯性。

4.3 物体级几何与 UV 质量

本文将 SceneCode 与图像到三维基线 SAM 3D Objects[33] 进行对比。为保证公平比较，两种方法在相同的物体请求集合上运行——这些请求由房间级智能体在 SceneEval-100 提示上生成，并使用相同的参考图像。本文采用 4.1 节介绍的六项网格与材质指标（MAT、PBR、NME、FAC、VTX、UVI）评估每个生成的资产；详细定义见附录 D.2。

表2：物体级定量结果。在房间级智能体针对 SceneEval-100 提示发出的同一组物体请求上，取平均得到的网格与材质级指标。↑表示数值越高越好，↓表示数值越低越好。最优结果以粗体标注。

网格与 UV 可用性。 表 2 显示，在所有衡量可编辑性与仿真导向可用性的指标上，SceneCode 均显著优于 SAM 3D Objects。差距最大的是 UV 组织：SceneCode 每个资产平均约有 22 个 UV 岛，约为 SAM 3D Objects（96 个）的 1/4.4，这意味着其 UV 参数化远更连贯，更利于下游纹理映射与编辑。

几何紧凑性同步提升：面数从 12036.57 降至 6013.64，顶点数从 7400 降至 4945，存储与渲染成本大致减半，同时仍能表达请求的物体。此外，SceneCode 每个资产平均有 1.5738 个材质槽，PBR 通道覆盖率为 0.6066，表明材质建模更完整。

拓扑结构也更清晰：SceneCode 平均生成 0 条非流形边，而图像到三维管线仍会生成带非流形伪影的资产，需要下游仿真器进行修复。这是逐部件基元程序的直接结果：每个部件拥有自己的网格、材质与 UV 布局，因此资产永远不会被扁平化为单一的不透水网格块。

图 4(a) 直观呈现了这一差距：SAM 3D Objects 生成的盆栽植物呈现碎片化 UV 图表，而 SceneCode 生成的对应资产则拥有少量、形状规则的大岛，且与物体的语义部件对齐。

图4：物体级定性对比。(a) SceneCode 与 SAM 3D Objects 代表性资产的网格与 UV 布局。(b) 代码级可编辑性：局部重执行单个物体程序并修改参数，可生成同一物体的不同变体。© 检索管线无法满足的、具备指定结构或材质的按需铰接物体。

代码级可编辑性。 将物体表示为程序的第二个优势是生成后仍可编辑。由于每个部件都由带显式命名参数的基元级 Blender Python 代码构建，因此可以局部修改单个属性并重执行，无需重新运行房间级智能体或重新生成参考图像。

图 4(b) 对此进行了说明：从单个盆栽植物程序出发，通过改变 arr_count（叶片实例数量）与 ring_count（每个叶片表面的角向与径向细分）等参数，可以生成同一物体的粗糙、中等与精细变体。这种结构化的参数级编辑难以从图像到三维网格中实现——后者的资产是一整块不透明的三角形集合，没有可寻址的语义手柄。

按需铰接物体。 最后，代码驱动资产消除了铰接物体的数据集瓶颈。基于检索的管线（包括最新仿真就绪场景生成器的铰接分支）只能返回已存在于整理好的铰接物体库中的物体，因此对于特殊功能结构（如带指定抽屉数量的橱柜）或特殊材质（如玻璃门橱柜）的请求，通常只能用最接近的可用资产近似。

图 4© 展示了两个此类请求——智能体指定了目标物体的功能结构或材质。由于 SceneCode 将每个请求编译为带显式可动部件的部件分解程序，它能够合成完全匹配请求的定制铰接资产，包括指定的部件数量与材质，而非将请求坍缩到数据集中碰巧可用的物体上。这一点将在附录 E 中详细阐述。

4.4 铰接与机器人交互

图 5 表明，由铰接物体程序生成的物体不仅视觉可信，还具备物理交互能力。由于可动组件被保留为独立连杆，并随关节元数据一同导出，生成的资产可加载到 MuJoCo[34] 中，并由机器人通过接触进行操作。这表明 SceneCode 生成的铰接物体适用于下游仿真与具身交互。

图5：生成的铰接资产的机器人交互演示。将 SceneCode 生成的铰接物体导入 MuJoCo 进行基于接触的机器人操作。铰接物体程序生成的可动部件保留为带编译关节的独立连杆，使机器人能够物理地打开或滑动它们。

5 结论

本文提出了 SceneCode，一套代码驱动的、面向具备物理交互能力的室内场景合成框架。通过将物体表示为可执行、具备部件感知的程序而非不透明网格，SceneCode 将视觉几何、语义结构、材质、铰接与仿真元数据耦合在统一的表示形式中。

结合房间级智能体规划器与执行引导的物体程序合成，该系统能够生成高提示忠实度的场景，且资产具备可编辑性与交互就绪特性。实验表明，该方法在语义保真度、物体级网格可用性、人工偏好与下游机器人交互方面均具备优势。

附录A 更多相关工作

其他室内场景合成系统。 除正文引用的代表性工作外，其他基于学习的合成器还包括 SceneFormer[35]；而更广泛的基于大语言模型与检索的管线通过查询整理好的三维资产库填充房间，包括 LayoutGPT[6]、AnyHome[7]、InstructScene[14] 与 Architect[37]。ProcTHOR[4] 等程序化系统借助手工规则提升环境多样性。这些系统在布局规划方式上各有不同，但普遍依赖检索得到的静态网格，而这正是本文代码驱动资产层所要消除的依赖。

其他代码驱动三维生成系统。 除正文引用的工作外，近期的视觉语言模型驱动代码生成系统还包括 3D-GPT[27] 与 BlenderLLM[5]，二者从自然语言合成 Blender Python 或领域特定代码，用于单物体建模或场景级视觉布局。

铰接物体生成。 具身智能中使用的铰接资产主要来自 PartNet[17]、PartNet-Mobility / SAPIEN[38] 等整理好的数据集，这些数据集支持操作学习[36]，但限制了下游可用的类别与关节配置。

越来越多的研究开始直接生成铰接物体：NAP[11] 与 CAGE[16] 学习部件图与关节参数的分布，URDFormer[2] 则从真实世界图像推断 URDF。NAP、CAGE、URDFormer 等方法聚焦于铰接物体先验或 URDF 推断，而 SceneCode 则着眼于生成完整的室内场景——其资产以可执行程序表示，并注册在持久化世界状态中。因此，本文的目标并非直接在铰接物体准确性上与这些方法对标，而是解决可交互室内环境的场景级整合与可执行表示问题。

附录B 代码驱动物体生成的路由专属提示设计

本附录详细介绍 3.2 节所述代码驱动物体生成模块使用的路由专属提示设计。尽管每个路由的物体都遵循相同的下游管线——资产请求路由、物体规划构建、物体规划校验、逐部件 Blender 程序合成、执行引导修复与资产打包，但不同的室内物体族适用于不同的几何构建先验。壁挂艺术最好表示为带纹理的薄画布；大型家具需要稳定的支撑面与重复的结构组件；简单可操作物体应避免不必要的部件分解；铰接物体则必须将可动部件保留为独立连杆，以供下游关节编译。

为在不拆分管线的前提下适配这些差异，本文采用了一小组专用提示配置。所有配置共享统一的物体规划模式与相同的“规划器-校验器-构造器”结构，但每个配置都在共享基础上补充了路由专属的构建先验，引导视觉语言模型生成可执行、几何可靠的 Blender Python 代码。本文实现中使用的提示特征汇总于表 3，生成策略与特征代码、目标物体类别的对应关系见表 4。

表3：路由专属代码生成配置使用的提示特征分类。所有路由共享基础物体规划结构，额外约束则提供对应物体族专属的构建先验。

表4：路由专属生成策略。每种策略使用专用的提示配置，同时共享相同的下游物体规划校验、逐部件代码合成、执行引导修复与资产打包管线。$J^{\ast }$ 表示结构化可操作物体提示保留了潜在可动子部件的独立性，但除非路由至铰接分支，否则物体仍被视为刚性资产。

B.1 路由策略与物体类别

资产路由器将每个房间级资产请求分配至五种生成策略之一。分配决策综合考虑请求的物体类别、文本描述、支撑关系、预期尺寸与功能可供性，并遵循固定的优先级顺序。

带功能性运动部件的请求（如门、抽屉、盖子、铰链、滑轨、旋转部件）优先分配至铰接分支，因为这些组件必须在几何导出前予以保留。印刷类壁挂物体分配至壁挂艺术分支。在其余刚性物体中，无功能性铰接的大型家具类物体分配至静态家具分支，而桌面或手持物体则根据预期的部件复杂度，分配至简单可操作物体或结构化可操作物体配置。

需要强调的是，路由并不会改变下游表示：每个生成资产仍由代码生成几何构建，并通过相同的打包阶段注册为场景对象。路由仅选择物体族专属的提示配置，为视觉语言模型的程序合成提供相应的几何与功能先验。

B.2 提示特征分类与针对性失效模式

表 3 中的路由专属特征，是为解决我们在使用单一通用提示引导视觉语言模型时观察到的反复出现的失效模式而引入的。通用提示经常生成视觉可信但几何脆弱的代码，尤其在对称操作、径向复制、凹结构、中空物体与带重复内部组件的物体上。例如，镜像操作可能错误地围绕每个部件的局部原点执行，而非预期的对称平面（由特征 A 解决）；当枢轴未显式置于旋转中心时，径向复制可能出现偏移（特征 B）；当需要精确圆弧或重复曲线元素时，自由形式贝塞尔曲线难以控制（特征 C）；对布尔切割得到的 N 边形面应用细分修改器，容易引入不稳定的拓扑与渲染伪影（特征 D）。

为提升鲁棒性，每个提示配置仅编码与其路由物体族相关的构建先验。静态家具与铰接家具配置强调部件分解、内部结构、重复组件与支撑面（特征 F、G）。简单可操作物体强调紧凑的几何程序，并明确避免过度分解（特征 L）。结构化可操作物体强调可见子部件，同时仍将物体打包为刚性资产（特征 $J^{\ast }$）。壁挂艺术提示强调画布构建、UV 映射与图像材质分配（特征 K）。铰接提示额外要求可动部件保持独立，以便下游编译为 URDF/SDF 连杆与关节（特征 J）。若干工程层面的规则——高风险几何的少样本演示（E）、标准化材质模板（H）、导出友好的 Blender 规范（I）、路由层级风格保留（M）——则为大多数配置所共享。

这些约束并非要取代执行时验证。相反，它们在代码生成前缩小视觉语言模型的搜索空间。生成的物体规划仍会在构建前经过校验，所得 Blender 程序会在无界面环境中执行，运行时出错时最多可进行三次修复尝试，随后对渲染输出进行最多两次评估驱动的精化迭代。

B.3 与铰接资产编译的关联

只要资产请求隐含功能性运动部件，铰接路由的优先级就高于刚性物体路由，因为这类组件必须在几何导出前予以保留。带抽屉的床头柜、带门的橱柜、带铰链盖的盒子，如果预期支持物理交互，就不能生成为单一融合网格。因此，铰接提示将可动组件标记为 is_movable=true 与 must_be_independent=true，禁止它们通过阵列或镜像操作合并，并记录关节编译所需的辅助信息。

逐部件代码生成后，铰接物体被转换为连杆-关节表示。每个可动部件都被分配父连杆、子连杆、关节类型、关节轴线、枢轴或原点，以及运动范围。本文目前支持用于铰链组件的旋转关节与用于滑动组件的棱柱关节。生成的铰接资产导出为 URDF 格式，并转换为 SDF 用于下游仿真。相比之下，除非路由器显式选择铰接分支，否则分配至简单可操作物体、结构化可操作物体、静态家具或壁挂艺术配置的物体均打包为刚性资产。

B.4 配置间的共享结构与风格保留

所有提示配置共享相同的高层“规划器-校验器-构造器”结构：规划器生成物体规划，校验器修正规划以保证完整性与几何合理性，构造器为各个部件合成 Blender Python 程序。配置间的差异完全在于构建先验。壁挂艺术配置要求显式画布与带 UV 映射的图像纹理；简单物体配置避免不必要的部件拆分；家具配置鼓励重复的结构组件与有意义的内部子部件；铰接配置则要求独立的可动连杆与下游关节元数据。

路由提示本身刻意保持保守。它保留用户请求的风格，除非资产请求隐含相应内容，否则不会自行添加不支持的材质、颜色或功能机制。当一个请求包含多个不同物体时，路由器可将其拆分为多条资产请求，使每个物体都能由相应配置生成。例如，这可避免装裱海报与书架被错误地由单一生成策略生成。

总体而言，路由专属提示设计通过使提示约束与各物体族的几何、功能结构对齐，提升了视觉语言模型生成 Blender 代码的可靠性，同时保持了下游校验、执行、修复与打包管线的统一性。

B.5 为何路由专属构建提示至关重要

图6：路由专属提示消融实验。通用提示可生成视觉可信的资产，但路由专属构建提示能更好地保留语义部件、内部结构、材质关联与铰接就绪组件。

此处的通用提示指移除路由器，仅让视觉语言模型根据输入请求生成目标三维内容的 Blender 代码。如图 6 所示，该基线可生成视觉可信、指标友好的网格，但往往无法保留语义部件、内部结构、材质关联与铰接就绪性。例如，通用提示生成的床头柜缺乏内部结构与抽屉，因此不适合下游铰接。若没有路由专属构建先验，更复杂的几何结构（如办公椅结构）与更复杂的材质关联（如画布构建与纹理分配）也难以实现。

附录C 评估提示

本附录列出了场景级评估基准中使用的完整自然语言提示描述。提示集包含30条室内场景描述，涵盖六类房间：卧室、客厅、餐厅、厨房、浴室与地下室。下文按每条提示描述的房间类型进行分类分组。完整基准CSV文件还记录了每条提示的难度标签；总计包含15条简单提示、12条中等提示与3条困难提示。

C.1 卧室

• 一间配有床和衣柜的卧室。
• 一间卧室，角落摆放一张特大号床，配有两把大型蓝色扶手椅，扶手椅旁立着一盏落地灯。
• 一间卧室，配有一张双人床，床边放着一台迷你冰箱，门对面有一张桌子，床上方的墙上挂着一幅画。
• 一间卧室，一张特大号床靠墙摆放，正对着窗户。床前放置两张凳子。床的上方挂着一幅画，两侧各配有一盏壁灯。房间左侧有一个书架，上面放着两本书。
• 一间青少年卧室，远处角落有一张带床头板的舒适单人床，床底放着收纳箱。床尾处有一张小书桌，配有显示器、外接键盘鼠标，右侧有一盏台灯保证照明，旁边配一把滚轮椅。床边有一个床头柜，附近还有一盏落地灯，可放置手机与其他贵重物品。一个带多个抽屉的大型木质衣柜提供充足衣物存储空间，旁边的茶几上摆放着书籍与桌游。房间中央铺着一块棕褐色地毯，打造出舒适的落座区域，墙面上装饰着各式海报与照片。
• 这是一间小巧朴素的卧室。进门后，右侧靠墙摆放着一张白色书桌，桌前有一把黑色滚轮椅。一张双人床居中靠墙放置，两侧各有一个现代风格床头柜，其中一个上面放着一盏造型别致的台灯。

C.2 客厅

• 一间配有电视、沙发、书架与茶几的客厅。
• 一间客厅，靠墙摆放着一张双人沙发，沙发前方的中央铺着一块方形地毯，沙发附近的地面上摆放着两盆大型绿植。
• 一间宽敞的客厅，靠墙设有三个展示架，前方摆放一张长沙发。沙发前有两张桌子，沙发右侧还有一张桌子，上面放着一盏台灯。房间内没有电视。
• 一间客厅，中央摆放着一张不规则形状的桌子，桌前放着一张沙发。桌子对面是两把单人沙发椅，中间摆放一张小型木质茶几。远离房门的墙面上挂着一个时钟。
• 房间光线昏暗，营造出沉静的氛围，这是一间布置温馨、家具齐全的客厅。房间中央摆放着一张餐桌，四周整齐排列着四把木质餐椅。桌面似乎已经摆好餐具，暗示着刚结束的用餐或聚会。紧邻用餐区，一张玻璃茶几作为会客区的核心，兼具美观与实用性，可放置饮品或装饰。茶几前方是一张多人沙发，为客人提供充足的座位。两把舒适的扶手椅分列茶几两侧，靠近沙发，同样面向茶几。沙发与每把扶手椅旁都配有边角几，提升实用性与便利性，每张桌子上都放着台灯用于照明。沙发与座椅组应朝向对面的墙壁，坐在房间里的人可以观看一台大屏平板电视。电视由电视柜支撑，柜下的储物空间存放着各类书籍。尽管背景中电视里播放着令人不安的新闻节目，房间整体仍传递出温暖宜人的氛围。宁静的客厅与电视里混乱尖叫的画面并置，营造出紧张不安的感觉。
• 一间客厅，配有一张宽大的沙发、一张复古木质桌子，墙上还装饰性地挂着一辆自行车。

C.3 餐厅

• 一间餐厅，吧台桌的短边两侧各放着一把吧台椅。
• 一间餐厅，门旁靠墙放着一个柜子，吧台桌附近的墙边有两个酒柜。
• 一间餐厅，角落摆放着一张桌子，长边一侧放着一把椅子。
• 一间餐厅，中央摆放着一张吧台桌。墙上安装了一个木质置物架，上面放着一盆盆栽与一个水壶，兼具装饰性与功能性。墙边设有一台冰箱与一个酒柜，提供充足储物空间，整体风格统一。
• 一间餐厅，一张圆形木质餐桌位于房间中央，周围摆放着六把木质餐椅。房间内没有茶几。
• 一间餐厅，一张圆形餐桌周围摆放着六把复古餐椅，墙边靠着一把旧木梯，上面陈列着植物与装饰罐。

C.4 厨房

• 一间厨房，角落设有一张小酒馆餐桌与两把椅子，旁边摆放着一台冰箱。
• 一间时尚的厨房，大理石台面的厨房操作台上方悬挂着一盏精致的吊灯。靠墙设有一个橱柜，提供充足储物空间。
• 在这间现代厨房里，中央摆放着一张大型吧台桌，配四把高背椅，方便社交聚会；远处墙边立着一台不锈钢冰箱，旁边是一个整洁的食品储藏架。桌面上放着一小碗水果。
• 这间温馨的厨房，靠窗摆放着一张质朴的木质餐桌，周围配有四把椅子。靠墙的餐边柜上摆放着咖啡机与小型香草盆栽。

C.5 浴室

• 一间浴室，磨砂窗边放置一个独立浴缸，对面是双台盆洗手台。
• 一间经典风格的浴室，一侧墙边设有双台盆洗手台，上方挂着两面圆形镜子，角落摆放着一个马桶。
• 这间浴室里，宽大的洗手台靠墙放置，上方安装着一面高身镜子。附近、靠近门的位置放着一个造型别致的洗衣篮，浴缸旁有一个小篮子，装着洗浴用品。
• 一间明亮的浴室，大窗边摆放着一个宽敞的浴缸，墙边立着一个时尚的置物架，陈列着毛巾与小型装饰品。马桶位于浴缸对面，旁边有一个小篮子。

C.6 地下室

• 这间地下室的中央摆放着一张台球桌，附近的吧台桌旁排列着两把吧台椅，适合社交聚会与娱乐。
• 一间用作健身房的地下室，靠墙摆放着一台跑步机与一辆健身单车，正对健身单车的墙上安装着一面全身镜。
• 这间多功能地下室，中央摆放着一张大沙发与一块地毯，打造出舒适的观影区；角落放置一台小型跑步机，可供短时锻炼。墙边挂着一块迷你黑板，旁边是一个挂钟。
• 这间娱乐型地下室，一侧墙边的书桌上摆放着两台显示器，构成大型游戏设备；附近放着一个舒适的豆袋椅，可供休闲就坐。游戏区对面是一个小柜子，配有迷你冰箱，顶部放着一台爆米花机，整体配置齐全。

附录D 指标详情

D.1 场景级指标

本文采用 SceneEval 基准[30]的场景级指标，综合评估显式提示要求（物体存在性、属性与关系）与隐式物理合理性（支撑性、可达性、可通行性、碰撞、越界放置与开口净空）。

• CNT（物体数量）：物体数量要求的满足率。由视觉语言模型将场景物体与提示中指定的物体对应，再将实例数量与标注数量（精确值或相对值）进行比较。该指标衡量生成场景是否包含请求的各类别物体数量。
• ATR（物体属性）：物体属性（如颜色、材质）的满足率。对每个带属性要求的物体，渲染其正面视图与带人体比例参考的参考视图，由视觉语言模型评估物体是否满足指定属性。该指标检验生成器除了生成正确的物体类别外，是否保留了提示中的描述性修饰语。
• OOR（物体间关系）：物体间空间关系（如“椅子在书桌前方”）的满足率。基于物体位姿与包围盒进行几何校验，对照预定义的关系类型评估关系是否成立。该指标衡量请求的物体间空间约束是否在生成场景中实现。
• OAR（物体与建筑关系）：物体与建筑结构关系（如“沙发靠墙”“地毯在房间中央”）的满足率。对照预定义关系类型，检验物体与建筑元素（墙、地面、天花板）的关系是否成立。该指标衡量请求的物体与建筑空间约束是否得到满足。
• SUP（支撑性）：稳定支撑的物体占比。由视觉语言模型从渲染图像中将每个物体分为地面支撑、物体支撑、墙面支撑或天花板支撑四类，再通过光线投射验证物体是否与对应类型的其他物体或建筑元素实际接触支撑。该指标刻画了除无碰撞之外的基本放置稳定性。
• ACC（可达性）：功能面保持可达的物体占比。由视觉语言模型识别每个物体的功能面（如沙发正面、床的侧面），再通过二维占用分析检验这些侧面是否无遮挡。该指标衡量物体放置是否保留了生成物体的使用性。
• NAV（可通行性）：最大连通自由地面区域占总自由地面空间的比例。构建场景的二维占用投影，并在自由空间上计算连通分量。数值越低表示物体放置将地面分割为孤立区域，数值接近1表示存在单一、可通行的自由区域。
• COL（碰撞）：与其他物体发生相交的物体占比。对所有物体进行逐对网格碰撞检测，报告至少参与一次碰撞的物体百分比。该指标刻画最基本的物理有效性要求：场景中的物体不应相互重叠。
• OOB（越界）：放置在户型边界外的物体占比。对每个物体采样表面点并向地面投射光线；若少于99%的光线击中房间地面，则判定该物体越界。该指标惩罚穿墙或超出房间轮廓的放置。
• OPC（开口净空）：建筑开口（门与窗）的净空体积被物体遮挡的比例。对每个开口，在其前方构建拉伸的净空立方体，任何与该体积相交的物体都视为遮挡开口。该指标保证门与窗保持功能可用性。

D.2 物体级网格与材质指标

本文使用网格与材质级指标评估生成的三维资产，反映下游可用性。具体报告材质槽数量、PBR通道覆盖率、非流形边数量、总面数、总顶点数与UV岛数量。这些指标从材质可编辑性、PBR渲染就绪度、拓扑有效性、几何紧凑性与UV布局组织性等互补维度刻画资产质量。所有物体级指标均通过同一资产加载与网格评估管线计算，先逐资产计算，再在评估集上取平均。

• 材质槽数量：对每个生成资产，加载属于该资产的所有网格物体，统计其上分配的非空材质槽数量。对于多部件资产，资产级得分为所有网格部件的材质槽之和。整体而言，该指标衡量材质可编辑性与语义材质分解程度：槽数越多表示资产被划分为更多材质区域，通常有利于编辑与分配部件专属外观。
• PBR通道覆盖率：在固定的材质通道集合 ${\mathcal{C}}_{PBR}$（如基础色、粗糙度、金属度、法线、透明度、自发光通道）上评估PBR就绪度。对每种材质 $m$，统计 ${\mathcal{C}}_{PBR}$ 中有多少通道以标量值或纹理/节点输入的形式存在，并除以所考虑的通道总数进行归一化：
  S p b r ( m ) = ∣ { c ∈ C P B R : c  is present in  m } ∣ ∣ C P B R ∣ . S_{pbr}(m)=\frac{\left|\left\{c \in \mathcal{C}_{PBR}: c \text{ is present in } m\right\}\right|}{\left|\mathcal{C}_{PBR}\right|} . Spbr​(m)=∣CPBR​∣∣{c∈CPBR​:c is present in m}∣​.
  资产级得分为其所有材质的平均值，最终报告得分为所有生成资产的平均值。该指标用于衡量资产是否适用于基于物理的渲染工作流：通道覆盖越丰富，下游渲染器与编辑器获得的材质信息越完整。
• 非流形边数量：对每个网格，统计邻接面数不等于2的边，包括边界边与被超过两个面共享的边。对资产 $a$ 及其网格部件集合 ${\mathcal{M}}_a$，资产级非流形边数为：
  N n o n m a n i f o l d ( a ) = ∑ M ∈ M a ∣ { e ∈ E M : d e g F ( e ) ≠ 2 } ∣ , N_{nonmanifold }(a)=\sum_{M \in \mathcal{M}_{a}}\left|\left\{e \in E_{M}: deg_{F}(e) \neq 2\right\}\right|, Nnonmanifold​(a)=M∈Ma​∑​∣{e∈EM​:degF​(e)=2}∣,
  其中 $de{g}_F(e)$ 为边 $e$ 的邻接面数量。该指标衡量拓扑有效性与网格整洁度。数值越低表示几何越干净，零则表示评估管线未检测到任何非流形边。
• 总面数：将资产中所有网格部件的网格面数相加，得到总面数：
  $$N_{face}(a)=\sum _{M\in {\mathcal{M}}_a}\left|F_M\right|$$
  其核心作用是衡量几何紧凑性与下游处理成本。在视觉质量相当的前提下，面数越低表示表示形式越高效，渲染、存储与处理成本越低。
• 总顶点数：将资产中所有网格部件的网格顶点数相加，得到总顶点数：
  $$N_{vertex}(a)=\sum _{M\in {\mathcal{M}}_a}\left|V_M\right|$$
  与面数类似，该指标衡量几何紧凑性。在生成资产保留相近视觉与语义质量的前提下，数值越低表示网格表示越轻量。
• UV岛数量：对每个带UV贴图的网格，构建UV连通图，并统计UV布局中的连通分量。当对应UV边在UV空间中连续时，两个面在该图中连通。资产级UV岛数为所有网格部件的UV连通分量之和。该指标衡量UV布局的组织性：岛数越少表示参数化越连贯，越易于检查、纹理映射与编辑；过度碎片化则表示UV布局组织性较差。

附录E SceneCode 资产与现有资产生成策略对比

本附录阐明，SCENECODE 并非仅仅改变了资产的获取来源。相反，它改变了资产层的表示形式。现有管线通常检索固定网格、检索预铰接模型，或生成不透明网格。在这三种情况下，资产在很大程度上都被视为最终产物。而 SCENECODE 将资产表示为可执行、具备部件感知的构建代码，能够在同一物体级表示中同时提供定制几何、语义部件、铰接元数据、可编辑结构与仿真就绪封装。

本文按所采用的资产策略对代表性现有系统进行分组。检索静态资产策略被以布局为核心与基于检索的场景合成器采用，包括LayoutGPT[6]、ATISS[21]、InstructScene[14]、Holodeck[39]、LayoutVLM[28]与HSM[23]，它们放置从整理好的三维库中提取的预构建静态网格。检索铰接资产与生成不透明网格两种策略均被SceneSmith[22]采用：它从PartNet-Mobility风格数据集[38]中检索铰接物体作为可交互元素，同时通过图像到三维管线生成其余的单块网格。

表5：SCENECODE 资产与常见现有资产生成策略的对比。核心区别不在于资产来源，而在于资产层的表示：SCENECODE 将物体存储为可执行、部件分解的程序，附带显式几何结构，以及（必要时）铰接与仿真元数据。

前两种策略受限于资产集合中已有的内容。静态检索可提供视觉可信的物体，但通常缺乏语义部件结构，也无法引入新的铰接物体设计。铰接检索仅在数据集中存在合适资产时才能保留关节，且其几何通常除粗略缩放或材质编辑外无法定制。不透明网格生成可以创建新形状，但生成的资产难以编辑、检查、分解为功能部件，或编译为带可靠连杆与关节的仿真器对象。

相比之下，SCENECODE 资产将几何构建、部件层级与封装元数据耦合在同一个可执行物体程序中。这使系统能够合成前所未有的物体变体，保留可编辑的子结构，在导出前标记可动组件，并将生成的物体打包用于下游仿真，而非将仿真支持视为独立的后处理步骤。

讨论：SCENECODE 与 SceneSmith 的对比。 在智能体式、仿真就绪的场景生成器中，SceneSmith[22] 与 SCENECODE 的定位最为接近：二者均面向具备物理交互能力的室内环境，而非纯视觉布局。然而，两套系统在物体级交互的实现方式上存在根本差异。

SceneSmith 通过混合两种资产来源构建场景：从整理好的数据集中检索铰接物体（如PartNet-Mobility风格库[38]），并通过图像到三维管线生成其余物体为不透明网格。因此，SceneSmith 场景中的每个可交互物体都受限于底层铰接物体数据集的覆盖范围；无法按需引入新的铰接类别或特殊关节配置。而其图像到三维分支生成的单块网格缺乏语义部件分解、关节标注与代码级可编辑性，因此不经过额外的事后铰接步骤就无法升级为可交互物体。

SCENECODE 消除了这种分裂。每个物体都被生成为可执行程序，同时完成从基元构建几何、将结果分解为命名语义部件、分配材质，以及（在适用时）在同一程序内声明棱柱或旋转关节、碰撞代理与物理属性。相较于SceneSmith，这带来四点具体优势：

• 无限制的铰接覆盖：可直接根据提示生成全新的可交互物体（如带铰链顶柜的定制多抽屉橱柜），而非受限于铰接物体数据集中已有的资产。
• 固有的部件层级与铰接性：部件与关节在生成时就成为程序的一等元素，而非要么继承自整理好的数据集，要么完全缺失（如图像到三维网格的情况）。
• 代码级可编辑性与局部重生成：由于每个物体都是一段程序，可局部编辑单个属性（尺寸、材质、关节范围、抽屉数量）并重执行，而SceneSmith的检索或图像到三维资产一旦选定就基本固定。
• 统一的仿真封装：仿真元数据——变换、支撑面、包围盒、铰接文件——由同一程序输出并注册到持久化场景状态中，无需维护独立的检索、生成与铰接管线。

简言之，SceneSmith 将可交互资产视为可供选择（铰接检索）或塑形（图像到三维）的对象，而 SCENECODE 将其视为可供编程的对象，这正是实现按需、可定制、可编辑的可交互场景合成的核心。

附录F 更多分析

本附录对第4.2节的房间级结果展开逐指标讨论。首先详细说明SceneCode领先的指标，再介绍其不占优的指标，以及造成这些差距的设计权衡。

语义保真度（CNT、ATR）。 SceneCode取得了最优的CNT（0.7951）与ATR（0.7344），是唯一同时在两项语义保真度指标上领先的方法。与最强基线SceneSmith相比，CNT优势较小（+0.0068），但相较于LayoutVLM（+0.1528）与HSM（+0.2623）差距持续扩大，表明SceneCode的逐物体请求管线能够可靠生成提示中指定的类别与数量。

ATR的优势更为显著：SceneCode超出SceneSmith 0.0182，超出HSM 0.1429，超出LayoutVLM达0.4236。本文将这一增益归因于可执行物体程序：逐物体代码直接从规划器接收属性参数（颜色、材质、风格、尺寸），并在构建时直接实现，因此提示中的描述性修饰语会转化为实际的资产属性，而非由最接近的检索网格近似。这也是图3中SceneCode比基于检索或主题的基线更贴合提示氛围与材质线索的核心原因。

物理合理性（NAV、COL、OOB）。 SceneCode同时在三项隐式物理合理性指标上领先：NAV（0.9999）、COL（0.0934）与OOB（0.0042）。其碰撞率约为各基线的一半（HSM为0.1882，SceneSmith为0.1812，LayoutVLM为0.2105），越界比例比LayoutVLM（0.0592）与HSM（0.0722）低一个数量级以上。本文将其归因于可执行物体代码生成的清晰、贴合轴对齐包围盒的几何结构，使放置器能够精确推理，因此碰撞与地面贴合度检测所基于的形状与实际渲染的形状完全一致。

物体间与建筑关系（OOR、OAR）。 SceneSmith在OOR（0.3723）与OAR（0.7241）上领先；SceneCode在OOR上紧随其后（0.3472，差距0.0251），在OAR上有所落后。造成这一差距的一个实际原因是本管线的资产接受机制：当物体程序超出重试预算仍未通过物体规划校验时，智能体会跳过该物体，而非提交低质量资产，这会导致最终场景中缺失部分承载关系的物体。而SceneSmith等网格生成基线不存在这一权衡，因为其图像到三维分支几乎能为任何请求返回视觉可信的网格，即便牺牲了细粒度语义准确性。因此，本文认为OOR基本持平，OAR是未来工作的可改进方向，例如在放置循环中加入关系感知奖励，或放宽对以关系表达为主的物体的资产接受标准。

逐基线权衡（SUP、ACC、OPC）与总体结论。 各项基线领先的指标分别对应各自的针对性设计选择，而非整体场景质量的体现。HSM在SUP（0.7072）上领先，因为其分层主题硬编码了支撑放置规则，但它在CNT上排名末位，在关系指标上位列倒数第二。LayoutVLM在ACC（0.9330）上领先，因为其可微布局目标显式优化可达性，且生成的场景明显稀疏——房间异常空旷，使得大多数功能面自然无遮挡，变相抬高了可达性得分——但它在ATR（0.3108）与SUP（0.2566）上表现很差。SceneSmith在OPC（0.0792）上领先；LayoutVLM完全未实现OPC（标注为N/A）。SceneCode在SUP（放置器尚未对每个物体进行支撑类型分类）与OPC（未强制执行开口净空检测）上落后；这两点都是与特定检测相关的局部不足，无需改变资产表示即可补充。

附录G 用户研究完整结果

设置回顾。 用户研究共9名参与者，平均分为3组，每组3人。A组对比SceneCode与SceneSmith，B组对比SceneCode与HSM，C组对比SceneCode与LayoutVLM，使用与自动评估相同的30条SceneEval-100房间级提示。对每条提示与每组对比，参与者进行两两偏好选择，并按1–5李克特量表对两个场景的提示忠实度与真实度打分。

由于SceneCode由全部9名参与者评分，而每条基线仅由对应组的3名参与者评分，因此绝对均值无法在基线间直接比较。因此本文报告两项指标：（1）偏好损失率，定义为基线优于SceneCode的对比比例；（2）配对逐样本差值$\Delta \text{PF}$与$\Delta \text{Realism}$：对每个样本，计算同一条提示、同一名评分者下SceneCode与基线的差值，再在每组$n=90$个配对样本上报告均值与95%置信区间。这种配对差值设计控制了评分者个体差异与提示抽样偏差，可单独比较SceneCode与各基线的差异。图7展示了用于收集用户研究评分与两两偏好的界面。

图7：用户研究界面。本文用于收集评分的界面截图。

两两偏好。 表6显示，基线被偏好的比例与基线在自动指标上的竞争力呈负相关：相较于LayoutVLM仅为3.3%，相较于HSM为20.0%，而相较于最强的基于检索的基线SceneSmith则为36.7%——后者的图像到三维分支几乎能为任何请求生成视觉丰富的网格。这一排序与表1中的$\Delta \text{PF}$列一致：提示忠实度差距越小，偏好结果越接近。

表6：用户研究完整结果。两两偏好损失率（基线优于SceneCode的试验比例，数值越低越好）与配对逐样本差值$\Delta \text{PF}$、$\Delta \text{Realism}$（每个试验内计算SceneCode与基线的差值后取平均），每组$n=90$个试验，较小字体标注95%置信区间。

真实度权衡。 SceneCode在真实度上优于HSM（+0.27）与LayoutVLM（+1.93），但逊于SceneSmith（−0.34）。这与上文讨论的OOR/OAR权衡相呼应：SceneSmith的图像到三维分支几乎能为任何请求返回照片级真实的检索网格，而SceneCode优先保证属性忠实的程序化几何，即便在视觉丰富的物体上真实感稍弱，但提示忠实度更优（注意同组中SceneCode仍在$\Delta \text{PF}$上胜出，为+0.14，且自动ATR指标更优）。因此，真实度差距是资产表示的固有属性，而非规划管线的问题，未来可在现有物体程序的基础上叠加神经纹理合成、材质精化或细节增强几何模块加以改进。

为何使用组内差值。 单一全局排名会混合三个不同的评分组与三种不同的基线分布，导致基线间的差异与参与者分组混淆。通过在每行中固定评分组，仅对比该组所见的基线与SceneCode，配对样本的$\Delta$值可以准确衡量该组参与者在同一条提示下对SceneCode与对应基线的评价差异。

附录H 计算开销统计

本文报告了实验所用同一批评估运行的计算开销统计。表7总结了基于token的货币成本（单位：美元），表8总结了实际运行时长。平均物体构建成本与平均智能体成本分解了平均token成本。

表7：评估运行的基于token的货币成本统计。平均物体构建成本与平均智能体成本为平均token成本的分解项。

表8：评估运行的实际时间开销统计，同时以小时:分钟:秒与秒为单位报告。

附录I 更多定性演示

I.1 场景演示

图8提供了更多关于SCENECODE房间级表现的定性证据。在这些提示中，生成的房间包含了请求的家具与功能物体，摆放为合理的房间级布局，同时保留了质朴的餐厅家具、地下室角落的健身器材、窗边的卫浴设施、装饰性墙面物品等属性线索。这些示例补充了正文的对比，说明代码驱动表示并非仅适用于孤立的展示场景：规划器可以实例化大量物体请求，连贯地布置它们，并保留足够的自由空间以支持导航与物理使用。

图8：更多房间级演示。SCENECODE 生成的厨房、地下室、餐厅、客厅、浴室与卧室场景，均具备高提示忠实度的物体覆盖、空间布局与风格属性。

I.2 物体演示

图9凸显了将资产生成为可执行构建程序在物体层面的优势。渲染视图展现了视觉各异的材质与外观，而对应的线框图则呈现出清晰、可编辑的几何结构，而非不透明的重建网格。这种结构对下游编辑与仿真十分有用，因为单个组件、尺寸与材质分配都可在代码中访问。

壁挂艺术示例表明SCENECODE可在薄的装裱物体上放置图像与文字内容；台球示例体现了对曲面光泽几何的数字与材质控制；桌游盒示例则说明可同时生成文字、彩色图形与分层物理结构。这些案例共同支撑了核心论点：SCENECODE不仅通过放置物体提升场景合成效果，更通过生成可控的代码驱动资产，使其保持可解释、可编辑且与物理场景构建兼容。

图9：更多物体级演示。SCENECODE 生成的家具、天花板物体、墙面物体与可操作物体的渲染图与对应线框图。示例表明，代码生成的资产能够表达材质、数字、文字与复杂几何结构，同时保留显式的网格组织。

I.3 铰接物体演示

图10展示了SCENECODE生成的铰接家居物体具备正确的几何结构、搁板与分隔等储物内部结构，以及可用于下游交互的可动组件。

图10：铰接物体演示。SCENECODE 生成的铰接家居物体，具备正确的几何结构、储物内部结构（如搁板、分隔）与可动组件，可支持下游交互。

图10表明，SCENECODE能够将铰接家居物体合成为结构化的可执行资产。生成的储物物体不仅外观合理，还保留了隔间、搁板、分隔等有意义的内部几何结构。其铰接性通过独立的功能部件（包括门、抽屉、盖子）体现，因此生成的资产可以支持符合物理意义的开合或滑动行为，而非保持静态网格。由于这些物体由基于请求的代码生成，其尺寸、内部布局、材质与关节配置均可按需定制，无需从固定资产库中检索最近邻，也无需依赖繁琐的人工建模。

附录J 可执行物体代码演示

本附录给出SCENECODE所用可执行物体表示的具体示例。以生成的床头柜为运行示例。物体级Blender程序从几何基元与程序化材质构建可移动抽屉，而导出的SDF将抽屉保留为独立的仿真连杆，并附带棱柱关节。

图11：生成的床头柜演示。

J.1 Blender抽屉构建程序

清单1展示了抽屉部件的完整Blender Python程序。代码显式呈现了抽屉前面板、侧壁、后壁、底板与旋钮的语义子结构，而非将对象存储为不透明网格。同时记录了构建尺寸、位置、材质、倒角与下游封装所用的局部原点。

# 部件：抽屉
# 描述：位于柜体上部的抽拉式抽屉
# 由部件构造智能体生成
import bpy
import math

def srgb_to_linear(srgb_color, alpha=1.0):
    linear_color = []
    for c in srgb_color:
        if c <= 0.04045:
            linear_color.append(c / 12.92)
        else:
            linear_color.append(((c + 0.055) / 1.055) ** 2.4)
    return tuple(linear_color) + (alpha,)

def create_drawer():
    """
    创建部件：抽屉
    形状：立方体
    尺寸：0.56 x 0.46 x 0.22
    位置：(0.0, -0.03, 0.84)
    """
    part_name = "drawer"
    # 若已存在同名物体则移除
    if part_name in bpy.data.objects:
        bpy.data.objects.remove(bpy.data.objects[part_name], do_unlink=True)

    # === 材质设置 ===
    # 1. 抽屉柜体与前面板的木质材质
    wood_mat_name = "drawer_wood_material"
    wood_mat = bpy.data.materials.get(wood_mat_name)
    if wood_mat is None:
        wood_mat = bpy.data.materials.new(name=wood_mat_name)
        wood_mat.use_nodes = True
        nodes = wood_mat.node_tree.nodes
        links = wood_mat.node_tree.links

        bsdf = next((n for n in nodes if n.type == 'BSDF_PRINCIPLED'), None)
        if bsdf:
            bsdf.inputs["Roughness"].default_value = 0.4
            bsdf.inputs["Metallic"].default_value = 0.0

            # 木纹程序化纹理
            tex_noise = nodes.new(type='ShaderNodeTexNoise')
            tex_noise.inputs["Scale"].default_value = 20.0
            tex_noise.inputs["Detail"].default_value = 4.0
            tex_noise.inputs["Distortion"].default_value = 1.0

            mix = nodes.new(type='ShaderNodeMix')
            mix.data_type = 'RGBA'
            mix.blend_type = 'MULTIPLY'
            mix.inputs["Factor"].default_value = 0.2

            base_color_srgb = (0.75, 0.5, 0.3)
            darker_wood_srgb = (0.6, 0.35, 0.2)

            mix.inputs[6].default_value = srgb_to_linear(base_color_srgb)  # A: 基础色
            mix.inputs[7].default_value = srgb_to_linear(darker_wood_srgb)  # B: 纹理色

            links.new(tex_noise.outputs["Fac"], mix.inputs["Factor"])
            links.new(mix.outputs[2], bsdf.inputs["Base Color"])

    # 2. 抽屉旋钮的塑料材质
    knob_mat_name = "drawer_knob_material"
    knob_mat = bpy.data.materials.get(knob_mat_name)
    if knob_mat is None:
        knob_mat = bpy.data.materials.new(name=knob_mat_name)
        knob_mat.use_nodes = True
        nodes = knob_mat.node_tree.nodes
        bsdf = next((n for n in nodes if n.type == 'BSDF_PRINCIPLED'), None)
        if bsdf:
            bsdf.inputs["Base Color"].default_value = srgb_to_linear((0.95, 0.95, 0.92))
            bsdf.inputs["Roughness"].default_value = 0.3
            bsdf.inputs["Metallic"].default_value = 0.0

    parts_to_join = []

    # 创建立方体形子部件的辅助函数
    def add_sub_part_cube(name, dimensions, position, material):
        bpy.ops.mesh.primitive_cube_add(size=1, location=position)
        obj = bpy.context.active_object
        obj.name = name
        obj.scale = dimensions
        bpy.ops.object.transform_apply(scale=True)
        if material:
            obj.data.materials.append(material)
        parts_to_join.append(obj)
        return obj

    # === 创建子部件 ===
    # 1. 抽屉前面板
    add_sub_part_cube(
        name="drawer_front_panel",
        dimensions=(0.56, 0.02, 0.22),
        position=(0.0, -0.25, 0.84),
        material=wood_mat
    )

    # 2. 抽屉左侧壁
    add_sub_part_cube(
        name="drawer_left_wall",
        dimensions=(0.015, 0.44, 0.18),
        position=(-0.2725, -0.02, 0.84),
        material=wood_mat
    )

    # 3. 抽屉右侧壁
    add_sub_part_cube(
        name="drawer_right_wall",
        dimensions=(0.015, 0.44, 0.18),
        position=(0.2725, -0.02, 0.84),
        material=wood_mat
    )

    # 4. 抽屉后壁
    add_sub_part_cube(
        name="drawer_back_wall",
        dimensions=(0.53, 0.015, 0.18),
        position=(0.0, 0.1925, 0.84),
        material=wood_mat
    )

    # 5. 抽屉底板
    add_sub_part_cube(
        name="drawer_bottom",
        dimensions=(0.53, 0.44, 0.015),
        position=(0.0, -0.02, 0.7575),
        material=wood_mat
    )

    # 6. 抽屉旋钮（球体）
    bpy.ops.mesh.primitive_uv_sphere_add(radius=0.03, location=(0.0, -0.28, 0.84))
    knob = bpy.context.active_object
    knob.name = "drawer_knob"
    knob.data.materials.append(knob_mat)
    parts_to_join.append(knob)

    # === 合并所有子部件为单个物体 ===
    bpy.ops.object.select_all(action='DESELECT')
    for p in parts_to_join:
        p.select_set(True)
    bpy.context.view_layer.objects.active = parts_to_join[0]
    bpy.ops.object.join()
    obj = bpy.context.active_object
    obj.name = part_name
    obj.data.name = f"{part_name}_mesh"

    # === 应用修改器 ===
    bevel = obj.modifiers.new(name="Bevel", type='BEVEL')
    bevel.width = 0.002
    bevel.segments = 3
    # 将倒角限制在一定角度内，避免破坏球形旋钮的几何结构
    bevel.limit_method = 'ANGLE'
    bevel.angle_limit = math.radians(30)

    # === 将原点设置为抽屉主位置 ===
    # 确保旋转与移动从正确的中心执行
    saved_cursor = bpy.context.scene.cursor.location.copy()
    bpy.context.scene.cursor.location = (0.0, -0.03, 0.84)
    bpy.ops.object.origin_set(type='ORIGIN_CURSOR')
    bpy.context.scene.cursor.location = saved_cursor

    return obj

if __name__ == "__main__":
    # 执行创建
    obj = create_drawer()
    print(f"Created {obj.name}: {obj.name}")

清单1：生成的抽屉部件的完整Blender Python演示代码。

J.2 SDF抽屉连杆与铰接

对应的SDF导出文件将抽屉保留为独立连杆。清单2展示了生成的SDF文件中的抽屉连杆头部、惯性属性、视觉网格与第一个碰撞代理。其余抽屉碰撞项遵循相同模式，为简洁起见在此省略。

<link name="drawer">
  <pose relative_to="base_link">0.00000000 -0.02083333 0.58333333 0.00000000 0.00000000 0.00000000</pose>
  <inertial>
    <mass>3.500000</mass>
    <pose>0.000000 -0.013572 -0.020292 0 0 0</pose>
    <inertia>
      <ixx>5.539828e-02</ixx>
      <iyy>6.690811e-02</iyy>
      <izz>1.101321e-01</izz>
      <ixy>2.495866e-11</ixy>
      <ixz>-3.135577e-12</ixz>
      <iyz>1.457055e-03</iyz>
    </inertia>
  </inertial>
  <visual name="drawer_visual">
    <pose>0 0 0 0 0 0</pose>
    <geometry>
      <mesh>
        <uri>visual/drawer_visual.gltf</uri>
        <scale>0.6944444444444444 0.6944444444444444 0.6944444444444444</scale>
      </mesh>
    </geometry>
  </visual>
  <collision name="drawer_collision_0">
    <pose>0 0 0 0 0 0</pose>
    <geometry>
      <mesh>
        <uri>collision/drawer_collision_0.obj</uri>
        <scale>0.6944444444444444 0.6944444444444444 0.6944444444444444</scale>
      </mesh>
    </geometry>
    <surface>
      <friction>
        <ode>
          <mu>0.500</mu>
          <mu2>0.500</mu2>
        </ode>
      </friction>
    </surface>
  </collision>

清单2：演示文件 nightstand_1777368137052.sdf 中的抽屉连杆片段。

清单3展示了同一抽屉的铰接元数据。棱柱关节将抽屉连杆与床头柜基座相连，沿y轴负方向滑动，行程范围限制为$[0.0,0.4]$。

<joint name="joint_drawer" type="prismatic">
  <parent>base_link</parent>
  <child>drawer</child>
  <axis>
    <xyz>0 -1 0</xyz>
    <limit>
      <lower>0.0</lower>
      <upper>0.4</upper>
      <effort>100</effort>
      <velocity>1.0</velocity>
    </limit>
    <dynamics>
      <damping>0.05</damping>
      <friction>0.05</friction>
    </dynamics>
  </axis>
</joint>

清单3：演示文件 nightstand_1777368137052.sdf 中的棱柱抽屉关节片段。

附录K 局限性

SCENECODE聚焦于具备物理交互能力的室内场景合成，这类场景中的物体通常由强功能与建筑先验（如地面、墙壁、支撑面、家具布局、家居铰接模式）组织。尽管该设定已覆盖多样的家居环境与广泛的常见物体，但将同样的纯代码驱动范式拓展至室外或大规模混合环境仍是有待探索的方向。室外场景具有更大的空间尺度、不规则地形、有机几何、植被、复杂光照、天气效应，以及更松散的物体布局，可能需要在当前室内管线所用的程序化先验与验证策略之外补充更多机制。

第二个方向关乎代码生成资产的视觉丰富度。SCENECODE优先保证显式的部件结构、可编辑性、清晰的几何结构与仿真导向的资产构建。这种设计使物体程序更具可用性，更兼容下游物理交互，但纯基元驱动的程序可能无法始终呈现检索或图像到三维管线所能提供的精细表面细节与照片级真实感纹理变化。未来工作可将可执行物体程序与神经纹理合成、材质精化或细节保留的几何增强相结合，同时保持底层语义部件与铰接元数据的可编辑性。

最后，本文的实现侧重生成质量、可追溯性与执行引导验证。这种设计有助于生成可编辑的世界程序，但也因程序合成、执行、修复与精化带来了不可忽视的运行耗时。未来系统可通过并行物体生成、针对三维资产生成蒸馏专用代码生成模型来提升吞吐效率。