「你这个底座铺到哪了」要用两把尺子分开答：量「现在能不能用」——能，它是一个完整可用的自部署 3D 虚拟世界基底，渲染内核（Three.js r128→r185/WebGL2/去 CDN 化）、资产管线（LOD 118 组、GLB 贴图 −68%~−92%、3DGS 26/26）、性能治理（draw call 3064→837、灯池消掉 8989 毫秒冻结）、多端适配、实时通信（弱网自愈 9/9）、AI 接入（每 Agent 约 1 KB/s、100 Agent 实测 0.079 核）、跨世界联邦（同名自动改名 4/4）这些层今天就在跑，全部有可重跑的验收脚本背书；量「方向还能走多远」——按这个方向最终能长成的形态估，底座覆盖 5%–8%，这两句话必须一起读：底座完整可用，且空间还剩九成以上，数字表达的是机会不是欠账。往上走有四件规划项（AI 拼装世界、Agent 商店、Agent 互操作 A2A、跨世界联邦 AI），文中逐项列了「依赖的底座能力已通到哪、还差哪段」，并明确声明全部尚未实现、不要当已上线功能评估。第 5 层业务逻辑（展厅、培训、社区世界）现在就有完整落地面。
3D 虚拟世界底座、自部署 3D 世界、Three.js 基座、浏览器端 3D、3D 世界开发、AI Agent 接入、跨世界联邦、私有化部署 3D、虚拟世界路线图、MCP Server
手工建模的东西再多也有「模型感」，实拍扫描的场景自带实景质感——3D 高斯泼溅（3DGS）补的就是「能走进去的实拍场景」这一格。这篇讲我们在自家浏览器端 3D 虚拟世界底座里自研 3DGS 的完整取舍：为什么不接现成库（依赖纪律 + 管线一致性，GLSL1 在 r185/WebGL2 下自动编译通过、伽马不双重编码已实测确认），工程上做了哪四件事（二进制 PLY 解析含球谐系数 f_rest_0..8、BufferGeometry+ShaderMaterial+Points 一次上传全量 GPU、世界生命周期接入（占位/dispose/摆回占位）、资产库化即上传即入库），支持 .rad/.ply/.spz/.splat/.ksplat 五种格式、验收 26/26 与 24000 点真实绘制、零第三方 3DGS 库依赖。同时如实交代：验收样本是脚本生成的 INRIA 标准 62 属性 PLY，真实扫描数据的端到端实测未做；大规模高斯点的弱设备帧率未完整实测；3DGS 没有可编辑网格，碰撞与交互资产仍应使用几何模型——3DGS 负责「像真的」，几何模型负责「能碰能改」。
3D 高斯泼溅、3D Gaussian Splatting、3DGS 浏览器渲染、实拍场景 3D、实景扫描、Three.js 3DGS、PLY 解析、球谐系数、自部署 3D 虚拟世界、实景展厅
跑了几年的 3D 世界几乎必然长出孤儿资产——上传了没用的模型、删了引用没删的文件，以及更隐蔽的一类：glTF 系资产是「JSON 元数据 + BIN 缓冲」分离结构，删动画只改 JSON 不重建 BIN，就会在文件内部留下永远没人读的孤儿字节。这篇讲我们对自家浏览器端 3D 虚拟世界做资产盘点的完整过程：方法是用引用清单对磁盘清单求差集、人工抽查后再动手；结果是场景资产库找出 159 个孤儿文件共 2.9GB，目录从 3.1GB 瘦到 390MB（已完成）；角色模板库 205.5MB 中有 79.3MB 结构级孤儿（集中在 4 个文件、最严重一件 93.4% 是垃圾），方案已定但尚未执行——清理后跨世界首屏预估从几十秒降到 1~2 秒，这是预估值不是实测值，文中如实区分「做完的」和「算清楚还没做的」，并解释了为什么后者先不动（重建 BIN 有写风险、收益未实测、30 天强缓存会放大操作风险）。
3D 资产管理、孤儿资产清理、GLB 资产优化、3D 虚拟世界部署、glTF BIN 缓冲、资产审计、跨世界加载速度、Three.js 资产管线、3D 模型瘦身、自部署 3D 世界
做 3D 时「支持手机」通常被放到最后，而它不是重写一套的问题：桌面端独有的鼠标交互在触屏上不成立，手机独有的内存上限与切后台冻结在桌面端不会遇见。这篇给出「按能力分档、不按设备分叉」的做法——高/中/低/XR 四档在运行时探测，而不是按设备类型写三套工程；并逐终端列坑：手机内存比帧率更容易先崩（内存审计修了四项泄漏）、平板最被低估、桌面端的问题是你的开发机太好（靠 diagTurnLag 这类诊断接口而不是感觉）、XR 是唯一帧率不达标就不能用的终端。文中给出可复用的资产分档数据（LOD 118 组 ≤100 面、三角数 −71%~−87%、贴图 −68%~−92%、draw call 3064→837、占位场一个 draw call 覆盖 1071/1071）、预热预算（每帧 170 毫秒、首进最长 386 毫秒）、灯池（消掉 8989 毫秒全场冻结）、弱网重连自愈 9/9。同时明确交代：移动端与 XR 的实机帧率尚未完整实测，文中数字全部来自桌面端验收脚本。
3D 多端适配、浏览器 3D 移动端性能、手机 3D 卡顿、draw call 优化、LOD 资产分级、着色器预热、灯池、WebGL2 兼容、弱网重连、多人在线带宽预算、3D 内存泄漏
从零写一个浏览器端 3D 场景不难，难的是让它在真实设备和网络里站得住。这篇把从零造的四笔隐性成本逐条摊开：颜色管线双重 gamma（不报错，画面偏亮偏粉，用 10 张统一口径基线截图加自研 PSNR/diff 工具验，后台 43.4dB 一致）、加载与预热预算（每帧 170 毫秒份额结算、首进最长 386 毫秒、超 500 毫秒长帧为 0）、draw call 与灯池（3064→837、−73%；灯数不变后重编译归零，消掉 8989 毫秒全场冻结）、弱网重连自愈（9/9 重连后对端仍可见移动）。核心是四类问题都不会报错——所以从零造时它们很难变成待办事项。随后给出五层分层表：前四层与业务无关，放在基座里一次做完；第五层业务逻辑由你自己写。文中也写明这个决定在什么情况下是错的：一次性静态展示、以学习为目标、极低运行环境、做完即下线的项目。
3D 虚拟世界底座、3D 基座分层、从零开发 3D、draw call 优化、Three.js 性能治理、LOD 资产管线、弱网重连、自部署 3D 世界、浏览器端 3D 架构、AI Agent 接入 3D、3D 场景技术选型
模型太大导致的加载慢、进度条卡 90%、手机端闪退，根因往往在文件本身而不是代码。这篇讲一套跑在上传管线里的 GLB 手术做法：用 JSON + BIN 改写实现「几何一克不动」，贴图按用途分级处理（法线与遮罩无损重编码、基础色调色板量化），实测课桌 25.74MB→8.22MB（−68.1%）、20.7MB 多 buffer 4K 模型→4.38MB（−92.5%），PSNR 31.4dB、差异像素 0.35%。难点不在压缩而在二进制布局：bufferView 重排、accessor 索引重映射、meshopt byteOffset 平移、多 buffer 逐段核对。配套五重闸门（网格名/压缩/多 buffer/几何一致性/回读验证）确保失败宁可不落盘，实测变体贴图剥离 215 件 0 失败；面数由另一条工具链保证低模 118/118 ≤100 面，且变体共享高模材质几乎不增显存。
GLB 压缩、模型瘦身、贴图压缩、baseColor 调色板量化、PSNR 验证、模型 LOD、面数上限 100 面、3D 资产管线、浏览器 3D 加载优化、meshopt