The measured Three.js/Babylon.js comparison and the case for a compiled artwork format. · Rendered from docs/decisions/0003-engine-bakeoff-and-lpr.md in the project repository · view as Markdown

ADR-0003：引擎对照闸门与 .lpr 标准运行时

• 状态：采用
• 日期：2026-07-31
• 取代：ADR-0002 中“Pilot 已选定 Three.js”的部分

决定

1. TypeScript + Vite 继续作为 Web 应用、编辑器、compiler 和权限/AI 工作流底座。
2. 3D 引擎在 Three.js 与 Babylon.js 完成相同技术切片后选择；Babylon.js 是标准引擎优先候选，Three.js 是控制力和性能基线。
3. .lpp 只作为创作源。新增无任意代码、版本化、renderer-neutral 的 .lpr（Lucas Painting Runtime）编译产物。
4. 先建立 Canvas2DReferenceRenderer，再在获选 3D 引擎同一 GPU context 内建立 GpuArtworkRenderer。
5. 3D 世界与 2D 作品只能通过版本化、白名单、限频 signal/event 协议交互。
6. 第一版之前保留所有 Painterly Chameleon 继承内容；清理是通过产品闸门后的独立阶段。

原因

Three.js 可以实现目标，但需要自行组装较多游戏引擎能力。Babylon.js 提供更标准的 Web 原生相机、碰撞、动画、DynamicTexture 和 RenderTargetTexture。实测可以避免把“更灵活”或“更标准”当作未经验证的信念。

更换 3D 引擎本身不会解决 Live Painting 的主要性能风险。解决路径是把 authoring source 与 runtime 分离，在 compiler 中烘焙静态内容、限制动态数据，再由中央 scheduler 和 GPU renderer 统一执行。

选择规则

• 两者都通过且 Babylon.js p95 frame time 在 Three.js 的 10% 以内：选 Babylon.js。
• Three.js 在 p95 frame time、内存或 texture upload 上好 15% 以上，或 Babylon 阻碍 .lpr GPU path：选 Three.js。
• 两者都失败：先隔离 artwork、upload 和 world rendering 成本，不直接跳 Unity/Godot。

完整任务、指标与验收条件以 docs/INCEPTION-SPACE-EXECUTION-PLAN.zh-en.md 为准。