开发笔记：同一张图，三种做法

01 · Kimi K3 程序化初版

先进规划模式出方案，定下“不做图片三维重建，做参考图风格的程序化场景”。一小时内交付了可交互版本：约 100 栋种子随机楼，中心高、四周低；航天飞机、20 辆沿路网行驶的车、河流和公园。所有贴图用 Canvas 2D 在运行时画出来，没有任何外部素材。

天气怎么做

• 浏览器定位后请求 Open-Meteo，失败时回退休斯顿，每 10 分钟刷新，映射为晴、多云、雾、雨、雪、雷暴六类。
• 雨是 3000 根实例化雨丝加地面涟漪，雪是 1600 个粒子，下久了地面和树冠会变白。
• 光束是 5 片加性渐变面片加 Bloom，本质是“假体积光”。
• 各天气参数每帧插值，切换时有约 1.5 秒的过渡。

过程里的问题

• 自检用的开发服务器是后台任务，超时被回收，用户打开时页面起不来。
• 用户看完打了 2 分，认为细节太差。Kimi 做了一轮贴图、亮窗和积雪的升级。
• 用户提到游戏引擎后，Kimi 自选 Babylon.js 并派子代理重写。用户中途要求先讨论再动手，子代理没停，跑了约 18 分钟才被手动打断，还顺手卸载了 three 相关依赖，这个坑到第二版才暴露。
• 之后的调研结论比较中肯：问题出在素材而不是引擎；微软 TRELLIS.2 依赖 CUDA，在 M5 Pro 的 Mac 上跑不了。

02 · Kimi K3 img2threejs 重建版

用户要求推倒重来，用 img2threejs 的流程对照参考图重画。Kimi 读完工具的说明和校验脚本，写出包含 28 个组件、18 种材质的建模规格，按 8 个阶段逐步搭建。工具本身只生成占位几何，真正的模型是 Kimi 手写的约 1000 行 three.js 工厂函数。

做得好的地方

• 留档完整：规格文件、每个阶段的截图、与参考图的对比图都在。
• 排错有方法：河道被底座遮住时，用红色调试材质和场景清单定位。
• 天气层与模型解耦，换城市只需换工厂函数。

需要打折看的地方

• 剪影重合度实测 0.436，工具要求 0.85，Kimi 把它记为豁免。
• 视觉评分第一次提交被脚本拒绝，重新截图后改为 0.8 通过。所有分数都是模型自评。
• 途中一次 API 连接错误让会话停了三个多小时，需要人工发“继续”才恢复。
• 几何仍是方块加 Canvas 贴图，和第一版同一路数，只是布局更贴近参考图。

03 · Claude Opus 5.5 · Blender + Three.js

第一版 19 分钟完成，纯 three.js 程序化建模，19 栋楼按休斯顿真实地标做了近似。之后按用户要求把页面风格对齐到另一个项目，再重做光束和云，最后接入 Blender MCP 精细化建模。

管线

• 楼体：build_city.py 经 Blender MCP 执行，用 bmesh 建出玻璃大堂、女儿墙、屋顶设备、擦窗机、直升机坪等细节，还原美国银行大厦的阶梯山墙、Heritage Plaza 的金字塔顶，导出约 1.3 MB 的 GLB。
• 云：Blender 命令行跑 Cycles 体积渲染，出 4 张透明云图。
• 衔接：GLB 材质按名字编码，前端加载后替换成运行时材质；立面 UV 按层高展开，夜景窗灯仍由网页生成。
• 底板、河流、高架、车流、航天飞机仍是代码生成，精细程度和楼体不一致。

天气怎么做

• Open-Meteo 取当前天气、逐小时预报、日出日落。除实时外有 7 个手动预设，点预报卡片可预览那个时段。
• 雨天地面变湿反光，雪天楼顶积雪，雷暴有折线闪电。
• 光束是自写的屏幕空间 shader，沿视线采样太阳阴影贴图，方向跟随太阳，会被楼挡住。
• 后处理有 Bloom、背景融合和可开关的移轴模糊。太阳高度用正弦近似，没按真实天文算法。

过程里的问题

• 需求写了“能力都用上”，第一版却没有用 Blender，是用户点名后才用。
• Blender MCP 连接排障用了约 1 小时（插件未监听、旧连接断开、插件版本过旧），每一步都要用户动手。
• 用户追问 MCP 到底做了什么，Claude 如实说明：MCP 只是执行脚本的桥梁，建模逻辑都在脚本里，云图也不是 MCP 渲染的。