2.67MB模型为何拖95MB运行时？

一个房间，131个网格、46544个三角面、12个语义组件。导出的运行时GLB只有2.67MB，但把必需的灯光贴图和反射探针算进去，声明的总量是95.10MB。另一份独立的便携GLB是8.80MB。这三个数字放在一起，就是这次测试里最实在的发现。

测试对象是img2interior，版本0.3.1，配套img2命令行工具0.4.0，Python 3.11.14，bpy 4.3.0，NumPy 1.26.4。工作站跑Windows 11，Ryzen 9 9950X加RTX 5070 Ti，浏览器是Chromium 155，走ANGLE D3D11。Codex在桌面会话里运行，命令行版本回读为0.144.1。

需要先说清楚它是什么。img2interior不是预训练的图像转网格模型，而是一套用来编写Blender场景的智能体工作流。测试里没有调用它自带的Oak/Linen房间配方，也没有跑Claude Code，而是用包里可复用的几何辅助函数，写了一个针对这张参考图的Python构建器。

参考图是项目公开的合成客厅图，2752×1536像素。尺寸以约3.1米的沙发为锚点，按米估算。隐藏的结构和相机位置属于作者设定，不是测量结果。原生编写用Z轴向上，glTF导出用Y轴向上。

三处Windows上的干预

隔离环境里注册包之后，Doctor返回零失败零警告，sync返回零漂移。这只验证了隔离夹具，不能证明新重启的用户Codex宿主发现了已安装的技能。真正需要动手的是三个Windows问题：

• 继承下来的OCIO设置把Blender指向了不兼容的影棚配置。只在编写子进程里清掉OCIO，预检通过，工作站的设置保留。
• 导出器在源图URL里写了反斜杠，查看器直接拒绝。用Path.as_posix()修掉这个字段，原值留着可回滚。
• Python 3.12报告的路径stat和文件stat的ctime不一致，触发了文件变更审计。换回Python 3.11跑同样的检查就过了。交付契约还需要一个等价的相对根路径，因为它的盘符路径被归类成了URL。

渲染、否决、修复、烘焙

第一次原生渲染花了5.44秒。结果被否决：相机太近，桌子和椅子被裁掉。两轮修复调整了取景、隐藏的前厅范围和家具比例，在最终烘焙前检查了正面、侧面、背面和织物视图。

五个完整/环境光烘焙组共耗时193.17秒，基础分辨率1024，织物和室外几何用2048，32采样，OpenImageDenoise降噪。一个1024×512的反射探针又花了6.61秒。这些是分阶段实测，不是完整的搭建或生成计时。

UV、颜色、坐标的往返误差为零。另有一个匹配的256×192浏览器校准夹具，在0到1尺度上对原生预期渲染的平均绝对RGB差为0.003818。这检验的是灯光贴图传输，不是和参考沙发像不像。

两份最终GLB都通过了Khronos校验器，零错误零警告。全新的Blender进程重新打开主文件、独立导入便携模型，各自渲染。完整查看器的实际下载与最终主文件和便携文件的哈希一致。

便携版和运行时版是两种契约

便携模型内嵌五张静态图，用无光照材质呈现烘焙外观，近处表面细节比原生/运行时PBR版本更软。它不携带当前的浏览器织物效果、实时窗帘状态或动态重打光。在线静态预览只在明确点击按钮后加载这份未改动的便携GLB，不会加载那95MB的运行时集合。

把便携GLB放进现有的Digital Garden渲染器时，用的是Three.js 0.186.1，而原来的PBR房间查看器用0.180.0。房间以缩放1导入，直立，不需要额外旋转。两条花园路径都撞上了显示器约60Hz的上限，这不能说明哪个后端更快。采样到的花园视图报告175次绘制调用、约1215万个渲染三角面，包含渲染通道。

导入暴露了一个摆放问题：现有植物穿进了房间。散布被保留下来，生产安装需要预留占地。线上花园没有为这个实验房间做改动，它的便携烘焙光也无法跟随花园的太阳。

布料、下摆和一个生命周期bug

桌面端后续测试了低、中、高三处织物点和两块面板的下摆：八个双向拖拽/释放用例，外加两个固定上摆检查。射线命中数据确实把part=hem识别了出来，布料命中没有被改标成下摆结果。远端下摆一开始被沙发挡住，处理方式是挪到清晰视角，而不是放宽遮挡检查。

一次单独的垂直拉伸中，导轨覆盖率保持为零，中间探针移动76.37毫米，较高探针移动5.09毫米，固定的顶部为0毫米。可移动保持点的最大观测误差为3.86毫米，低于设定的5毫米阈值。相机变换/投影和UV0/UV1指纹保持不变，渲染出的世界顶点与求解器在Float32精度内吻合。

原生指针捕获丢失、画布外释放、可信的浏览器失焦、Source模式切换、真实离屏暂停、风关闭休眠、页面退出与返回，全部通过。真实导航产生了pagehide和hidden事件，并移除了旧画布。隔离的hidden暂停测试用了恢复的临时getter和事件，因为应用内浏览器的非活动标签页仍然可见。额外的触摸/取消处理器用的是DOM PointerEvents。这两项模拟都不是真机证据。

测试找到了一个真实的生命周期bug：已分离的旧画布上迟到的上下文丢失事件，可能把替换它的查看器打进错误状态。修复方式是在销毁时移除旧键盘和上下文监听器，并用会话归属守卫上下文处理器。修复后重新派发同样的旧画布事件，新查看器保持就绪，相机不变。

真实的WebGL丢失、被拦截的清单请求、被拦截的图集请求，都通过“重试加载”恢复。修复后八个审查阶段和全部三个阻断门通过。门检查的是顺序和字节，浏览器观察确立的是限定范围内的行为。

它适合拿来做什么

这个可编辑项目适合当作一个近似房间的起点，尤其是当你想要一个构建器和一份能继续改的Blender场景。审查和修复仍然是工作的一部分。几何造型、软包、木材、石材、室外树木和光照都明显被简化了。

在把它当作生产花园资产之前，需要改进重建质量、预留占地、削减运行时体积、完成真机检查。390×844的布局模拟没有横向溢出，但没有连接实体手机。也没有完整的搭建计时或每次运行的token/成本基线。

至于它能不能在Codex里跑通：在这台Windows机器上跑通了，靠的是新写的构建器、多轮渲染迭代、本地兼容性修改和一次查看器修复。这不能证明它在其他图片或全新宿主安装上具备未经改动的首轮可靠性。

许可方面，被测包在img2 Interior Free Use, Restricted Commercialization License 1.0下源码可见，不是OSI开源许可。输出、运行时和第三方条款需要自行阅读。这次测试没有对参考图或工具包重新授权。