Codex 室内建模实测暴露资源体积隐账

Codex 能配合 img2interior，把一张客厅参考图做成可编辑的 Blender 场景，也能导出放进 Three.js 的模型。但这次跑通靠的是反复审图、Windows 兼容修正和查看器修复，不能当作「一张图、一句提示、一次成功」的证明。

最值得程序员关注的是交付成本：运行时 GLB 只有 2.67 MB，加上必需资源却达到 95.10 MB；另一个可独立使用的静态版本是 8.80 MB。生成模型只是起点，资源依赖、浏览器生命周期和接入验证才决定它能否进入项目。

它是在重建房间，还是编写一个近似场景？

img2interior 是让 Agent 编写 Blender 场景的工作流，不是把图片直接变成网格的预训练模型。作者在当前 Codex 桌面对话中，调用包内可复用的几何辅助函数，写了针对这间客厅的 Python builder，没有使用自带的 Oak/Linen 房间配方，也没有运行 Claude Code。

输入是一张 2752×1536 的合成客厅图。作者以约 3.1 米长的沙发估算尺寸，最终得到 131 个网格、46,544 个三角形和 12 个语义组件，包括房间外壳、家具、玻璃、窗帘、UV 与灯光。原生场景使用 Z-up，glTF 导出使用 Y-up。

这套流程生成了可以继续修改的场景结构，但遮挡区域和相机仍靠人工设定，没有实测尺寸，也没有精确重建的主张。

图里的几何装饰画、均匀石材、简化软包和树木，就是还原的边界。能识别为同一类空间，不代表材质、尺度和隐藏结构都可靠。

第一次原生渲染花了 5.44 秒，但镜头过近，桌子和椅子被裁切。作者拒绝这个结果，经过两轮修正，调整取景、前侧隐藏空间和家具比例，再检查正面、侧面、背面及织物视图。

这次验证证明了流程可以经过修复交付，没有证明首次生成的可靠性。

Windows 上跑通，具体修了哪些地方？

测试环境是 img2interior 0.3.1、img2 CLI 0.4.0、Python 3.11.14、bpy 4.3.0 和 NumPy 1.26.4，硬件为 Windows 11、Ryzen 9 9950X、RTX 5070 Ti。浏览器是通过 ANGLE D3D11 运行的 Chromium 155，Codex CLI 版本回读为 0.144.1。

三个问题都与运行环境有关。

首先，继承的 OCIO 环境变量让 Blender 指向不兼容的工作室色彩配置。作者只在场景创作子进程中清除 OCIO，保留工作站原设置。其次，导出器在源图 URL 中写入了反斜杠，查看器拒绝加载；本地改用 Path.as_posix() 后恢复。

第三，Python 3.12 返回的路径与文件状态 ctime 不一致，触发文件变更审计。相同检查换用 Python 3.11 后通过。交付契约还把盘符路径识别成了 URL，需要换成等价的相对根路径。

安装检查也有边界：隔离测试环境里的 Doctor 是零失败、零警告，sync 是零漂移，但作者没有证明用户重启 Codex 后，新宿主一定能发现已安装的 skill。

下载包保留 builder、输入、生成的亚麻贴图、打包主文件、便携模型和查看器补丁；参考图、环境、生产花园植物及大型运行时附属资源没有打包。重建还要单独安装锁定版本的官方工具包。

这对日常 AI 编程很有参考价值：Agent 写出的脚本能执行，只覆盖了一部分验收。解释器差异、路径格式和宿主发现机制，都可能让另一个人的环境失败。

为什么 2.67 MB 的模型，实际需要 95.10 MB？

作者交付了三种用途不同的产物：

产物	用途	使用边界
打包 Blender 主文件	继续编辑场景	是创作源文件
运行时 GLB	完整 PBR 查看器	依赖光照贴图、反射探针和查看器集成
便携 GLB	导入其他场景	自包含，但外观为静态烘焙

运行时 GLB 是 2.67 MB，加上必需的光照贴图和反射探针，声明总量为 95.10 MB。便携 GLB 为 8.80 MB。这些都是十进制 MB 和文件字节统计，不是冷启动网络传输实测。

烘焙是在纹理里预先存好光照结果。五组完整光照与环境光烘焙耗时 193.17 秒，基础分辨率为 1024，织物和室外几何使用 2048，配置为 32 samples 与 OpenImageDenoise；1024×512 的反射探针另花 6.61 秒。这些只是阶段计时，没有覆盖完整安装和生成过程。

便携版内嵌五张静态图片，使用 unlit 材质显示烘焙外观。它不携带当前浏览器中的织物效果、实时窗帘状态或动态重打光能力。在线预览也只在用户点击按钮后加载这个文件，不会加载整套 95 MB 资源。

作者把便携版接进真实 Digital Garden 渲染器。花园使用 Three.js 0.186.1，原 PBR 查看器使用 0.180.0；模型以 scale 1 导入，方向正确，无须额外旋转。但原有植物穿进了房间，静态光照也无法跟随花园太阳变化。

两个花园渲染路径都碰到约 60 Hz 的显示上限，不能据此判断哪个后端更快。采样画面有 175 次 draw call、约 1215 万渲染三角形，且包含渲染通道。性能结论必须连同统计口径一起看。

验证能加载，还要验证旧实例不会干扰新实例

作者用新的 Blender 进程重新打开主文件，并独立导入、渲染便携模型。两个最终 GLB 都通过 Khronos validator，零错误、零警告，查看器实际下载文件的哈希也与最终产物一致。

UV、颜色和坐标往返检查报告零误差；另一个 256×192 的浏览器校准场景，相对原生预期渲染的平均绝对 RGB 差为 0.003818，范围是 0–1。它验证光照贴图传递，不能拿来证明沙发还原得像。

交互部分测试了两片窗帘的低、中、高位置和下摆，共八组双向拖拽释放，另有两组固定上摆检查。一次竖直拉动让中部移动 76.37 mm、较高位置移动 5.09 mm、固定顶部保持 0 mm；最大可移动抓取点误差为 3.86 mm，低于设定的 5 mm 门槛。

真正值得前端开发者关注的是生命周期漏洞：旧 canvas 已经脱离页面，迟到的 context-loss 事件仍能把新查看器置为错误状态。作者在销毁时移除旧键盘和 context 监听器，并让 context 处理函数检查会话归属。修复后，对旧 canvas 派发相同事件，新查看器仍保持就绪，相机也没有变化。

实际 WebGL 丢失、manifest 请求被阻断、atlas 请求被阻断，均能通过 Retry load 恢复。修复后八个审查阶段和三个阻断门禁全部通过，但门禁检查的是顺序与字节，具体交互行为仍靠浏览器观察确认。

移动端证据有限。390×844 布局模拟没有横向溢出，额外触摸和取消处理使用 DOM PointerEvents，部分隐藏暂停检查使用临时恢复的 getter/event。没有连接实体手机。

我的判断

我认可作者把失败和修复保留在结果里。对 AI 生成工作流，交付边界比成品截图更有参考价值：文件能否独立打开、依赖是否齐全、旧实例是否清理，都影响后续维护。

但这里没有与手工建模或其他方案的对照数据，也没有完整耗时、每轮 token 和成本基线。因此，「适合拿来做近似房间的可编辑起点」是合理经验；「能降低多少成本」「换张图还能否成功」，目前无法量化。

便携版减少接入依赖，同时放弃动态光照和实时织物能力。完整运行时保留更多表现，却带来明显资源负担。原文没有执行另一个优化流程，不能替它推算压缩空间。

另外，源码可获取不等于 OSI 开源。测试包采用 img2 Interior Free Use, Restricted Commercialization License 1.0，输出、运行时及第三方资源条款仍需分别确认，参考图也没有因此获得重新授权。

能拿来做什么

• 在 Three.js 中验证场景接入时，先用自包含的便携 GLB 检查比例、朝向、占地和穿插，再判断是否需要完整运行时能力。
• 给 AI 生成的三维资源建立完整依赖清单，把 GLB、光照贴图和反射探针一起统计，避免用主文件大小代替加载预算。
• 给频繁挂载和销毁的 WebGL 组件补上旧实例事件回归测试，重点检查监听器清理、会话归属和失败重试。
• 把场景质量与工程正确性分开验收：独立打开、格式校验和资源哈希通过后，仍需审查还原程度，并在实体手机上验证交互。