「你这个底座铺到哪了」要用两把尺子分开答：量「现在能不能用」——能，它是一个完整可用的自部署 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
评估一个 3D 世界的成本，不能只问报价——它的成本结构分三类：随访客线性增长的（带宽、实时算力，首屏实测 838KB/99 请求、加载 1.7 秒）、几乎恒定的一次性投入（性能治理、资产管线、多端适配、实时通信接入；灯池消掉 8989ms 全场冻结、预热预算把长帧压到 500ms 内、GLB 贴图 −68%~−92%）、以及规模越大越省的（世界里的 AI 不渲染画面，服务器只发 JSON：每 Agent 约 1KB/s，100 个 Agent 占 0.079 核 CPU、92MB 内存，observe P50 7ms）。文中给出四个可直接使用的评估问题，以及四类「看起来省钱、实际推高成本」的动作。
3D 世界成本结构、带宽成本优化、首屏体积优化、3D 带宽预算、服务器渲染成本、AI 接入成本、自部署 3D 成本、draw call 优化、实时通信带宽、性能治理
引擎升级是最像自找麻烦的一件事，但收益具体：颜色管线正确（r128 的双重 gamma 让画面偏亮偏粉）、WebGL2 能力面、不依赖外部 CDN。本文是一次真实换代的完整实录：esbuild 自建 UMD bundle 顶替旧文件名，六类加载器逐个本地化/stub 化，three-shim 垫片补 87 个符号（只补签名不补行为），patchTHREE 兼容层把旧 outputEncoding/texture.encoding 真映射到 colorSpace，79 处遗留 API 清单化治理。验证方法是先立 10 张统一口径基线截图再用自研 PSNR/diff 工具比对——后台 43.4dB 一致，主世界差异全部归因于颜色管线正确化。另配 webgl2Guard 加载前检测，不支持 WebGL2 时全屏中文提示而非白屏。
Three.js r185 升级、Three.js 版本升级、WebGL2、颜色管线、色彩管理、three-shim 垫片、去 CDN 化、离线部署 3D、渲染内核换代、浏览器 3D 兼容性
Mixamo、Ready Player Me、VRoid、RootMotion 四条来源的角色模型放进同一个 3D 世界，问题集中爆在骨骼上：骨架命名、坐标轴、动画约定各不相同，导出工具还会留下副本骨骼链。本文拆解一套翻译层做法：容器旋转归一、动画约定补偿、重复骨骼链换绑并同步逆绑定矩阵、词边界命名匹配，每层带安全门——补偿后 rest 异常即拒补偿、换绑后 IBM 变差即回滚，配合 _diag 诊断接口。实测轨道命中 33/33、312/318，51 骨模型逐模型补偿 10/10，骨骼套件回归 67/67。翻译层只治约定差异，不治源文件本身的内容错误。
Mixamo 骨骼、Ready Player Me 集成、VRoid 导出、RootMotion 动画、骨骼动画兼容、动画重定向、GLB 骨骼修复、Three.js 角色动画、自部署 3D 世界角色
浏览器端 3D 世界规模一大就卡：提交次数、灯数变化触发重编译、主线程解析、着色器编译、加载期白屏。本文拆解一次完整治理的五处改动——几何合批（密集区 draw calls 3064→837，−73%）、12 盏常驻灯池（灯数变化冻结 8989ms→0）、GLB 解析入 Worker（23/23）、预热预算每帧 170ms（出生点首进 worst 386ms、>500ms 长帧 0）、全图占位场（1071/1071 覆盖），并给出三条可复用的判断：visible=false 不可当成本判据、把不可控的驱动行为变成可预算资源、观感与性能不冲突。全部指标来自仓库里可重跑的 54 个验收脚本。
draw call 优化、Three.js 性能治理、浏览器 3D 卡顿、着色器编译卡顿、GLB Worker 解析、3D 性能预算、几何合批、WebGL draw call、自部署 3D 世界