静态物理满分、交互 11.54%:3D 场景生成系统的幻觉

文章目录

把一个房间生成得好看,和把一个房间生成得能用,是两件事。这句话在 3D 室内场景生成这个方向上,直到 2026 年才被系统性地量出来。

《ScIntBench: Physical Interaction Plausibility in 3D Scene Generation》做的事很直接:它不再只是渲染几张图、让多模态大模型打个分,而是把生成出来的场景原样搬进物理仿真器,让一台 Franka Panda 机械臂真的上去推椅子、开门、用探针探桌面,然后看会发生什么。论文评估了 12 个最先进的文本生成 3D 室内场景系统,覆盖四类完全不同的技术路线,每类房间各三条提示词,一共构造了 203 个交互任务,展开成 2436 个"场景 × 交互"评测实例。

结论先行:三个数字与一个被拆开的问题

三个数字

  • 11.54%:SAGE 的交互成功率。它的静态物理成绩几乎是满分------碰撞率只有 0.41%,被动稳定性 98.33%。也就是说,这是一个"摆得最干净"的系统,但规定动作只完成了 11.54%。
  • 36.92%:全场最好的成绩,来自通用编码 agent Claude Code。十二个系统里没有一个过半。
  • 7 / 12:有一半以上的系统,生成的场景连"被交互"这件事都做不到。论文的原话是这些场景"不支持物理仿真",因此连被动稳定性都没法测,交互成功率一律记为 0。

这三个数字放在一起,构成了一句相当不客气的判断:这个领域过去两年在排行榜上刷的东西,不能当作"仿真就绪"的证书。论文自己的表述更克制一些------看似合理的静止外观,并不保证交互就绪。

一个问题被拆成两个

论文最有价值的地方不是这几个数字,而是把一个此前混在一起的问题拆成了两个:

  • interaction availability(交互可用性):场景里到底有没有支撑这个动作的前提。冰箱有没有能转的铰链,桌子是不是一个可以推的刚体,台面是不是一块能放探针的水平面。
  • interaction reliability(交互可靠性):前提有了,动作真的执行下去之后,结果在物理上靠不靠谱。门是被推开了,还是被推飞了;桌子位移到了 15 厘米,还是把桌上的书碰下了地。

分开之后才能回答一个工程上真正重要的问题:一个场景失败,到底是因为它没有能力 ,还是因为能力不可靠。这两件事的修法完全不同------前者要补资产和物理元数据,后者要修生成与摆放的物理一致性。论文的答案是两个障碍同时存在,而且在现有 12 个系统里,前一个障碍更大。

现有评测只测到 t 等于 0 那一刻

语义分与静态物理分都在初始化时刻算

过去对生成场景的评测基本是两条线。第一条是语义保真:渲染出来看一眼,像不像那么回事,家具摆得对不对。第二条是静态物理合法:检查初始状态下有没有互相穿模、有没有越界、支撑关系对不对、在重力下放一会儿会不会自己塌。

这两条线有一个共同点:它们全部只描述 t=0,也就是场景刚生成完、还没被任何东西碰过的那个瞬间。论文举了两个例子把这个盲区说得很清楚:一台冰箱可能被摆在了完全正确的位置,但它没有可动的铰链,门根本开不了;一把椅子在重力下稳稳当当,但一被推、一被压,反应就不像真的。

这不是吹毛求疵。一个场景只要被拿去做具身智能的仿真环境,交互就是它唯一的存在方式。把只测 t=0 的指标当成验收标准,等于体检只量身高体重。

已有基准的对比:交互那一栏几乎是空的

论文用一张表把 8 个已有评测协议和 ScIntBench 摆在一起(原文 Table 1)。结果很整齐:语义视角这一栏人人都有,静态物理这一栏大部分有,而"主动交互物理"这一栏,只有 ScIntBench 一个打勾。

评测 / 基准 语义视角 静态物理 交互物理
SceneWeaver 俯视 有 无
SceneEval 俯视 有 无
SceneCritic 逐视角 有 无
LEGO-Eval 约束专用 无 无
VWE-Bench 5 视角 无 无
3DTindo 俯视加侧视 有 无
AuthorBench 状态加渲染 有 无
Code4Scene 4 全景 无 无
ScIntBench 俯视加四角 有 有

这些协议的侧重点不同:SceneEval 与 SceneWeaver 在语义之外加了静态的几何检查,SceneCritic 给逐视角的评语式批评,LEGO-Eval 检查自然语言约束,VWE-Bench、AuthorBench 与 Code4Scene 把评测扩展到编码 agent 的构建与编辑、指令满足与场景状态保持。共同的缺口是同一个:没有人真的动手。

还有一个细节值得注意:在"被评测的方法类型"这四列里,ScIntBench 是唯一四类全勾的。专用生成器、LLM 或 VLM 工作流、专用智能体流水线、通用编码 agent,都能用同一套任务集跑。这一点很关键,因为不同范式的场景生成在资产来源、物理属性处理、可交互性上差别极大,只有放在同一套动作契约下比较,那些差异才不会被生成方式的差异掩盖。

整篇论文的装置可以概括成三块(图 1):左边是五视角语义评分,中间是几何与被动稳定检查,右边是主动交互评估------动作集、指令、仿真器状态、规则判据与多模态评审串成一条链。图的下半部分直接给了两组结果和三种失败模式,基本上就是全文的缩略图。

图 1|整套评测装置的三块:左边五视角语义评分,中间几何与被动稳定检查,右边把动作集、仿真器状态与四类判据串起来的主动交互评估(原文 Figure 1)

图源:ScIntBench: Physical Interaction Plausibility in 3D Scene Generation(arXiv:2610.37326v1),arXiv 非独占许可

评测装置:把场景搬进 Isaac Sim,真的推一把

30 条提示、10 类房间、203 个任务

基准的文本提示直接取自 SceneEval,30 条,覆盖 10 类室内房间,每类 3 条:卧室、客厅、餐厅、游戏室、厨房、浴室、地下室、书房(den)、游戏房(playroom)、办公室(图 2)。每条提示配一份语义要求与一组交互任务,12 个方法各生成一遍,共 360 个场景。

交互任务不是随手写的。论文用 GPT-5.6 做了两阶段构造:第一阶段从一个预定义动作库里选出适用的动作族,同时把提示词里明确提到的所有物理实体列成清单(包括地标、上墙物件和建筑构件);第二阶段对每一个"动作 × 实体"的组合判断语义上是否适用,适用的全部保留,不做 top-k 截断。两阶段都要求"不要凭空发明把手或隐含部件",也就是说,判断一条交互任务是否成立,依据的是提示词怎么写,而不是某个方法能不能做到。

这一步是整篇论文的方法论地基:任务集在生成之前就固定,并且对所有方法共享。203 个任务乘以 12 个方法,就是那 2436 个评测实例。生成方法没有办法"只提供自己能做的动作",也没有办法通过少生成可交互物件来减少被考的次数。

动作只有三类,但每类都有冻结的成功判据

动作库里只有三个族:

  • open hinged:开合页式的封闭体或门,通常是柜门、房门、冰箱门。
  • push rigid:推动落地支撑的独立刚体,做水平平移,结束时必须仍然落地支撑。
  • place push probe:把标准化的小刚性探针放到一个可接近的水平支撑面上,再按外力时序推它。

动作库的措辞里还有几条排除规则,看得出作者被这类评测坑过:开合只适用于"正常带铰链的封闭体或门",不包括"只有抽屉的储物柜"的一般性打开;推刚体不能把上墙固定的东西拆下来推,也不能把架子上的物件推下去;探针探测要求存在真正可接近的水平支撑面,不能在曲面物件上凭空造一个平台,也不能用被水槽占满的开口充当台面。

每类动作都配了冻结的成功判据。论文给了一个完整例子------一个卧室场景(双人床、床边小冰箱、门对面的桌子、床上方墙上的画)被构造成 8 个任务:开小冰箱门(开启角 ≥60° 且保持 ≥1 s)、开房门(同样 ≥60° 且 ≥1 s)、推双人床、推小冰箱、推桌子(后三者位移落在 0.13--0.17 m,也就是 15 厘米上下浮动 2 厘米)、以及在床面、冰箱顶、桌面各做一次探针探测(滑动 ≥0.02 m 并保持 ≥0.2 s)。

场景按原样评估:缺的东西不补

这是全篇最容易被忽略、但决定了所有数字含义的一条规则:缺失的物理属性或铰链机构不会自动补齐。场景生成出来是什么样就什么样,评估过程只保留原始几何、物体位姿和原生物理属性。

于是就有了那个 N.S.A. 标签------not support interaction,因为缺目标物体或缺原生物理前提。在 2436 个实例里,有 1534 个落进这一类,只有 902 个是真正被有效执行并留下了物理证据的。换句话说,这批场景里超过六成的"场景 × 交互"组合,连被评判的资格都没有。

这条规则是公允的:如果评测器会替场景补铰链、补质量、补摩擦系数,那测出来的就是评测器的补全能力,而不是生成方法的能力。代价是"失败原因"被合并了------缺目标和缺物理机制被压进同一个标签,后面会专门讨论这一点。

图 2|基准覆盖的十类室内房间:卧室、客厅、餐厅、游戏室、厨房、浴室、地下室、书房、游戏房、办公室(原文 Figure 4)

图源:ScIntBench: Physical Interaction Plausibility in 3D Scene Generation(arXiv:2610.37326v1),arXiv 非独占许可

四类交互指标:成功、进度、完整、可信

ISR:二元的交互成功率

最直接的一个指标。ISR 就是规定任务里成功完成的那个比例,成功与否只看仿真器可观测的状态是否满足预先写死的判据。缺目标物体或缺原生物理前提的任务,直接记为不成功,而不是剔除。控制器或仿真本身崩掉的情况会被单独标记,不算到生成场景头上。

I S R m , p = 1 N p ∑ t ∈ T p I t , I t = 1 S u c c e s s ( m , p , t ) \mathrm{ISR}{m,p} = \frac{1}{N_p}\sum{t \in T_p} I_{t}, I_{t} = \mathbf{1}\left\\mathrm{Success}(m,p,t)\\right ISRm,p=Np1t∈Tp∑It,It=1Success(m,p,t)

这里 m 是生成方法,p 是提示词,T_p 是这条提示词对应的共享任务集,N_p 是任务数,方括号里是指示函数。公式很朴素,但它把"缺能力"和"做失败"压成了同一个 0,这正是下一个指标要解决的问题。

ICP:把"差一点"和"根本不会"分开

二元成功会掩盖一件重要的事:一个场景是"门在那儿但没铰链",还是"门有铰链、被推到 0.47 度就卡住了",在 ISR 里都是 0 分,但工程含义天差地别。所以论文引入了六级量表 ICP:

分值 档位 判据 典型表现
0 Target Absent 目标缺失 场景里没有这个交互目标 提示词点名了冰箱,场景里没有冰箱
2 Target Present 目标存在 目标在,但不具备动作所需的物理结构 冰箱摆在那儿,但没有可动铰链
4 Physically Interactable 物理可交互 有合法碰撞几何、关节或铰链,动作在物理上可能 门能转,只是这次没被推动
6 Interaction Initiated 交互已启动 能产生有效响应,但在取得实质进展前失败 门开了 0.47 度就停住
8 Substantial Progress 实质推进 朝目标取得了大量且物理正确的进展,但没到判据 门开了 50 度,差 10 度
10 Task Success 任务成功 达到预定义的成功状态 门开了 67.96 度并保持住

I C P m , p = 1 N p ∑ t ∈ T p s ( m , p , t ) , s ∈ { 0 , 2 , 4 , 6 , 8 , 10 } \mathrm{ICP}{m,p} = \frac{1}{N_p}\sum{t \in T_p} s(m,p,t), \quad s \in \{0,2,4,6,8,10\} ICPm,p=Np1t∈Tp∑s(m,p,t),s∈{0,2,4,6,8,10}

打分由多模态大模型完成,输入是场景表示、可用的原生物理能力,以及在能执行时附上的执行观测。注意这不是一个"看着像那么回事就给分"的自由评分,而是一个严格有序的六档量表:只有当前面所有档位都成立,才可能被打到更高一档。所以 ICP 的分值天然是偶数,平均下来也不会出现 7.3 这种精细到小数点的错觉------它其实就是各档位的加权平均。

这个指标在整篇论文里承担了最多的归因工作。后面会看到,最能区分系统差异的不是 ISR,而是 ICP:ISR 大面积并列成 0,ICP 却能把它们摊开在 0.72 到 7.35 之间。

PIV:执行之后留下了多少烂摊子

任务成功不代表场景没被搞坏。论文定义 PIV 来量执行之后的物理完整性:把初始状态和执行后经过标准沉降期的状态做对比,逐个物体检查有没有出现新的或恶化的违规------非预期位移、新的或加重的互相穿透、越界、必需支撑关系丢失。一个物体只要出现其中任意一种就算一次违规,多种违规同时出现也只算一次。

V i o l a t i o n ( m , p , t ) = ∣ V m , p , t ∣ ∣ O m , p ∣ , P I V m , p = 1 N m , p ′ ∑ t ∈ T m , p ′ V i o l a t i o n ( m , p , t ) \mathrm{Violation}(m,p,t) = \frac{|V_{m,p,t}|}{|O_{m,p}|}, \mathrm{PIV}{m,p} = \frac{1}{N'{m,p}} \sum_{t \in T'_{m,p}} \mathrm{Violation}(m,p,t) Violation(m,p,t)=∣Om,p∣∣Vm,p,t∣,PIVm,p=Nm,p′1t∈Tm,p′∑Violation(m,p,t)

这里 O_{m,p} 是原场景里的物体集合,V_{m,p,t} 是执行任务 t 之后出现了新增或恶化违规的子集,T'_m,p 是真正被有效执行过的任务集合。PIV 越低越好,而且是按场景算完再平均。

一个容易搞混的细节:任务本身的预期运动不算违规。开门、把目标物体推到 15 厘米外,这些是任务要求的结果,不能被记成"非预期位移"。但预期运动也不会让物体豁免碰撞、越界和支撑检查------门开了,不代表门可以穿进墙里。这条区分很要紧,否则一个成功推开门的场景会因为门动了而被判违规。

DP:从交互视频里看物理像不像真的

第四个指标 DP 是感知层面的补充。给定交互过程录下来的视频帧、动作意图和执行协议,让多模态大模型在 0 到 10 之间打分,评判的是可观察的物理行为:运动与因果(是否符合接触力、加速度、惯性、制动的直觉)、接触与碰撞(穿透、穿模、抖动、不真实撞击、缺少物理耦合)、重力与支撑(下落、静止、倾倒、支撑转移,包括非目标物体)、摩擦与滑动、刚性与铰链(完整的刚体、连接件、铰链轴、关节运动)。

这个指标的设计里有两个自我约束值得一提。第一,证据不足不等于违规 :被遮挡的接触属于"未验证",视觉伪影本身也不能用来断定碰撞,模型被要求承认证据不足而不是硬判。第二,任务失败不等于物理不可信:一个动作可能没达到目标,但过程中的物理行为完全合理;反过来,任务成功了,如果过程中出现明显违规,也要扣分。

这两条约束让 DP 和 ISR 变成一组互补而不是重复的指标。后面在结果里能看到,这个区别被真实数据支撑住了。

执行协议:先校准,再放机器人上去

要让"场景导致失败"和"控制器导致失败"分开,光有任务集还不够。论文的做法是先在正控制场景上校准执行策略:在执行前,用可控场景验证 Franka Panda 的开合页动作和推刚体动作确实能完成规定交互(图 3),确认之后再把这套已验证的策略套到生成场景上,并做目标级别的准备,包括物体绑定、接触几何检查和机器人位姿摆放。整个过程里,生成场景的原生物理属性和预定义成功判据都不动。

每次交互都从原始场景状态独立开始,执行结束后松开或撤回执行器,再做 5 秒的交互后沉降,然后以 12 FPS 录制交互视频供后续打分。缺目标或缺原生物理能力的任务标为 N.S.A.。所有仿真都在 Isaac Sim 5.1 里跑,渲染那一路用 Blender。

图 3|正式评测前在可控场景上做的执行策略校准:左边是开合页动作,右边是推刚体动作,用 Franka Panda 验证通过后才套到生成场景上(原文 Figure 5)

图源:ScIntBench: Physical Interaction Plausibility in 3D Scene Generation(arXiv:2610.37326v1),arXiv 非独占许可

语义与静态那两套指标:沿用,但改了细节

五视角语义评分

语义这一路沿用 SceneWeaver 的协议,但把视角从俯视扩展成一个俯视加四个角视角,一共五个视角,每张图 1024×1024。俯视负责全局布局,四个角视角负责减少遮挡、把单一视角下说不清的空间关系补出来。

多模态大模型把五张图和原始文本描述、结构化的几何布局信息放在一起,打四个 0 到 10 的分:Real(真实感,明确忽略材质、光照和门)、Func(功能性,房间是否支持预期的活动)、Lay(布局,位置、朝向、体量是否合理)、Comp(完整度,物件和细节是否够)。评分指令要求严格:只要发现关键问题------缺关键物体、明显布局错误、不真实的元素------分数就要显著压低,哪怕其他方面没问题。

几何检查与被动稳定性

静态物理这一路由四个指标组成,全部沿用已有实现,论文只做了必要的适配:

  • COL(碰撞率)用 SceneEval 的基于网格的碰撞检测,包括它那个 5 毫米的接触过滤流程:一对初始就相交的物体,只有在把两者临时拉开、观察相交是否仍然存在之后,才会被算作真碰撞。这个检查在检测副本上做,不改动生成场景。
  • OB(越界)同样用 SceneEval 的检测器,在每个物体网格表面采样点、向下投射射线到评测地面,如果不到 99% 的采样点能打到地面,就判为越界。
  • SUP(支撑)分两步:先用 GPT-5.6 从多视角视觉证据判断每个物体的期望支撑类型(地面、物体、墙面、天花板四选一),再用改造过的射线接触检测器验证对应的几何支撑关系。
  • STAB(被动稳定性)沿用 SAGE 的判据:每个场景在重力下模拟 120 个物理步,位移超过 0.2 m 或朝向变化超过 8° 的物体判为不稳定。

需要说清楚的是:这四个静态指标在这篇论文里不是创新点,也不是结论所在。它们存在的意义是当对照------正因为有了这一组"业界标准"的静止时刻指标,后面那句"静态分高不等于能用"才有说服力。

图 4|十二个方法的任务结局分布:右侧七根柱子整根是"不支持",五种能执行的方法里成功比例最高的是 Claude Code 的 36.9%(原文 Figure 6)

图源:ScIntBench: Physical Interaction Plausibility in 3D Scene Generation(arXiv:2610.37326v1),arXiv 非独占许可

结果:静态最干净的系统,交互最差

一眼就能看出的反差

论文在正文里直接把 SAGE 和 Holodeck 拎出来做对照。SAGE 的静态物理是全场最好的:碰撞率 0.41%、越界 0.00%、被动稳定性 98.33%,但它的交互成功率只有 11.54%。Holodeck 的静态成绩明显更差------碰撞率 14.86%、被动稳定性只有 51.43%,交互成功率反而是 17.39%。

这不是统计噪声的问题,而是两个指标测的东西根本不是一回事。静态分高,只能说明这个场景在没人碰的时候是干净、稳定、合法的;它完全不约束"有东西碰上去之后会怎样"。SAGE 的场景干净,一种可能的解释是它的物件更少更规整、可动的机构也更少------干净和可交互,在生成模型这里可能是互相拉扯的。

十二个系统的全景

先看语义那四维(原文 Table 2 的前半段),三个梯队很清楚:

  • 三个任务专用生成器(ATISS、DiffuScene、InstructScene)在语义上就没过线,功能分只有 1.13 到 1.40,碰撞率却高达 35.14% 到 59.20%。
  • 四个 LLM 或 VLM 工作流(LayoutGPT、LayoutVLM、Holodeck、HSM)语义好一些,功能分 3.60 到 4.30,但几何仍然脏,越界率最高到 37.80%,支撑正确率最低只有 14.13%。
  • 两个智能体流水线加两个编码 agent 才是 6 分以上的档位,Claude Code 与 Codex 在真实感、功能性、布局三项上都到了 6.73 到 8.87,SceneSmith 是智能体流水线里最好的一组。
方法 Real ↑ Func ↑ Comp ↑ Lay ↑
ATISS 3.00 1.13 1.80 1.93
DiffuScene 3.87 1.30 2.13 2.53
InstructScene 3.33 1.40 2.00 2.20
LayoutGPT 2.90 3.60 1.90 2.40
LayoutVLM 3.07 4.03 2.10 3.00
Holodeck 4.07 3.80 3.13 2.97
HSM 4.13 4.30 3.57 3.50
SceneWeaver 4.40 5.10 3.30 4.90
SAGE 4.83 4.37 4.83 2.90
SceneSmith 6.78 6.93 5.17 6.00
Codex 6.73 8.57 4.43 7.50
Claude Code 7.33 8.87 4.60 7.77

静态物理这一栏单独看(原文 Table 2 的后半段):SAGE 与 Claude Code 的碰撞率只有 0.41% 和 0.81%、被动稳定性 98.33% 和 94.75%,Codex 的 3.04% 与 97.46% 也在同一档;七个方法的稳定一栏是 N.S.A.,能测出来的五个里 Holodeck 只有 51.43%。

方法 COL ↓ SUP ↑ STAB ↑ OB ↓
ATISS 59.20 27.52 N.S.A. 27.04
DiffuScene 41.58 65.14 N.S.A. 14.69
InstructScene 35.14 62.30 N.S.A. 23.22
LayoutGPT 23.83 14.13 N.S.A. 37.80
LayoutVLM 33.89 74.66 N.S.A. 18.70
Holodeck 14.86 37.41 51.43 4.76
HSM 14.08 74.24 N.S.A. 10.36
SceneWeaver 6.94 4.38 N.S.A. 2.68
SAGE 0.41 77.42 98.33 0.00
SceneSmith 9.33 96.03 76.98 5.03
Codex 3.04 83.66 97.46 2.19
Claude Code 0.81 92.83 94.75 0.67

再看交互那四栏,画风立刻变了。把每个方法的三种结局(成功、执行了但没成功、不支持)铺成柱状图(图 4),最右侧七根柱子会整根变成灰色------那七个方法 100% 的任务都落在"不支持"里,连一点被评判的机会都没有:

方法 ISR ↑ ICP ↑ PIV ↓ DP ↑
ATISS 0.00 0.72 N.S.A. N.S.A.
DiffuScene 0.00 0.84 N.S.A. N.S.A.
InstructScene 0.00 0.77 N.S.A. N.S.A.
LayoutGPT 0.00 2.00 N.S.A. N.S.A.
LayoutVLM 0.00 2.00 N.S.A. N.S.A.
Holodeck 17.39 4.28 7.33 5.88
HSM 0.00 1.50 N.S.A. N.S.A.
SceneWeaver 0.00 1.80 N.S.A. N.S.A.
SAGE 11.54 5.50 1.10 6.21
SceneSmith 27.40 6.43 4.35 6.57
Codex 27.75 6.56 6.89 6.53
Claude Code 36.92 7.35 12.52 6.43

把静态那张表的 STAB 一列和交互这张表对起来,会发现一件事:被动稳定性记为 N.S.A. 的七个方法,正好就是交互成功率为 0 的那七个。这说明它们的问题不是"交互动作没做好",而是生成的场景根本不具备可仿真的物理属性------连在重力下放 120 步都做不了,谈不上推一把。论文正文把这一类归因写成"场景不支持物理仿真"。

交互排序跟着功能语义走,不跟着稳定性走

论文里有一个相当有意思的相关性观察:在 5 个真能执行交互的方法里,ICP 的排序与 Func 的排序完全一致,ISR 也基本同序(例外是 SAGE 和 Holodeck 这一对互换了位置)。而 ICP 与 STAB 之间没有这种整齐的对应关系------SAGE 的稳定性 98.33 是全场最好的,ICP 却排在倒数第二。

作者由此提出一个解释:功能性合适的场景内容,对物理交互能否发生可能比对被动稳定更关键。直觉上也说得通------一个场景要先有对的东西、对的空间关系,才有"可被交互"的余地;被动稳定只保证初始状态不塌,不保证任何动作能发生。这条解释还是相关性层面的,论文没有做因果实验,但方向足够明确,值得写下来。

通用编码 agent 的位置:语义第一,完整度垫底

最出人意料的可能是两个通用编码 agent 的表现。Claude Code 在 Real、Func、Lay、ISR、ICP 五项上都排第一,Codex 在 Func、Lay、ISR、ICP 上排第二。它们没有专门的场景生成模型,靠的是用建模工具写程序性地构建场景,却把一堆专用流水线甩在了后面。

但它们在 Comp 上明显吃亏:Claude Code 4.60、Codex 4.43,都低于 SAGE 的 4.83 和 SceneSmith 的 5.17。作者的解释也直白:功能上的一致性做得好,不等于场景里东西多。编码 agent 生成的房间功能对、格局对,但相对空旷,架子上的小物件、支撑面上的摆件都少。这反过来也解释了为什么它们的功能语义分很高------空房间里摆几个关键家具,功能判据当然容易满足。

下表的时间单位是分钟、API 成本单位是美元,都是单场景均值。代价方面,两个编码 agent 大约是每个场景 28 分钟,远低于 SAGE(235.13 分钟)和 SceneSmith(174.34 分钟)。论文同时提醒,运行时受硬件和实现差异影响很大,这组数不能当严格的速度对比。完整的开销统计是这样:

方法 时间均值 时间范围 API 均值
ATISS 0.19 0.15--0.27 0
DiffuScene 0.53 0.51--0.55 0
InstructScene 0.05 0.03--0.06 0
LayoutGPT 0.30 0.16--0.67 0.20
LayoutVLM 0.88 0.66--1.03 0.14
Holodeck 3.00 2.10--3.83 0.07
HSM 8.48 3.32--16.90 0.56
SceneWeaver 84.29 5.45--209.63 0.46
SAGE 235.13 176.00--370.00 0.80
SceneSmith 174.34 101.70--455.42 10.18
Codex 27.77 22.15--36.66 5.99
Claude Code 28.00 16.38--53.32 3.02

最后两行的 API 成本是按记录的 token 用量、分别套用 OpenAI 与 Anthropic 的价目估算出来的,其余方法也都是通过 API 调用外部语言或视觉模型。把这张表和上面的交互成绩放在一起看,会得到一个挺尖锐的对照:SceneSmith 是单场景 API 成本最高(10.18 美元)的方法,交互成功率 27.40%,还低于每场景 3.02 美元的 Claude Code。

定性对比:图上能直接看出的差别

论文给了两组定性对比。一组是 7 个方法在 4 条提示词下的生成结果(图 5),另一组是 12 个方法在 2 条提示词下全部铺开(图 6)。这两张图最直观的用处不是分出高下,而是让人看到同一句"一间有双人床、床边有小冰箱、门对面有桌子、床上方墙上有画"的描述,被不同范式兑现成了差异极大的房间:有的只有几件家具摆在大片空白里,有的塞满了装饰但空间走不通,有的家具正确却缺少可交互的细节。

图 5|七种方法在四条提示词下的场景对比:同一句描述被兑现成的房间,在体量、密度和可交互细节上差别很大(原文 Figure 2)

图源:ScIntBench: Physical Interaction Plausibility in 3D Scene Generation(arXiv:2610.37326v1),arXiv 非独占许可

图 6|十二种方法在客厅与厨房两条提示词下的全部结果:专用生成器往往只剩几件家具,编码 agent 房间里东西明显更少(原文 Figure 7)

图源:ScIntBench: Physical Interaction Plausibility in 3D Scene Generation(arXiv:2610.37326v1),arXiv 非独占许可

四种可复现的崩法

可见的门,不等于能开的门

第一种崩法最典型,也最能说明 availability 和 reliability 的区别。论文给了一张四列两行的对照图(图 7),同一个"打开冰箱"任务,SAGE 生成的场景里冰箱摆得很好看,但完全没有可动的铰链,交互直接记为不支持,ICP 只拿到 2 分------目标存在,但缺少动作所需的物理结构。这不是执行失败,是根本没有执行的前提。

SceneSmith 和 Codex 的场景迈过了这一关,门确实能转,但转不动:峰值开启角分别是 0.47° 和 0.11°,而判据要求 ≥60°。两者的 ICP 都是 6 分------交互已启动,有有效响应,但在取得实质进展之前就停住了。只有 Claude Code 达到了 67.96°,ISR 记为成功,ICP 满分。

三种结局,三层含义:一个是根本没能力,一个是能力在但执行推进不下去,一个是真做成了。ISR 把前两个都记成 0,ICP 把它们分成 2 和 6。这张图是整篇论文最值得反复看的一张,因为它同时展示了指标设计的必要性。

触发了但推不动

第二种崩法出现在推动类任务上。同一个"把桌子推 15 厘米(上下浮动 2 厘米)"的任务,SAGE 推了 15.70 cm、SceneSmith 14.47 cm、Claude Code 14.60 cm,都算成功;Codex 的场景里位移是 0.00 cm,机器人的手确实碰到了桌子,但没有产生任何有效位移,ICP 6 分。

值得注意的是这里出现了一个反转:SAGE 在开冰箱任务上一败涂地(2 分),在推桌子任务上却满分。这提醒读者不要把一个方法的交互能力当成单一标量------同一个系统在不同动作族上的表现可以完全不同,而这恰恰是"按动作族分别设计任务"的价值。

成功也会留下烂摊子

第三种崩法只有在有了 PIV 之后才看得见。Claude Code 的交互成功率最高(36.92%),但它的执行后违规率也最高,12.52%。反过来,SAGE 的违规率最低(1.10%),可它完成的任务少得多。

这两件事并不矛盾:一个场景被推、被开的次数越多,场景里其他物件被牵连的机会就越多。一个"什么都不敢动"的场景天然违规率低。所以 PIV 必须和 ISR 一起读------单看 PIV 会把"不敢交互"误读成"物理完整"。论文在指标定义里也明确处理了这层关系:PIV 只在有效执行过的任务上算,报告平均值时要同时给出覆盖率。

非目标物体才是真正的受害者

论文的失败模式图里有一幕很直观:推椅子的动作执行完之后,原本好好放在桌上的两本非目标书掉到了地上。这不是目标物体位移错了,而是非目标物体失去了支撑关系。PIV 的判据正是为这类情况设计的------检查的是全场景所有物体,而不只是目标物体。

这一条对下游的杀伤力可能比前几条都大。如果你的场景是用来训机器人策略的,目标物体被推对位置只是任务成功的一半;另一半是这个过程里没有把别的什么东西搞坏。真实房间里,一次推挤连带掉东西就是失败,而现有语义和静态指标完全看不见这一幕。

最后一层是 DP 给出的。DP 最高的是 SceneSmith(6.57),不是交互成功率最高的 Claude Code(6.43)。也就是说,任务完成度和"过程中物理像不像真的"是两件互补的事,一个方法可以在一个维度上领先而在另一个维度上落后。论文把这层关系写得很清楚,也正好解释了为什么它要同时保留一个状态判据指标和一个感知判据指标。

图 7|两行四列看同一个动作的三种结局:开冰箱时 SAGE 缺铰链、SceneSmith 只到 0.47°、Codex 只到 0.11°、Claude Code 到 67.96°;推桌子时 Codex 位移 0.00 cm(原文 Figure 3)

图源:ScIntBench: Physical Interaction Plausibility in 3D Scene Generation(arXiv:2610.37326v1),arXiv 非独占许可

指标本身可信吗:参照场景与人工对齐

拿真实的交互式场景当参照

一个新指标最大的风险是"它测的其实是仿真器或评审模型的偏好"。论文做了两组验证。第一组是拿真实的交互式参照场景跑同一套任务:BEHAVIOR-1K 的策划交互仿真、ReplicaCAD 与 iGibson 的扫描重建场景。挑的是与输入描述相似、并且含相关交互目标的房间或区域,用固定的任务协议和成功判据测;BEHAVIOR-1K 上 7 个任务,ReplicaCAD 与 iGibson 各 3 个。三组参照场景的 PIV 都是 0.00,说明它们执行完不留违规。

参照场景集 参照 ISR 参照 ICP 参照 DP 生成最高
BEHAVIOR-1K 100.0 10.00 7.57 57.1
ReplicaCAD 66.7 8.00 7.00 33.3
iGibson 100.0 10.00 6.33 66.7

最后一列是生成方法在同一批任务上的最好成绩:BEHAVIOR-1K 上 57.1%,由 Codex 与 Claude Code 并列;ReplicaCAD 上 33.3%,SceneSmith、Holodeck、Codex、Claude Code 四个方法并列;iGibson 上 66.7%,是 SceneSmith。

这组数字的意义在于:同一套动作执行器、同一套成功判据,在参照场景上能拿到 100%、66.7% 和 100%,在生成场景上最高只有 57.1%、33.3% 和 66.7%。差距不是执行器不会做,而是场景本身撑不住。ReplicaCAD 的参照场景也只有 66.7%,说明这套判据并不是"放水给参照场景"------真实现场也有做不到的任务。

与人工评分对齐

第二组验证针对两个靠多模态大模型打分的指标:ICP 和 DP。三位标注员各自独立评了 100 个交互案例,样本来自不同生成方法、覆盖不同动作类型与执行结果,用的是和多模态评审完全相同的量表(ICP 六级、DP 0 到 10,且允许标注员指出"视觉证据不足")。标注界面把目标视角与总览视角的同步视频、动作意图、成功判据、以及物理属性与测量值放在同一屏(图 8)。

结果是:ICP 与人均人类评分的 Spearman 秩相关 0.5126、Kendall τ 0.4654;DP 是 0.4169 与 0.4215。这个量级应该被诚实地读成"中等一致",而不是"高度一致"。ICP 比 DP 稳一些,也符合直觉:ICP 更多依赖可核对的状态与几何事实,DP 依赖对视频里物理过程的判断,后者的主观空间更大。

换句话说,ScIntBench 的交互结论在排序层面站得住(大差距不会被评审噪声翻过来),但如果你要拿单个场景的 DP 分去做精细比较,误差是不小的。这一点论文没有回避,人工验证的全部意义就是把这层不确定性摆出来。

图 8|人工评测界面:左边是目标视角与总览视角的同步交互视频、动作意图与成功判据,右边是 ICP 六级量表与 DP 零到十分的两套打分(原文 Figure 8)

图源:ScIntBench: Physical Interaction Plausibility in 3D Scene Generation(arXiv:2610.37326v1),arXiv 非独占许可

局限与失效场景

动作库只有三类,覆盖不到真实操作的大半

这是最实质的限制。整篇论文的交互结论建立在三个动作族上:开合页、推刚体、探表面。它没有覆盖抓取与放置、抽屉的直线拉出、旋转把手、按压开关、把物体从一个支撑面搬到另一个支撑面、以及任何多步长程任务。

而且这个动作库的边界是被明确写死的:开合只针对"正常带铰链的封闭体或门",抽屉式储物柜的一般性打开不在其中。这意味着一个"抽屉做不出来"的系统,在这套基准里不会被记为失败------它在任务构造阶段就被排除了。反过来说,这篇论文测出的交互就绪度,是一个下界,不是全景。真实机器人操作里最常见的抓放、多步任务、需要双臂协同的动作,这里都没有对应指标。

单一仿真器,加上"不补物理属性"带来的归因灰区

所有交互都在 Isaac Sim 5.1 里跑,接触模型、摩擦模型、求解器参数都来自这一个实现。论文对此是透明的,但也意味着某些失败可能带有仿真器特异性:一个在 Isaac Sim 里推不动的门,换一个接触参数更宽松的仿真器可能就推动了。论文没有做跨仿真器的对照,所以"某个系统的接触设置不对"和"这个场景的几何本来就没法接触"这两种情况,在结果层面没有被完全分开。

更麻烦的是 N.S.A. 这个标签把两件事合并了:缺目标物体 和缺原生物理前提。前者是语义层面的失败,后者是物理元数据层面的失败,修法完全不同。论文在 1534 个不支持实例上没有做这个拆分统计,所以读者无法知道这 1534 个里到底有多少是"该有的东西没有",多少是"东西有但不能动"。从那张对照图(图 7)里"冰箱有但没铰链"的案例看,后者恐怕占了相当比例,但这只是推断,论文没有报告。

多模态评审的天花板

四个指标里有两个(ICP、DP)由多模态大模型打分,其中 DP 的分数几乎完全由感知判断决定。人工一致性只有中等(ρ 0.42 到 0.51),意味着单场景的 DP 值有相当的不确定性;而在只有 30 条提示词的规模下,方法之间的 DP 差距(比如 6.53 与 6.57)远小于这个不确定性,不应该被当成有意义的名次差。

另外,评审用的 rubric 极其严格,措辞里反复强调"分数必须挣来""单次重大违规就封顶在 3 分以下"。这种严格对区分度有好处,但也可能引入系统性的保守偏差------一个所有方法都被压在 6 分左右的指标,用来排序是有效的,用来判断"离可用还有多远"就不一定准。

提示集与任务粒度的边界

30 条提示全部来自 SceneEval,10 类房间每类 3 条。这个规模足够撑起方法间的横向比较,但不足以支撑更细的结论,比如"哪一类房间最难做成交互就绪"。论文也没有按房型拆解交互成绩。

任务粒度上,203 个任务摊到 30 条提示词,平均每条 6.8 个单步任务;每个任务独立从原始场景状态开始,动作结束后做 5 秒沉降就结算。这个设计保证了可比性,但也意味着它测不到"连续操作下的累积劣化":真实使用中,一个房间会被反复推、反复开,第一次没事不代表第十次没事。这类长程劣化在这套协议里是看不见的。

落地判断:谁该信、谁别信、先做什么

拿生成场景训机器人策略的团队:不要把语义榜当就绪证书

如果你正在做的事是"用生成的室内场景当仿真环境,在上面训策略或者做评测",这篇论文给的信息很直接:

  • 你手上那套场景,很可能有超过一半的"场景 × 交互"组合根本不可执行。这篇论文的样本里这个比例是 1534/2436,超过六成。
  • 即使是最好的系统,规定动作的成功率也只有 36.92%;静态物理最干净的系统只有 11.54%。
  • 更危险的是失败归因:如果环境本身就撑不住这些动作,你在这种环境里测出来的策略成功率,混合了"策略不行"和"环境不行"两种原因,而且无法拆分。SAGE 那种"碰撞率 0.41% 却只有 11.54% 交互成功"的组合,最容易让人误判。

具体做法上,至少在把场景喂给策略训练之前,先跑一遍按动作族的可用性检查:目标在不在、有没有铰链、能不能被推动、推动之后周围的东西还在不在原位。这套检查不需要完整的 ScIntBench,但需要它那个思路------任务先固定,再拿场景去碰。

做场景生成的团队:把 availability 当成一级指标

这篇论文对方法研究的启示,是别再把"渲染好看"和"初始物理合法"当成收敛信号。数据上很清楚:

  • ICP 的排序和 Func 的排序在 5 个可执行方法上完全一致,和 STAB 不一致。这意味着优化功能语义(场景里该有的东西都在、空间关系对)比优化被动稳定更接近"可交互"。
  • 交互失败的第一大原因是缺原生物理前提,不是执行不稳。这指向资产层与元数据层:铰链、关节、质量、摩擦这些字段的完整性,比再换一个更强的布局模型更影响下游可用性。
  • 编码 agent 在语义与交互上都领先,但完整度明显落后。这是一个明确的改进方向:把"物件丰富度"和"可交互性"一起优化,而不是二选一。

做 3D 资产与 articulation 标注的团队:这是被点名的瓶颈

论文把最大的失败来源指在了"缺铰链、缺物理元数据"上。对做资产库、articulation 标注、物理属性估计的团队来说,这几乎是一份需求说明:可交互的封闭体需要有可动的铰链轴,落地刚体需要有合理质量与摩擦,支撑面需要有可接近的水平区域。这些字段在纯视觉的资产库长期是缺失的,而它们是交互就绪度的前置条件。

只做图、只做视频的团队:影响有限

如果你的目标是出渲染图、出漫游视频、做虚拟拍摄,这篇论文的结论基本不适用。它测的是物理交互,而这类应用不需要门能开、椅子能推。反过来说,如果你在宣传里用"仿真就绪""可用于具身智能"这类措辞,而手上只有语义和静态指标,那这篇论文正好是那句话的反例。

一个具体的动作:先测 ICP,别只测 ISR

如果只从这篇论文里拿走一个工程习惯,我建议是这个:在评测交互能力时,先测"能不能"再测"成不成"。ISR 是一个二元指标,它把"没有铰链"和"铰链被推了 0.47 度"压成同一个 0,而这两件事的修复成本差一个数量级。ICP 的六级量表虽然要靠多模态模型打分、有噪声,但它至少能把"根本不会"和"差一点"分开------在你只有几十个场景要评估的时候,这一层区分比小数点后的成功率有用得多。

术语速查表

指标、标签与动作族

术语 含义与在本文里的作用
interaction readiness(交互就绪度) 场景能否支撑真实物理交互的综合属性,被拆成可用性与可靠性两层
interaction availability(交互可用性) 场景里是否存在支撑某动作的前提,如铰链、可推刚体、可接近的水平面
interaction reliability(交互可靠性) 前提存在时,动作执行过程与结果在物理上是否靠谱
ISR(Interaction Success Rate) 规定任务的成功比例,二元判据,缺目标或缺前提直接记 0
ICP(Interaction Capability Progress) 六级量表 0/2/4/6/8/10,把目标缺失、目标存在、可交互、已启动、实质推进、成功分开
PIV(Post-Interaction Physical Violation) 执行后新增或恶化的违规物体占全场景物体的比例,越低越好
DP(Dynamic Plausibility) 从交互视频判断物理可信度的 0 到 10 分,因果、接触、重力、摩擦、铰链五个维度
Real / Func / Lay / Comp 五视角语义评分的四维:真实感、功能性、布局、完整度
COL / OB / SUP / STAB 静态物理四指标:碰撞率、越界、支撑、被动稳定性
N.S.A.(not support interaction) 缺目标物体或缺原生物理前提,交互无法执行;与"执行失败"不是一回事
open hinged / push rigid / place push probe 动作库的三个族:开合页、推刚体、放置并推动探针
正向控制场景(positive-control) 正式评测前用于校准执行策略的可控场景,用来分离控制器失败与场景失败
settling(沉降期) 动作执行后松开执行器、等待 5 秒让场景自然静止,再判定违规

一次评测的完整流程

把前面几节拼起来,单个场景的一次交互评测长这样。这张流程图里的每一步都在正文里出现过,放在一起是为了看清楚指标之间的依赖关系:PIV 依赖沉降后的状态比对,DP 依赖执行过程的录制,而这两者都只在"真的能执行"时才存在。

text 复制代码
仅示意:单场景单次交互的评测流程(非原文代码)
输入:p 提示词,m 方法,S 场景,T_p 任务集
1 五视角渲染:俯视 + 4 角视角
2 MLLM 打分 Real/Func/Comp/Lay
3 COL 5 mm 接触过滤后计碰撞
4 OB 不足 99% 射线命中地面
5 SUP 支撑类别 + 射线接触
6 STAB 重力 120 步
7 for t in T_p:
8   缺目标或缺物理前提?
9     是 → N.S.A.,ISR=0,ICP 取 0 或 2
10  否 →
11    绑定物体、检查接触、摆机械臂
12    执行开合页/推刚体/推探针
13    松开、沉降 5 秒、12 FPS 录像
14    ISR:判据是否满足
15    ICP:MLLM 六级量表
16    PIV:违规物体 / 全部物体
17    DP:MLLM 看录像打 0 到 10
18 场景内聚合,再跨场景等权平均

回到开头。这篇论文真正的贡献不是给出了一个"谁最好"的排名------它的排名里最好也只有 36.92%,本来就不适合当排行榜读。它的贡献是把"仿真就绪"从一个形容词变成了四个可以测的量,并且用数据说明这组分数不能被另外两组替代------静态物理近乎满分的系统,交互可以只有 11.54%。对一个正在把生成场景往机器人策略训练里塞的团队来说,这个结论比任何一次成功率提升都更值得先处理。

参考

论文内引用到的相关工作

  • 评测与基准:SceneEval、SceneWeaver、SceneCritic、LEGO-Eval、VWE-Bench、3DTindo-Bench、AuthorBench、Code4Scene
  • 被评测的场景生成系统:ATISS、DiffuScene、InstructScene、LayoutGPT、LayoutVLM、Holodeck、HSM、SAGE、SceneSmith、Codex、Claude Code
  • 仿真与参照场景:Isaac Sim、Blender、BEHAVIOR-1K、ReplicaCAD、iGibson
相关推荐
咬代码的兽1 小时前
智元创新日拆解:机器人开始按工时结算,Token之后有了Worken
机器人
OpenAnolis小助手1 小时前
多租户公有云共享 CXL 内存池场景下的内存卸载研究
人工智能·操作系统·龙蜥社区·risc-v·agentic os
趣味科技v1 小时前
具身智能从“演示”走向“部署”:智元把机器人送进真实工位
机器人·具身智能·智元
xsd202411181 小时前
OCEC 24×40 开闭眼脑电分类:从 α 波节律到实时 BCI 落地方案
人工智能·1024程序员节
Ivanqhz1 小时前
MoE + LLM 应用
数据库·人工智能·pytorch·python·深度学习·算法·1024程序员节
Agent世界1 小时前
摩尔线程开源万卡训练底座:大模型 MoE 训练的四个开关
人工智能·开源·moe
l1m0_1 小时前
AI设计工具有哪些?Paico、Pixso AI、墨刀AI、Lovable、Codex怎么选
前端·人工智能·ai·设计·墨刀·codex·pixso
Wanda12141 小时前
机器人与机电一体化3D数字孪生机器-Day9
人工智能·3d·unity·机器人·数字孪生
聆思科技AI芯片1 小时前
【AI硬件开发上手教程】怎么使用AI编程实现小聆AI语音控制舵机
人工智能·嵌入式硬件·开源·ai编程·智能硬件