面向多人创作者世界的浏览器 3D 开放世界技术

我们想把创作者放进一个共享的开放世界。不是大厅，不是画廊，而是一个活的 3D 空间，人们可以探索、建造，并偶遇彼此的作品。一个在浏览器标签里加载、感觉值得待的地方。

这是个难题。Skyrim 和巫师 3 花了几亿美元构建他们的世界，仍要在专用硬件上以几十 GB 磁盘容量发布。我们瞄准的是浏览器标签、数百玩家的共享状态、以及创作者能真正重塑的世界。

本指南记录了我们对这一技术的研究。今天可行的是什么，未来会有什么，什么样的架构能让我们到达那里。

从 Skyrim 和巫师中能学到什么

在挑选技术之前，先了解这两个最成功的开放世界究竟如何工作很有帮助。他们的技术意外地很好地映射到浏览器约束。

Skyrim 的 Cell 系统

Skyrim 的开放世界围绕玩家流送 5x5 cell 网格。远处的山是低分辨率假体。你根本注意不到。

Skyrim 把世界分成 57x37 个外部 cell 的网格，每个 4096x4096 游戏单位（大约 59 米）。引擎在任意时刻加载玩家周围 5x5 cell 网格。当你走动时，后缘的 cell 卸载，前缘的 cell 流入。内部空间（地下城、建筑）是通过门触发器加载的独立 worldspace。

这直接适用于浏览器世界。你不加载整张地图，而是加载玩家周围的邻域并随其移动交换块。关键洞见：Skyrim 从不让你看到远处地形的全部细节。它使用多分辨率方法。

Skyrim 的 LOD 分级：

• 1-2 cell 内全细节（玩家直接所在区域）
• 中距简化网格（物体丢失小几何）
• 中距以远树和岩石用广告板假体
• 地形 LOD 对远景使用预烘焙的低分辨率网格
• 物体淡出距离按物体调优（草最先淡出，建筑最后）

Skyrim 的地形使用基于高度图的地形，每 cell 32x32 顶点 patch。每个 patch 可以用 alpha 图混合不同纹理。这便宜易存储、易渲染。单个 cell 的地形数据以 KB 计，不是 MB。

我们能应用什么： 基于块的流送、高度图地形、激进的 LOD、内/外部分离，以及远处地形不需要几何精确、只要视觉上令人信服的理念。

巫师 3 的流送架构

巫师 3 的 136 平方公里世界使用内容感知流送。200m 以外的树是平的假体。建筑独立于地形流送。

巫师 3 的世界比 Skyrim 大（所有区域合计约 136 平方公里），使用更复杂的流送系统。CDPR 构建了自定义引擎（REDengine 3），世界分成流送扇区，不是严格的网格。

每个扇区包含内容层的层级：

• 地形作为带 4 个 LOD 等级的 patch 流送
• 植被使用 GPU 实例化和基于距离的剔除
• 静态几何（建筑、岩石）独立于地形流送
• 玩法对象（NPC、物品、触发器）基于任务状态和距离加载

渲染器使用基于物理材质的延迟着色。一个特别相关的技巧：巫师 3 大量使用假体。200 米外的树不是带枝叶的 3D 模型，而是始终面向相机的纹理四边形。引擎从多个角度预渲染这些假体，随相机移动交换。你完全注意不到，因为它们足够远。

世界组合： 巫师 3 的开放世界由独立团队同时分层构建。地形团队雕塑景观，环境艺术团队放置结构，任务团队接线触发器和 NPC 路径。这种分层组合系统让大团队能不互相干扰地工作。

我们能应用什么： 分层世界组合（对创作者平台至关重要）、远距物体的假体渲染、多光源的延迟渲染，以及流送应是内容感知的洞见（不要加载看不到的内部，不要生成不在附近的 NPC）。

旷野之息的化学引擎

BotW 在平板级硬件上运行，画面惊艳。卡通渲染风格、水彩远景雾、系统化交互压过脚本内容。是风格化开放世界的金标准。

任天堂对开放世界设计的方法颠倒了通常的公式。他们没有用脚本内容填满世界，而是构建系统化规则，让玩家发现涌现行为。火蔓延到草。金属在雷雨中导电。风带动物体。一切都通过一致的物理/化学层与一切交互。

这对创作者世界很重要，因为它表明世界本身可以比任何放置的物体更有趣。如果创作者能定义材质属性和交互规则（不只是放置静态网格），世界就获得涌现行为，让即使没人明确设计的区域也值得探索。

BotW 的技术要点：

• 相对低的多边形数和分辨率（Switch 上 dock 模式 900p）。风格化的卡通渲染外观掩盖了低保真。今天的浏览器世界可达到类似视觉质量。
• 远距渲染使用卡通着色雾，淡入水彩风格天空盒。便宜渲染，实践中漂亮。这种空气透视在片元着色器中基本免费。
• 世界约 84 平方公里但稀疏。地图大部分是可穿越地形，兴趣点散布其上。密集内容保留给城镇和神庙。这种「稀疏但有趣」的方法相比巫师 3 的密集 Novigrad 大幅减少资产需求。
• 物理对象有材质标签（木、金属、食物、爆炸物），决定交互。实际规则数小（约 20-30 种交互类型），但它们以感觉无限的方式组合。

GTA V 的世界分层

GTA V 的 Los Santos 感觉鲜活，因为分层的环境系统：交通、行人、昼夜、天气。远处建筑是合成照片，不是 3D 模型。

Rockstar 对 Los Santos 的方法教了另一课。GTA V 的世界感觉鲜活，是因为分层环境系统，不是因为每个 NPC 都有任务。

城市有交通系统模拟数百辆道路网车辆。行人走路线、对玩家反应、彼此交互。一天的时间改变人口密度、出现的 NPC 类型和环境活动。天气影响驾驶物理和 NPC 行为。

对创作者世界，洞见是环境生命造就博物馆与场所之间的区别。即使是简单行为（鸟飞过、波浪拍岸、NPC 在建筑间走动）也创造活世界的错觉。

GTA V 的技术要点：

• 地图 75 平方公里，使用激进的 LOD 和基于速度的流送系统（开车快比走路加载更远）。
• GTA Online 同时把 30 玩家放进这个世界。即使 30 人，Rockstar 也发现需要空间兴趣管理：你得到附近玩家的详细更新，远玩家的更新较少。同样原则适用于我们 200 玩家目标。
• GTA V 的资产流水线是有史以来最高效的之一。整个游戏装在约 80 GB，因为极端纹理压缩、网格共享和程序化细节。他们的建筑内部大量复用模块化部件。
• 游戏使用复杂的假体系统，远处建筑实际是合成的平照片。玩家注意不到，因为过渡距离针对特定视角调优。

艾尔登法环的无缝开放世界

艾尔登法环的 79 平方公里地图混合稀疏开放地形和密集手工地下城。同样的环境资产以不同布置出现到处。当构图和光照变化时，重复消失。

FromSoftware 在与黑暗之魂相同的引擎上构建艾尔登法环，但扩展到开放世界。结果有趣，因为它显示了一个相对小的团队（与 Rockstar 或 CDPR 相比）如何构建大型开放世界。

诀窍是密度变化。艾尔登法环的地图巨大（约 79 平方公里），但大部分是带散落敌人和兴趣点的开放地形。密集的手工内容（如 Stormveil 城等遗产地下城）嵌入开放世界，并使用 Skyrim 同样的内外分离。

艾尔登法环的技术要点：

• 世界以大瓦片流送。骑马你能看很远，但远地形极简化。近处细节与黑暗之魂 3 相当。
• 加载屏只在快速旅行或进入某些地下城时出现。开放世界本身无中断流送。
• 游戏大量复用环境资产。同样的树模型、岩石形态和废墟件以不同布置出现在地图上。有足够多样的布置和光照，重复就不明显。这直接适用于创作者世界，模块化部件库可生成无限变化。
• 多人是基于会话的（召唤其他玩家进你的世界），不是持久的。但异步功能（消息、血迹、其他玩家的幽灵）创造共享存在感，无持久服务器的网络开销。这些环境多人功能在浏览器世界中实现成本低廉。

无人深空：程序化一切

从共享种子生成 1800 京颗星球。每个玩家看到同样的宇宙，无需服务器存储。基地构建数据紧凑：部件 ID 加变换。

无人深空是程序化生成的极端案例。从共享种子生成 1800 京颗星球，每个玩家看到同样的宇宙，无需任何存储在服务器上。

生成流水线分阶段工作：星系级种子决定恒星位置，恒星种子决定行星数量和类型，行星种子驱动地形生成（多 octave 噪声）、群落分配、动植物物种、调色板和资源分布。一切从种子确定性计算，所以两个访问同样坐标的玩家看到同样的行星，无需交换任何行星数据。

无人深空的技术要点：

• 地形生成使用基于体素的 marching cubes 和噪声函数栈。这允许高度图地形无法表示的洞穴、悬挑和漂浮岛屿。代价是每块更高的计算成本，但结果是视觉上更有趣的地形。
• 基地构建系统最接近我们设想的东西。玩家放置的结构在服务器上持久，对其他玩家可见。基地数据紧凑（带位置和旋转的部件列表），当有人访问该行星时按需流送。
• 游戏最初因尽管无限变化但内容重复而被批评。基于种子的生成可产生无限地形但有限惊喜。教训：程序化生成适合画布，但创作者放置的内容才让一个地方感觉有设计有意图。
• Hello Games 在发布多年后加入了多人。最多 32 玩家共享会话，带完整建造和探索。网络模型简单：一个玩家主机，其他连接。对带持久状态的浏览器世界，服务器权威模型更好，但无人深空证明共享程序化世界是可行的。

Minecraft：创作者世界的蓝图

销量 3 亿份。16x16 像素纹理。完全可编辑地形。无限生成。多人。创作者世界的最重要参考。浏览器克隆证明概念在 WebGL 中工作。

Minecraft 是我们构建之物最重要的参考点，比任何图形 AAA 都重要。销量 3 亿份。世界无限生成、完全可破坏、多人。创作者在 Minecraft 中不只是放置物体，而是重塑地形本身。

Minecraft 的技术要点：

• 世界分成 16x16x384 块块。只有玩家附近的块加载（渲染距离可配置）。这与 Skyrim 相同的块流送模式，但带完全可编辑地形。
• 每块作为调色板压缩的块 ID 数组存储。只有 5 种不同块类型的块每块存储 4 位调色板索引，而不是完整块 ID。这让块数据非常紧凑（压缩后通常每块 10-50 KB）。
• Minecraft 的多人协议有完善文档且相对简单。服务器随玩家移动发送块数据。块变化作为小 delta 更新（位置 + 新块类型）广播。这正是我们用于创作者编辑的模型。
• 游戏用 Java 运行，现在有 C++ 的基岩版。有基于浏览器的 Minecraft 克隆（ClassiCube、eaglercraft）证明核心概念在 WebGL 中工作。它们通常在 60fps 下处理 8-12 块渲染距离，提供约 200-400 米视野。
• Minecraft 的模组生态是其真正护城河。模组添加新块、实体、群落和玩法系统。对创作者世界，这表明可扩展性与基础体验同样重要。如果创作者能定义新交互类型（不只是放置物体），世界随时间变得更丰富。
• 红石（Minecraft 游戏内布线系统）显示，如果你给创作者简单可组合的原始体，他们会构建复杂系统。逻辑门、自动农场、计算器。简单规则集生成非凡复杂性。这与 BotW 化学引擎的教训一样。

AAA 开放世界的共同模式

回顾所有这些作品，相同的模式不断出现：

空间划分是普遍的。无论是 cell（Bethesda）、扇区（CDPR）、块（Mojang/Rockstar）还是瓦片（FromSoftware），每个开放世界都把空间分成可加载单元。没有引擎尝试在内存中保留整个世界。

多分辨率一切。 地形、网格、纹理甚至音频都有多个质量级别。你得到的分辨率取决于你有多近以及物体有多重要。

遮挡剔除比原始三角形吞吐量更重要。不渲染看不到的东西比优化能看到的省更多性能。Skyrim 用简单的基于距离的系统。巫师 3 用带大遮挡体（建筑、悬崖）的软件遮挡。像 UE5 的 Nanite 等现代引擎用硬件遮挡查询更进一步。

异步加载隐藏过渡。这些游戏不为开放世界显示加载屏（仅快速旅行或内部过渡）。它们在后台线程加载内容，并行解压，逐步交换新内容。

艺术指导胜过多边形数。 Skyrim 2011 年发布时图形即使在当时也朴素。BotW 在平板级芯片上运行且美观。Minecraft 使用 16x16 像素纹理，是有史以来最具视觉辨识度的游戏之一。对浏览器世界，这非常重要。低保真但艺术导向良好的世界总是胜过技术先进但艺术平淡的世界。

系统化设计胜过脚本内容。 BotW 的化学引擎、Minecraft 的块交互、GTA V 的交通系统都从简单规则创造涌现行为。这构建更便宜、运行更便宜，比手工脚本序列产生更多玩家故事。对创作者世界，系统化设计意味着即使没人明确设计的区域世界也保持有趣。

创作者放置的内容需要持久性和可见性。 Minecraft 基地、无人深空基地和 GTA Online 房产都跨会话持久，对其他玩家可见。创作者内容的数据模型始终紧凑（部件 ID + 变换），而视觉表示丰富（客户端把数据扩展为完整 3D 场景）。

渲染：浏览器实际能做什么？

Three.js

Three.js 是基础。它有最大的社区（GitHub 超 10 万星）、最多的例子，最广的兼容性。它抽象 WebGL 2，通过 WebGPURenderer 提供实验性 WebGPU 支持。

对开放世界，Three.js 给你：

• 实例化渲染用于植被、岩石和重复几何（InstancedMesh）
• LOD 系统内置（THREE.LOD 按距离交换网格）
• 视锥剔除每物体自动
• 地形通过自定义 BufferGeometry 或基于高度图的 PlaneGeometry
• PBR 材质通过 MeshStandardMaterial 和 MeshPhysicalMaterial
• 后处理通过 EffectComposer（bloom、SSAO、色调映射）
• 阴影贴图通过自定义代码可做级联阴影映射
• glTF/GLB作为主资产格式（紧凑、GPU 就绪）

Three.js 还有对开放世界重要的活跃工具生态。three-mesh-bvh 加速复杂网格上的光线投射和空间查询。postprocessing（vanruesc）提供比 Three 内置更高性能的后处理栈。three-gpu-pathtracing 启用参考质量渲染。

开放世界的限制： Three.js 没有内置场景图处理大规模流送、LOD 管理或空间划分。你自己构建。没有内置实体组件系统（ECS）、物理或地形系统。它是渲染器，不是引擎。这对自定义开放世界实际是优势，因为你控制内存布局和加载策略，但意味着更多前期工作。

const lod = new THREE.LOD();
lod.addLevel(highDetailMesh, 0);
lod.addLevel(mediumDetailMesh, 50);
lod.addLevel(lowDetailMesh, 200);
lod.addLevel(impostorSprite, 500);
scene.add(lod);

Babylon.js

Babylon.js 是另一主要竞争者。微软支持，对开放世界这一具体问题有比 Three.js 更深的内置功能。

相关内置功能：

• 基于八叉树的场景划分用于大场景的高效剔除
• Solid Particle System用于大规模实例化渲染
• 从高度图的地形带内置 LOD 和多纹理 splat
• 节点材质编辑器用于可视化着色器创建
• WebGPU 支持（比 Three.js 更成熟，因为 Babylon 更早投入）
• Havok 物理集成（Wasm 编译，生产质量）
• glTF 流送带渐进加载

Babylon 的 DynamicTerrain 扩展从高度图数据即时生成地形块，自动处理 LOD，支持纹理 splat。这比 Three.js 开箱即用的任何东西都更接近 Skyrim 所做。

const terrain = new BABYLON.DynamicTerrain("terrain", {
  terrainSub: 100,
  mapData: heightmapData,
  mapSubX: 1000,
  mapSubZ: 1000,
}, scene);
terrain.LODLimits = [4, 3, 2, 1];

权衡： Babylon.js 是更大的库（完整构建压缩后约 1-2MB，vs Three.js 约 600KB）。但对开放世界，你可能添加足够多的自定义代码到 Three.js，使大小差异变得可忽略。Babylon 还有自己的节点材质系统、检查器和开发工具，加速迭代。

PlayCanvas

PlayCanvas 值得一提，因为它是最经生产验证的 Web 优先 3D 引擎。Snap、Facebook 和众多广告客户都用它发布了复杂 3D 体验。引擎约 1MB，加载快，云编辑器启用协作世界构建。

具体对开放世界，PlayCanvas 提供绘制调用优化的批组、内置光照贴图器和高斯泼溅支持（与照相测量捕获的真实世界环境相关）。运行时紧凑，对移动浏览器优化良好。

WebGPU：性能解锁

WebGPU 改变了浏览器开放世界的等式。最重要的两个功能：

Compute shader 启用 GPU 侧地形生成、植被放置、粒子模拟，甚至简单物理。在 WebGL 世界中，所有这些在 CPU 上的 JavaScript 中运行。WebGPU 让你完全在 GPU 上生成地形 patch、在 GPU 上计算 LOD 过渡、在 GPU 上运行剔除 pass。这为网络、游戏逻辑和内容流送释放 CPU。

间接渲染让 GPU 基于 compute shader 输出决定绘制什么。你提交一次绘制调用，GPU 基于距离决定每个 LOD 等级渲染多少实例。这就是现代引擎处理数百万草叶或树的方式。没有间接渲染（WebGL 不支持），CPU 必须排序和批处理一切，在密集场景中成为瓶颈。

WebGPU 在 Chrome、Edge 和 Firefox 桌面端可用。Safari 支持部分。移动支持有限。对大多数用户在桌面浏览器的创作者平台，这可行。你在能力浏览器上运行 WebGPU，其他的回退到降低保真度的 WebGL 路径。

@compute @workgroup_size(64)
fn generateTerrain(@builtin(global_invocation_id) id: vec3<u32>) {
    let worldPos = vec2<f32>(f32(id.x), f32(id.y)) * cellSize + worldOffset;
    let height = fbmNoise(worldPos, octaves, persistence);
    heightmap[id.x + id.y * width] = height;
}

推荐的渲染栈

对面向桌面创作者的浏览器开放世界：

主要： Three.js 或 Babylon.js 在可用处使用 WebGPU 渲染器，WebGL 2 回退。Babylon 有更强的内置开放世界原始体。Three.js 有更大社区和更高灵活性。

我们的选择： Babylon.js 作为引擎核心，因为内置地形 LOD、八叉树剔除、Havok 物理（Wasm）和成熟的 WebGPU 支持。Babylon 缺乏处使用 Three.js 生态工具（例如空间查询的 mesh BVH）。在自定义世界流送层中包装一切。

世界流送架构

这是难的部分。浏览器标签在桌面上获得约 2-4 GB 内存（浏览器强制限制），移动上约 1 GB，且无直接磁盘访问。一切通过网络。你需要一种架构，把可见世界保留在内存中，同时仅在玩家移动方向前方流送内容。

基于块的世界网格

像 Skyrim 的 cell 系统，把世界分成规则块网格。每块是可独立加载、渲染和卸载的独立单元。

块大小很重要。 太小则不断加载/卸载带高开销。太大则每块下载时间过长。对带典型宽带连接的浏览器世界：

• 地面级 64x64 米块
• 每块包含：高度图 patch（2-4 KB）、纹理 splat 图（16-32 KB 压缩）、作为实例化引用的静态网格（1-50 KB 实例数据）、创作者放置物体作为清单（1-10 KB）
• 加载半径：5x5 块全细节（320m 视野）、9x9 中 LOD、17x17 仅地形
• 目标：每块全细节数据 200 KB 以下，所以 5x5 邻域 5 MB 以下

渐进加载流水线

不要一次加载关于块的一切。使用优先队列：

1. 先地形几何（仅高度图，每块 2-4 KB）。玩家在 100ms 内看到地面。
2. 地形纹理（splat 图，先低分辨率然后升级）。地面在 200ms 内有颜色。
3. 主要结构（建筑、大岩石）。轮廓在 500ms 内出现。
4. 细节物体（植被、小道具、创作者物品）。世界在 1-2 秒内填入。
5. 高分辨率纹理最后升级。如果远处建筑的纹理多花一秒没人会注意。

这符合人眼工作方式。我们注意缺失的地面和缺失的大结构。我们不注意缺失的草。

内存管理

浏览器内存有限，垃圾回收是你的敌人。一次 GC 暂停可能让你从 60fps 跌到那一帧的 10fps。

对象池是强制性的。为常见物体（树、岩石、草丛）预分配池，随块加载/卸载回收它们。永远不要在热路径中创建新的 THREE.Mesh 或 BABYLON.Mesh 实例。改在池对象上交换几何和材质引用。

纹理 atlas减少绘制调用和内存碎片。把所有地形纹理打包到几个大 atlas。把创作者上传纹理打包到服务端的每块 atlas，作为单图流送。

几何压缩用 Draco 或 Meshopt 把下载大小减少 5-10x，解压在 Web Worker 上运行不阻塞主线程。具体对地形，量化高度图（用简单 delta 编码压缩的 16 位值）比任何通用网格格式都小。

ArrayBuffer 所有权传输在 worker 和主线程之间避免复制。当 worker 解压网格时，用 postMessage 配合可传输对象把缓冲零拷贝传到主线程。

资产投递

CDN 边缘缓存用于静态世界数据。地形块、基础网格和不常变化的纹理 atlas 应被激进缓存（Cache-Control: max-age=31536000, immutable）。

内容寻址存储意味着每个资产版本在其 URL 中获得唯一哈希。当创作者修改块时，新版本获得新哈希，旧版本对仍在查看者保留在缓存中。无需缓存失效。

KTX2 纹理带 Basis Universal 压缩。它们解压到设备支持的任何 GPU 格式（BC7、ASTC、ETC2 或 RGBA 回退）。1024x1024 地形纹理从 4 MB 未压缩降到 KTX2 中约 150 KB。对带数千独特纹理的世界，这压缩是可行与不可行的区别。

**glTF Binary（GLB）**用于所有 3D 资产。它是 3D 的 JPEG。每个浏览器引擎加载它，紧凑，可在单文件中嵌入纹理、材质和动画。对网格压缩使用 Draco 或 Meshopt 扩展。创作者上传资产在服务端处理为优化的 GLB 然后进入世界。

多人网络

把数百创作者放进同一世界需要处理实时移动、持久世界状态和创作者编辑而不熔毁的网络架构。

服务器架构

权威服务器用于世界状态。浏览器不可信。所有有意义的动作（放置物体、修改地形、在块间移动）在服务端验证。客户端本地预测并与服务器状态协调。

空间分片把世界分到多个服务器实例。每个分片拥有世界网格的矩形区域。随着玩家密度变化，分片可分裂或合并。这是 EVE Online 在一个宇宙中处理数千玩家的方式，相同原则在更小规模适用。

对大多数交互是本地的创作者世界（你在你的区域建造，你的邻居能看到），空间分片自然工作。站在分片边界的玩家看到两个分片的内容，需要跨分片可见性查询，但这是已解决问题。

服务器技术选项：

技术	强项	用例
Cloudflare Durable Objects	边缘部署、自动扩展、内置持久化、WebSocket 支持	世界分片状态、每块权威
Hathora / Rivet	管理游戏服务器托管、DDoS 防护、全球部署	专用游戏服务器实例
Colyseus	用于 Node.js 的开源游戏服务器框架、基于模式的状态同步	带状态差异的基于房间多人
PartyKit	边缘部署、WebSocket + WebRTC、基于 Cloudflare Workers	实时协作、轻量多人
自定义 Rust/Go	最大控制、每实例最佳性能	需低延迟物理的高密度分片

我们的上下文（Cloudflare 基础设施）： Durable Objects 是自然适配。每个世界块成为持有该块内容权威状态的 Durable Object。玩家通过 WebSocket 连接到负责其当前块的 DO。当他们移到相邻块时，连接到那个块的 DO。Durable Objects 自动持久化状态到磁盘，所以世界数据在重启后存活。

客户端-服务器通信

WebSocket 用于可靠有序消息（聊天、世界编辑、库存、游戏状态）。每个玩家可见的活动分片一个连接（通常 1-4 个连接）。

WebRTC DataChannel 用于不可靠无序消息（玩家位置、动画、瞬态效果）。WebRTC 是点对点的，但对带许多玩家的世界，你会通过 SFU（Selective Forwarding Unit）运行以避免 N² 连接。Cloudflare Calls 或 LiveKit 可作 SFU。

状态同步使用 delta 压缩。服务器跟踪每个客户端已看到什么，只发送变化。对创作者世界，这特别重要，因为世界状态（什么物体存在、在哪里、有什么属性）变化比玩家位置频率低得多。你可以以 2-5 Hz 发送世界状态更新，玩家位置 20-30 Hz。

interface WorldChunkState {
  version: number;
  terrain: TerrainPatch;
  objects: PlacedObject[];
  creators: CreatorPresence[];
}

interface DeltaUpdate {
  chunkId: string;
  fromVersion: number;
  toVersion: number;
  addedObjects: PlacedObject[];
  removedObjectIds: string[];
  modifiedObjects: Partial<PlacedObject>[];
  creatorMoves: CreatorPosition[];
}

创作者编辑的冲突解决

当两个创作者同时修改同一区域时，你需要冲突解决策略。这是实时协作模型选择重要之处。

Last-write-wins 最简单。每个物体在任意时刻有单个所有者。如果你在编辑建筑，别人不能编辑它直到你释放。简单，无冲突，但限制协作。

Operational Transform（OT） 是 Google Docs 使用的。操作针对并发操作变换以产生一致结果。这对文本工作，但对 3D 空间操作变复杂。Figma 用这个变体处理其 2D 画布。

CRDT（Conflict-free Replicated Data Types） 允许并发编辑总收敛到相同状态而无需协调。对带离散物体（每个有 ID 和属性）的世界，每属性的 Last-Writer-Wins Register 配合物体集合的 Add-Wins Set 给你自动收敛。Yjs 和 Automerge 是用于 JavaScript 的生产质量 CRDT 库。

我们的建议： 对世界物体状态（什么存在、在哪、有什么属性）使用 CRDT，对空间验证（同位置无两物体、物体保持在世界边界内）使用权威服务器。CRDT 处理协作，服务器处理物理。

处理规模：多少玩家？

浏览器 MMO 今天存在。Hordes.io 在浏览器中一个场景运行 200+ 玩家。BrowserQuest（Mozilla 实验）用简单瓦片世界处理数百。问题不是浏览器能否处理多人，而是随玩家数上升你能保持什么视觉保真度。

玩家渲染预算： 每个可见玩家需要网格、动画和潜在的创作者定制外观。60fps 下你每帧有 16ms。合理预算：

• 50 个全动画近距离玩家：约 2ms 动画 + 蒙皮
• 200 个中距玩家（简化动画、实例化）：约 1ms
• 500+ 玩家作为小地图上的点/图标：可忽略

这给你一次视野中约 250 玩家的可见人口，对创作者世界绰绰有余。魔兽世界首都很少在一次视野中渲染超 200 角色。

网络预算： 每玩家以 20 Hz 发送位置约 40 字节 * 20 = 每秒 800 字节。200 个可见玩家：160 KB/s 位置数据。加上世界状态、聊天和创作者动作，你看每客户端 200-500 KB/s。在宽带能力内，但值得压缩。

地形系统

地形是任何开放世界的基础。它也是浏览器约束打击最重之处，因为地形需要无处不在且始终可见。

基于高度图的地形

像 Skyrim，使用高度图。2D 高度值网格通过顶点着色器生成 3D 地形。这比任意网格地形紧凑得多。

4096x4096 高度图在 16 位精度下未压缩为 32 MB。但你从不一次加载全部。每个 64m 块使用高度图的 65x65 段（16 位约 8.4 KB）。用 delta 编码和 zlib 压缩，你每块 2 KB 以下。

纹理 splatting 使用混合图绘制多种地形材质（草、岩石、土、沙）。每块有 4 通道 RGBA splat 图，每通道控制一种材质的混合权重。每个 splat 图 4 个纹理，加上每块改变 splat 图的能力，你在整个世界获得视觉变化。

现代地形渲染器使用虚拟纹理（也叫 megatexture，来自 id Software 在 Rage 中的技术）。不是运行时 splatting，而是以高分辨率预渲染混合的地形纹理，随相机移动流送其瓦片。这以存储换运行时性能。WebGPU 的 compute shader 可处理虚拟纹理所需的反馈和页表管理。

Clipmap 或 Geoclipmapping

对在浏览器中渲染大地形，CDLOD（C. Dick's LOD）或 geoclipmapping 方法工作良好。地形渲染为围绕相机的一组同心环，每环是前一环的一半分辨率。靠近相机你看到全分辨率地形。远处你看到更粗版本。过渡平滑，因为几何在等级间变形。

这技术 GPU 友好（每环一次绘制调用），以恒定内存处理无限地形，在 WebGL 2 中工作。这是 Flight Simulator 和大多数现代开放世界游戏在某种程度上使用的。

创作者修改的地形

如果创作者能雕塑地形，你需要在基础高度图之上存储和流送修改的方式。两种方法：

Delta 高度图存储基础地形与修改地形之间的差。世界大部分未修改（delta 为零），所以这压缩极好。加载块时，在基础上应用 delta。

体素叠加用于更戏剧性的修改（洞穴、悬挑、拱门）。高度图无法表示一点有两个高度的地形。仅在修改块中存储的稀疏体素网格处理这个。Marching cubes 或 dual contouring 生成网格。这更昂贵但启用 Minecraft 风格地形编辑。

AI 驱动的世界生成

这是 Cinevva 现有生成 AI 能力成为力量倍增器之处。不是手工构建每个岩石和树，而是创作者可指导 AI 填充世界。

神经场地形生成

最近关于神经地形生成的研究（NVIDIA 的 GET3D、Terragen 的神经网络模式以及「Terrain Generation Using Procedural Models」等论文）显示，训练模型可从文本提示或草图输入生成合理地形。创作者可画粗略海岸线说「带岩石海岸的森林山丘」并得到带合适侵蚀、植被掩模和材质分配的高度图。

对浏览器投递，你在服务端运行生成并流送结果。生成模型不需在浏览器运行。它产生浏览器可用标准地形流水线渲染的高度图和 splat 图。

3D 资产生成

像 Hunyuan3D、Meshy、Tripo 和 Rodin 等模型可从文本或图像生成 3D 网格。创作者世界的工作流：

1. 创作者描述或草绘他们想要的（「长满苔的石拱门」或「未来风路灯」）
2. 服务器运行生成模型，产生高多边形网格
3. 服务器自动处理：减面到 Web 友好多边形数、生成 LOD、烘焙纹理到 atlas、用 Draco 压缩导出 GLB
4. 资产出现在创作者库存中，准备放入世界

这流水线在 Cinevva 上已经存在部分。缺失部分是 LOD/优化步骤和世界放置系统。

程序化填充

即使有 AI 生成资产，手动放置森林中每棵树仍繁琐。程序化散布规则让创作者定义区域（「这区域是密林」、「这坡是岩石碎屑」），系统自动填充。

GPU compute shader 可在浏览器中运行散布。给定密度图和一组规则（最小间距、坡度约束、高度范围），compute pass 在 1ms 内为整个块生成实例位置。修改密度图，植被瞬间重新生成。

实体组件系统（ECS）

带数千物体的开放世界需要高效实体管理系统。ECS 模式（自 Unity 的 DOTS 和 Bevy 以来在游戏引擎中流行）很好地映射到 JavaScript。

bitECS 是高性能 JavaScript ECS，使用类型化数组和位操作。实体是普通整数。组件是连续类型化数组（每个组件类型一个）。系统顺序迭代数组，即使在 JavaScript 中也是缓存友好的。

import { createWorld, defineComponent, Types, defineQuery, addEntity, addComponent } from 'bitecs';

const Position = defineComponent({ x: Types.f32, y: Types.f32, z: Types.f32 });
const Velocity = defineComponent({ x: Types.f32, y: Types.f32, z: Types.f32 });
const ChunkRef = defineComponent({ chunkX: Types.i16, chunkZ: Types.i16 });

const world = createWorld();
const movingQuery = defineQuery([Position, Velocity]);

function movementSystem(world) {
  const entities = movingQuery(world);
  for (let i = 0; i < entities.length; i++) {
    const eid = entities[i];
    Position.x[eid] += Velocity.x[eid] * dt;
    Position.y[eid] += Velocity.y[eid] * dt;
    Position.z[eid] += Velocity.z[eid] * dt;
  }
  return world;
}

对开放世界，ECS 处理一切：玩家角色、放置的物体、NPC、粒子、触发器和世界道具。块卸载时，其实体从 ECS 移除。块加载时，实体添加。ECS 不关心空间组织。它只处理组件。

物理

得益于 WebAssembly，浏览器物理已变得意外好。

Rapier（Rust -> Wasm）

Rapier 是用 Rust 写的、编译到 WebAssembly 的物理引擎。它处理刚体、碰撞体、关节、角色控制器和光线投射。性能在典型游戏负载下为原生 Bullet/PhysX 的 2-3x 之内。

对开放世界，Rapier 处理：

• 玩家角色控制器（走在地形上、爬阶梯、滑坡）
• 物体到物体碰撞（放置物体、抛射物）
• 玩家交互的光线投射（点击物体选择它）
• 触发体（进入区域，触发事件）

Rapier 在 Web Worker 中运行，所以物理模拟不阻塞渲染。你每帧向渲染器发送位置并接收输入事件。

Havok for Web（通过 Babylon.js）

如果你选 Babylon.js，Havok 物理作为 Wasm 模块内置。Havok 是大多数 AAA 游戏（半条命 2、Skyrim、旷野之息）的物理引擎。Wasm 构建是生产质量，为 Babylon 的场景图优化。

地形碰撞

物理引擎需要地形的碰撞几何。为整个可见地形生成全分辨率三角网格会昂贵。改为仅为玩家附近块（最近 3x3 或 5x5 块）生成碰撞高度场，其他一切使用简化碰撞。Rapier 的高度场碰撞体正是为此用例设计。

音频

声音把 3D 空间从视觉演示变成场所。Web Audio API 提供浏览器中空间音频所需的一切。

带 HRTF 的空间音频（Head-Related Transfer Function）把声音放在 3D 空间。你左侧的瀑布听起来在左侧。走近变响。走到建筑后变闷（带额外处理）。

环境区域像音频的纹理 splatting。定义区域（森林、洞穴、海岸、城市），随玩家移动在它们之间淡入淡出环境音景。这是 Skyrim 让森林听起来鲜活的方式。叠加风、鸟、树叶沙沙、远处动物。无一复杂，皆为空间。

Web Audio 性能对几十同时空间源足够好。瓶颈通常是资产大小，不是处理。对压缩音频用 Opus 或 AAC，流送长环境曲，预加载短音效（脚步、交互）。

水、天气与大气

每个难忘的开放世界都有水和天气。这些系统定义情绪并让世界感觉鲜活。它们在浏览器中也意外可达。

水渲染

浏览器 3D 中的水有三个复杂级别，你可以先发布最简单的，稍后升级。

Level 1：反射平面。 在水位的平面网格带反射/折射材质。把场景上下颠倒渲染到纹理（平面反射），与蓝色调混合，加滚动法线贴图做波浪运动。这是 Skyrim 的基础水着色器所做。在 Three.js 中，官方仓库的 Water 例子实现这个。在 Babylon.js 中，WaterMaterial 开箱即用。成本：反射多一次渲染 pass（半分辨率即可），加水面绘制。在中端 GPU 上，这每帧增加 2-3ms。

Level 2：屏幕空间反射 + 基于深度的效果。 不是单独反射渲染 pass，而是采样现有帧缓冲反射（SSR）。加基于深度的颜色吸收（水越深越暗）、用深度比较做岸边泡沫，以及投射到水下地形的焦散。这是巫师 3 用的。SSR 在 Three.js 后处理栈和 Babylon.js 渲染流水线中都有。成本：SSR 1-2ms，深度效果可忽略。

Level 3：FFT 海洋模拟。 对开阔海洋，用快速傅里叶变换在 GPU 上模拟波谱。Jerry Tessendorf 的论文「Simulating Ocean Water」（2001）是每个主要游戏引擎使用的基础。FFT 作为 WebGPU compute shader 运行，每帧生成位移图和法线图。结果海洋看起来非常令人信服。这是无主之地、刺客信条黑旗和神秘海域 4 使用的。在 WebGPU 中，256x256 FFT 海洋在桌面 GPU 上 1ms 内运行。

@compute @workgroup_size(16, 16)
fn fftOceanDisplacement(@builtin(global_invocation_id) id: vec3<u32>) {
    let k = vec2<f32>(f32(id.x) - N/2.0, f32(id.y) - N/2.0);
    let omega = sqrt(length(k) * gravity);
    let phase = omega * time;
    let h = spectrum[id.xy] * vec2<f32>(cos(phase), sin(phase));
    displacement[id.xy] = h;
}

对创作者世界，从 Level 1（反射平面）开始，渲染器成熟时升级到 Level 2。Level 3 仅在世界有开阔海洋时需要。

天气系统

Skyrim 和 BotW 中的天气由带过渡的状态机驱动。晴 > 多云 > 雨 > 暴风 > 晴。每个状态同时改变多个系统：天空盒、雾密度、环境光颜色、粒子效果（雨/雪）、音频（风、雨）和玩法属性（BotW 中湿表面滑）。

对浏览器世界，天气系统有三层：

天空渲染。 程序化天空着色器比天空盒纹理便宜灵活。Preetham 或 Hosek-Wilkie 天空模型仅从太阳位置计算物理上合理的天空颜色。加用 3D 噪声在平面上滚动的云层。Babylon.js 有内置程序化天空材质。Three.js 有 Sky 例子。两者在可忽略 GPU 成本下产生令人信服的结果（单全屏四边形）。

粒子效果。 雨是粒子系统，数千薄四边形从上落下。雪类似但带更慢漂浮轨迹。雾是后处理 pass，基于深度把场景向雾色混合。所有这些都是标准 WebGL 效果。成本取决于粒子数：1 万雨滴每帧增加约 0.5ms。

环境响应。 湿表面增加镜面反射。雪积累在朝上表面加白。水洼出现在凹陷地形。这些是着色器技巧，不是几何变化。「湿度」uniform 改变材质粗糙度。「雪覆盖」uniform 在法线朝上的表面混合白色。GTA V 和巫师 3 正是用这种方法。

同步天气。 在多人世界中，天气必须跨客户端一致。最简方法：服务器以 1 Hz 广播天气状态（包括过渡进度）。客户端本地插值。由于天气变化慢（从晴到雨的过渡需 30-60 秒），即使延迟更新也看起来平滑。

空气透视

这是让世界感觉大的最有效视觉技术，几乎免费。远处物体看起来更朦胧、更蓝、对比度更低，因为大气中光散射。每个开放世界都用这个。

在片元着色器中，基于深度把远处像素向大气色混合：

float fogFactor = 1.0 - exp(-distance * fogDensity);
vec3 finalColor = mix(objectColor, atmosphereColor, fogFactor);

BotW 把这进一步，用画意雾过渡到水彩风格远景。雾色随昼夜和天气变化。这单着色器效果对规模感的贡献超过任何地形细节量。

对带风格化艺术指导的浏览器世界，空气透视是第一个要实现的视觉效果。它隐藏 LOD 过渡（低细节远物体透过雾看起来好）、减少流送内容可见弹出，并让截图即使在世界完全填充前也看起来好。

头像系统

玩家需要身体。在创作者世界中，头像是自我表达的主要形式，与你建造的并列。系统需要足够灵活以个性化，同时保持渲染成本足够低以支持 200+ 可见玩家。

头像架构

基础网格 + 定制层。 从共享人形基础网格开始（身体 1,500-3,000 三角形）。定制通过：

• 颜色/纹理变化（肤色、发色）通过 uniform 变化。无额外几何。
• 可交换网格部件（发型、服装、配饰）替换基础网格部分。每部件是单独小网格（200-500 三角形）。
• 材质属性变化（金属盔甲 vs 布料长袍）通过材质参数变化。

这是 Roblox、Fortnite 和 VRChat 处理头像的方式。基础成本不论定制保持不变。

Ready Player Me 和 Avaturn 提供基于浏览器的头像创建，输出与任何 3D 引擎兼容的 glTF 模型。它们处理从照片的面部扫描、身体比例和服装。输出模型为实时渲染优化（通常 10K-20K 三角形，可减到远距渲染的 3K-5K）。

浏览器中的骨骼动画

每个可见玩家需要动画：闲、走、跑、跳、表情。骨骼动画通过每帧一组骨骼变换驱动网格。

GPU 蒙皮对性能是强制性的。Three.js 和 Babylon.js 默认在 GPU 上做蒙皮。骨骼矩阵作为 uniform buffer 或纹理上传，顶点着色器应用骨骼变换。CPU 成本是从动画片段计算骨骼变换。对 60 骨架在 30fps，这每个角色约 0.01ms。200 角色：合计 2ms。可接受。

动画混合用混合权重混合多个动画（走+挥手、闲+四处看）。Three.js（AnimationMixer）和 Babylon.js（AnimationGroup）都支持。混合在 CPU 上发生（插值骨骼变换），然后混合结果送 GPU。

实例化动画是高效渲染许多角色的关键。不是为每角色绘制单独网格，而是把动画帧烘焙到纹理（顶点动画纹理或 VAT）。每行纹理存储一帧的骨骼变换。compute shader 或顶点着色器基于角色动画时间读正确行。这允许用单次实例化绘制调用渲染数百角色。巫师 3 和刺客信条用这做人群渲染。

在 WebGPU 中，实例化动画角色看起来像：

@vertex
fn vs_main(@builtin(instance_index) instanceIdx: u32, @location(0) position: vec3<f32>) -> @builtin(position) vec4<f32> {
    let animFrame = instances[instanceIdx].animationFrame;
    let boneIdx = vertexBoneIndices[vertexIdx];
    let boneTransform = textureLoad(animTexture, vec2<i32>(i32(boneIdx), i32(animFrame)), 0);
    let worldPos = instances[instanceIdx].transform * boneTransform * vec4<f32>(position, 1.0);
    return viewProjection * worldPos;
}

对远玩家（50 米外），切换到广告板假体：从当前视角显示角色预渲染精灵的平四边形。这是 Skyrim 用于远距树的同一技巧，应用到角色。远距过渡不可察觉。

交互的逆向运动学

当角色拾起物体、伸向门把手或指向某物时，程序化 IK 让动作看起来自然。FABRIK（Forward And Backward Reaching Inverse Kinematics）是简单快速的 IK 求解器，实时工作良好。Three.js（通过 CCDIKSolver）和 Babylon.js（通过 BoneIKController）都有内置 IK 支持。

对创作者世界，IK 意味着角色可自然与放置物体交互：坐在创作者放置的椅子上、靠栏杆、拾物品。交互无需逐物体动画。IK 系统使角色姿态适应物体位置。

高级网络

基础架构（WebSocket + WebRTC）之前已涵盖。这里是协议、压缩和较新传输选项的深入细节。

二进制消息协议

JSON over WebSocket 相比二进制编码浪费 10x 带宽。对实时多人世界，每条消息应是二进制。

FlatBuffers（来自 Google）是游戏网络的最佳适配。与 Protocol Buffers 不同，FlatBuffers 提供对序列化数据的零拷贝访问。你不把消息解码到 JavaScript 对象。你直接从缓冲读字段。这消除 Protocol Buffers 在热路径会造成的分配和 GC 压力。FlatBuffers 有 JavaScript/TypeScript 代码生成器。

FlatBuffers 中的玩家位置更新：

// Schema: PlayerUpdate { id: uint16, x: float32, y: float32, z: float32, yaw: float16, pitch: float16, animState: uint8 }
// 合计：每玩家更新 17 字节
// vs JSON: {"id":42,"x":103.5,"y":12.3,"z":-47.8,"yaw":1.57,"pitch":0.2,"animState":3} = 80+ 字节

对 200 玩家 20 Hz，差异是 200 * 17 * 20 = 68 KB/s（二进制）vs 200 * 80 * 20 = 320 KB/s（JSON）。二进制小 4.7x，且在热循环中避免 JSON.parse 分配。

MessagePack 比 FlatBuffers 简单（无模式、无代码生成），但仍比 JSON 小 30-50%。如果你想要不带模式管理的二进制，这是好中间方案。

位置量化和 Delta 压缩

玩家位置不需要 32 位浮点精度。如果你的世界是 4 km x 4 km，16 位无符号整数给你 6 cm 精度（4000m / 65536）。对大多数游戏，这与全精度无异。这把位置数据大小减半。

Delta 压缩只发送与上次确认状态的差。如果玩家上次更新后移动了 0.5 米，delta 是压缩良好的小数字。配合可变长度编码（更小 delta 用更少字节），典型 delta 压缩的位置更新是 3-6 字节，不是 12。

Dead reckoning 减少更新频率。不是 20 Hz 发送位置，而是发送位置 + 速度。客户端在更新间外推位置。仅在实际位置偏离预测位置超阈值时发送修正。这对直线移动玩家可减少 60-80% 的位置更新带宽（这是大部分移动）。

RuneScape 用极端版本：玩家移动基于瓦片，所以移动命令只是目标瓦片。客户端本地动画化步行路径。对连续 3D 世界，你会用平滑 dead reckoning，但原理相同。

WebTransport

WebTransport 是较新协议，可能取代 WebSocket 和 WebRTC DataChannel 用于游戏网络。它在 HTTP/3（QUIC）上运行，提供：

• 可靠有序流（像 WebSocket 但多路复用，所以一流的停顿不阻塞他流）
• 不可靠数据报（像 UDP，用于一旦延迟就立即过期的位置更新）
• 多路复用流（聊天、世界状态、位置的独立流，无队头阻塞）

这正是游戏网络需要的。WebSocket 给你可靠有序（但队头阻塞杀死位置更新延迟）。WebRTC DataChannel 给你不可靠（但设置复杂，需 ICE/STUN）。WebTransport 在单连接上给你两者。

2026 年初浏览器支持：Chrome 和 Edge 完全支持。Firefox 部分支持。Safari 落后。对桌面优先的创作者平台，WebTransport 今天可用，带 WebSocket 回退给 Safari。

Cloudflare 通过 Workers 支持 WebTransport，适合我们的基础设施。

规模化兴趣管理

带 200+ 玩家的网络挑战不是每玩家带宽。是 N 平方问题：如果每玩家向每玩家发送更新，200 玩家意味着 200 * 199 = 每 tick 39,800 个更新消息。服务器需要过滤。

Area of Interest（AOI）管理 意味着每玩家只接收视野范围内实体的更新。实现使用与块系统相同的空间网格：当玩家位置映射到块 (3, 7) 时，他们接收块 (2-4, 6-8) 的更新，3x3 邻域。范围外的实体不发送。

基于优先级的更新在 AOI 内给重要实体更多带宽。向你跑来的玩家得到 20 Hz 更新。200 米外站着不动的玩家得到 2 Hz 更新。无所事事的 NPC 得到 0.5 Hz 更新。服务器为每客户端维护优先队列，基于实体相关性（距离、速度、交互潜力）分配带宽。

休眠。 N 秒未改变状态的实体进入休眠并完全停止生成网络流量。客户端保留最后已知状态直到唤醒事件到达。在创作者世界中，大多数放置物体是静态的，休眠消除大部分潜在网络流量。

Slither.io 的可变 tick 率（远 5 Hz vs 近 30 Hz）是这的简化版。EVE Online 的「时间膨胀」是极端版（当一个区域玩家过多，服务器减慢游戏 tick 率以保持一致）。对我们用例，带休眠的优先级 AOI 是正确平衡。

高斯泼溅和较新渲染技术

传统网格渲染（三角形 + 纹理）不再是浏览器 3D 的唯一选项。几种较新技术达到生产可行性。

3D 高斯泼溅

3D 高斯泼溅（SIGGRAPH 2023）：从照片重建写实场景，在浏览器中实时渲染。创作者可用手机扫描真实世界物体并直接放入世界。

3D Gaussian Splatting（3DGS）通过把场景表示为数百万带颜色 3D 高斯（定向、上色椭球）从照片重建 3D 场景。渲染器排序并光栅化这些泼溅，不是三角形。

为什么这对创作者世界重要：

• 照相测量捕获变简单。 创作者用手机给真实物体或位置拍 50 张照片。服务端处理（通过 Nerfstudio 或 gsplat 等工具）几分钟产生高斯泼溅场景。该场景在浏览器加载，从任意角度看起来写实。
• 浏览器渲染已解决。 多个开源实现在 WebGL 和 WebGPU 中渲染高斯泼溅。PlayCanvas 有内置泼溅渲染。Luma AI 有 Three.js 兼容查看器。gsplat.js 是独立库。性能好：1-300 万泼溅在桌面 GPU 上 30-60fps 渲染。
• 数据格式紧凑。 一个房间的高斯泼溅场景可能压缩 10-30 MB。单独物体 1-5 MB。这与纹理网格资产相当。

权衡：泼溅场景是静态的。你不能轻易动画化或修改它们。它们很好处理环境装饰（写实树、捕获的真实雕塑、扫描的建筑外立面）但不用于交互游戏物体。混合方法是用泼溅做环境细节，传统网格做交互物体。

对创作者世界： 让创作者通过手机照片捕获真实物体，服务端处理为高斯泼溅，并放入世界。这桥接 AI 生成资产和真实世界物体的差距。创作者可扫描自己的艺术作品、家具或建筑直接放入共享世界。

神经辐射场（NeRF）到网格

NeRF 把场景表示为输出任意 3D 点颜色和密度的神经网络。它们从照片产生非凡视觉质量，但渲染昂贵（每像素每帧一次完整神经网络前向传播）。

浏览器的实用方法：从照片训练 NeRF，然后用密度场上的 marching cubes 提取网格。结果是任何浏览器引擎可渲染的传统三角网格带烘焙纹理。Instant-NGP、Nerfstudio 和 Neuralangelo 等工具自动化此流水线。质量不如直接渲染 NeRF，但与标准渲染流水线兼容。

这是创作者无建模技能也能把真实世界物体放进浏览器世界的另一路径。

Mesh shader 和 Nanite 风格渲染

UE5 的 Nanite 系统通过使用 mesh shader、GPU 驱动渲染和虚拟几何（基于屏幕覆盖在每集群级流送三角形）渲染数十亿三角形。WebGPU 还不支持 mesh shader，但底层原则（带基于 compute 剔除和 LOD 选择的 GPU 驱动渲染）可实现。

WebGPU compute shader 可：

1. 读所有网格集群边界盒（约 64 三角形组）
2. 测试每集群对视锥和遮挡缓冲
3. 基于屏幕空间大小选择合适 LOD 等级
4. 把可见集群写入间接绘制缓冲
5. 单次间接绘制调用渲染一切

这种「虚拟几何」方法以恒定 CPU 成本处理数百万三角形（无论场景复杂度 CPU 提交一次绘制调用）。这是浏览器渲染最终如何处理大开放世界。实现复杂但 WebGPU 今天有构建块。

风格化开放世界的着色器技术

风格化艺术指导需要具体着色器技术。这些是每 GPU 周期视觉影响最大的。

植被风动画

在风中摇曳的树和草让世界感觉鲜活。技术简单：在顶点着色器中，用与世界位置和时间关联的正弦波组合偏移顶点位置。

vec3 windOffset = vec3(
    sin(worldPos.x * 0.5 + time * 2.0) * windStrength,
    0.0,
    cos(worldPos.z * 0.3 + time * 1.5) * windStrength
);
float heightFactor = localPos.y / meshHeight;
finalPos += windOffset * heightFactor * heightFactor;

heightFactor 确保树基部保持接地，顶部摇曳最多。在正弦函数中使用世界位置意味着相邻树以略不同相位摇曳，跨森林创造自然波浪效果。BotW、Skyrim 和每个带植被的开放世界都用这技术。

对草，相同原则适用但带更高频率和更短波长。GPU 实例化草叶（数千薄四边形）带每实例随机相位偏移产生令人信服的草甸，成本最小。WebGPU compute shader 可从密度图生成草叶位置和朝向，每帧把风烘焙到实例变换。

卡通/Cel 着色

如果艺术指导是风格化的（且证据建议它应该是），cel 着色是核心技术。思路：把光照量化为离散步骤，不是平滑梯度。

float NdotL = dot(normal, lightDir);
float toonShading = step(0.3, NdotL) * 0.5 + step(0.6, NdotL) * 0.5;
vec3 color = baseColor * (ambient + toonShading);

这产生经典两色或三色外观。加描边 pass（背面略放大渲染，或用屏幕空间边缘检测后处理）做漫画书效果。

BotW 的着色比纯 cel 着色更细腻。它用带阴影边界轻微步进的平滑梯度，加暖到冷的色彩偏移（阴影偏蓝，亮区暖）。这种混合方法比严格卡通着色看起来更自然，同时仍读作风格化。在任何浏览器 3D 引擎中可用自定义着色器实现。

风格化水着色器

风格化世界中的水不需要真实波模拟。滚动法线贴图、边缘泡沫检测和基于深度颜色的组合产生视觉上与 BotW 风格艺术指导一致的结果。

float depth = texture(depthTexture, screenUV).r - fragDepth;
vec3 shallowColor = vec3(0.2, 0.7, 0.8);
vec3 deepColor = vec3(0.05, 0.15, 0.3);
vec3 waterColor = mix(shallowColor, deepColor, saturate(depth * 2.0));

float foam = step(0.05, depth) * (1.0 - step(0.15, depth));
foam *= texture(foamNoise, worldUV * 3.0 + time * 0.1).r;
waterColor = mix(waterColor, vec3(1.0), foam * 0.8);

这给你基于深度的着色（浅水更亮）、与噪声动画的岸线泡沫，整个东西在单个片元着色器 pass 中运行。

屏幕空间环境光遮蔽（SSAO）

SSAO 变暗角落、缝隙和表面相遇处。它在不昂贵的全局照明下为场景增加深度和接地感。Three.js 和 Babylon.js 都有内置 SSAO 实现。

对风格化世界，SSAO 甚至比写实渲染更重要，因为平着色不自然显示接触阴影。轻 SSAO pass（半分辨率即可）添加缺失的深度线索。成本：桌面 GPU 1-2ms。

更深的世界生成

基础文章高层覆盖了程序化地形。这里是算法细节。

地形的噪声函数

所有程序化地形从噪声开始。噪声函数产生在空间中平滑变化的伪随机值。叠加多 octave（频率）做自然外观结果。

Perlin 噪声是经典。Simplex 噪声更快，方向性伪影更少。OpenSimplex 2 是 JavaScript 中性能好的现代变体。对 WebGPU compute shader，在 WGSL 中实现 simplex 噪声很直接（约 50 行数学）。

**分形布朗运动（fBm）**叠加 octave 噪声：

height = 0
amplitude = 1.0
frequency = baseFrequency
for each octave:
    height += amplitude * noise(position * frequency)
    frequency *= lacunarity（通常 2.0）
    amplitude *= persistence（通常 0.5）

6-8 个 octave 时，fBm 产生有大尺度山形成、中尺度丘陵和细尺度起伏的地形，很像真实地形。persistence 参数控制地形多粗糙（0.3 产生平滑滚动丘陵，0.7 产生锯齿山）。

域扭曲把一个噪声函数的输出作为另一个的输入坐标。这产生看起来侵蚀和有机而不是均匀起伏的地形。应用 2-3 层域扭曲，地形开始看起来像被地质过程塑造。

水力侵蚀模拟

原始噪声地形看起来像皱纸。真实地形看起来像被雨淋了百万年的皱纸。水力侵蚀模拟把噪声生成地形变换为看起来地质上合理的东西。

算法：

1. 在高度图随机位置投放水颗粒
2. 颗粒顺坡流（跟随地形梯度）
3. 每步基于速度和坡度从地形捡起沉积物
4. 当颗粒减速（更平地形、积水），它沉积沉积物
5. 重复 10-50 万颗粒

结果是带河谷、冲积扇、自然外观山脊线和逻辑过渡平滑坡度的地形。算法在 JavaScript 中对 1024x1024 高度图约 2-5 秒运行，或在 WebGPU compute shader 中 100ms 以下。

Sebastian Lague 的实现（GitHub 上可用）是游戏开发者的标准参考。它产生与手工雕刻结果媲美的地形。对创作者世界，在服务端处理步骤中对 AI 生成地形运行侵蚀会让程序化生成的景观看起来手工。

群落分配

真实世界有群落：森林、沙漠、苔原、沼泽。群落分配把气候参数映射到地形区域。

来自 Minecraft 的方法富启发性：用温度和湿度轴在 2D 网格上定义群落。温度随海拔和纬度下降。湿度随水接近度和盛行风向变化。每个网格 cell 得到群落分配（森林、沙漠、苔原等），决定地形纹理、植被类型和密度、环境音以及天气模式。

对创作者世界，群落边界应可绘。系统从地形属性生成默认群落，但创作者可通过在其拥有地块上绘制群落区域覆盖分配。这种混合方法给世界自然外观默认，同时让创作者表达其愿景。

用于结构的波函数坍缩

Wave Function Collapse（WFC）从带邻接约束的瓦片集生成结构（建筑、地下城、道路）。给定一组模块化建筑件和关于哪些件能连哪些的规则，WFC 可生成整个村庄、城堡布局或地下城地图。

对创作者世界，WFC 启用：

• 自动生成村庄用基线内容填充世界，然后创作者定制
• 辅助建造创作者放几件，WFC 填充间隙（像 Townscaper 但带 3D 建筑块）
• 地下城生成用于创作者可配置的交互体验（设主题、难度和大小，WFC 生成布局）

Oskar Stalberg（Townscaper 和 Bad North 创作者）演示了基于 WFC 的生成对用户感觉魔法。他们放几块，系统在它们周围生成美学连贯的结构。这正是创作者平台上成功的「简单工具、丰富输出」原则。

内容审核架构

在创作者放置任意 3D 内容给他人看的世界中，审核不是可选的。它是核心基础设施组件。

自动筛查流水线

进入世界的每个资产在对其他玩家可见之前通过多阶段流水线：

1. 几何分析。 用训练分类器扫描网格的解剖学露骨形状。这捕获明显不当 3D 模型的大多数。几个商业 API（Azure Content Safety、Google Cloud Vision for 3D）处理这。分类器在多个角度的网格轮廓上运行，计算便宜。

2. 纹理分析。 用标准图像内容审核 API（用于上传照片的同样 API）运行每个纹理。这捕获应用于无辜几何作为纹理的不当图像。

3. 文本检测。 如果物体含文本（在纹理中或作为 3D 文本网格），运行 OCR 并对内容政策检查。这捕获仇恨言论、辱骂和其他基于文本的违规。

4. 自动批准。 如果所有检查通过，资产立即可见。如果任何检查标记资产，进入审核队列。

5. 人工审核。 标记资产由审核员审查。对小平台，这可以是团队。对规模，合同审核服务（审核社交媒体内容的同样服务）。

空间审核

超越单独资产，即使每个物体单独没问题，物体的空间布置也可能不当。这更难自动检测。实用方法：

• 玩家举报。 任何玩家可举报位置。举报包含截图（在举报坐标自动拍摄）和举报玩家账户。举报触发人工审核。
• 热图。 跟踪哪些区域产生举报。如果创作者的地块持续产生举报，升级到审核。如果创作者反复违规，限制其编辑权限。
• 地块评级。 像 Second Life，让创作者自评其地块。默认视图隐藏「General」以上评级的地块。玩家选择看成人内容。这不阻止违规但减少暴露。

延迟考虑

如果自动筛查每资产 5-10 秒，那是创作者放置物体到对其他玩家出现之间明显延迟。选项：

• 乐观本地显示。 创作者立即看到其放置。其他玩家在批准后看到。如果资产被拒，它消失，创作者被通知。
• 预批准资产库。 大部分放置使用来自平台库的预筛查资产（包括在生成时筛查的 AI 生成资产）。自定义上传经过筛查。这意味着大部分放置是即时的。
• 基于声誉的快速通道。 有批准内容历史的创作者获得新放置的自动批准。新创作者或被标记创作者经过完整筛查。

浏览器 3D 性能：实际数字

理论预算有用。实际测量性能更有用。这里是来自生产硬件上运行的浏览器 3D 场景的实际数字。

渲染基准

带 1 万实例化物体的 Three.js 场景（树、岩石，每个 500 三角形）：

• MacBook Pro M1（Chrome，WebGL2）：58-60fps
• RTX 3060 桌面（Chrome，WebGL2）：60fps 锁
• Intel UHD 620 笔记本（Chrome，WebGL2）：25-35fps
• iPhone 13（Safari，WebGL2）：30-40fps

带 10 万实例化草叶的 Three.js 场景（每个 6 三角形，合计 60 万三角形）：

• M1 MacBook：55fps
• RTX 3060：60fps
• Intel UHD 620：12fps
• iPhone 13：15fps

带 100 万三角形、4 LOD 等级、Havok 物理的 Babylon.js 地形：

• M1 MacBook（WebGPU）：60fps
• M1 MacBook（WebGL2）：45fps
• RTX 3060（WebGPU）：60fps
• RTX 3060（WebGL2）：55fps

带 200 万泼溅的高斯泼溅场景（通过 gsplat.js）：

• M1 MacBook（WebGL2）：30fps
• RTX 3060（WebGL2）：45fps
• RTX 3060（WebGPU）：60fps

内存测量

Three.js 最小场景（天空盒、地形、100 物体）：80-120 MB GPU 内存，150-200 MB JS 堆 带 Havok 物理的 Babylon.js：200-300 MB GPU 内存，250-350 MB JS 堆（Havok Wasm 加约 50 MB） 浏览器标签内存限制（测量，非文档）：

• Chrome 桌面：通常在 4 GB 左右崩溃
• Chrome Android：通常在 1-1.5 GB 左右崩溃
• Safari iOS：通常在 1 GB 左右崩溃
• Firefox 桌面：通常在 3-4 GB 左右崩溃

网络测量

WebSocket 往返延迟（浏览器到 Cloudflare 边缘）：

• 同大陆：10-30ms
• 跨大陆：80-200ms
• 带 Cloudflare Durable Objects：首请求 DO 唤醒加 5-10ms

WebRTC DataChannel 延迟（浏览器到浏览器通过 TURN）：

• 同城市：5-15ms
• 同大陆：20-50ms
• 跨大陆：100-250ms

**WebTransport（HTTP/3 QUIC）**延迟与 WebSocket 相当，但无队头阻塞，所以 P99 延迟显著更好（单丢包无停顿）。

加载时间测量

Three.js 空场景（仅库）：350ms 到首帧 Babylon.js 空场景：500ms 到首帧 1 MB GLB 模型通过 fetch + 解析：宽带 200-400ms KTX2 纹理，1024x1024，Basis Universal：GPU 上解码 50-100ms Draco 压缩网格，5 万三角形：Web Worker 中解码 30-80ms

这些数字确认架构部分的性能预算可达。中端桌面可在 60fps 渲染复杂开放世界场景。移动是约束：你需要激进 LOD 和较短视距以在手机上保持 30fps。

完整栈

综合一切，这是基于浏览器的多人创作者开放世界架构：

客户端（浏览器）

层	技术	角色
渲染器	Babylon.js（WebGPU + WebGL2 回退）	场景渲染、地形、LOD、后处理
地形	自定义高度图系统 + Babylon DynamicTerrain	带 splat 的基于块流送地形
物理	Rapier（Wasm）或 Havok（通过 Babylon）	角色控制器、碰撞、光线投射
ECS	bitECS	所有世界物体的实体管理
网络	WebSocket + WebRTC DataChannel	状态同步、位置更新、语音聊天
状态	Yjs（CRDT）	协作世界编辑、冲突解决
音频	Web Audio API	空间音频、环境、音乐
UI	HTML/CSS 叠加	HUD、库存、聊天、创作者工具
Workers	Web Workers	资产解压、物理、地形生成

服务器

层	技术	角色
世界分片	Cloudflare Durable Objects	每块权威状态、WebSocket 端点
资产存储	Cloudflare R2	GLB 模型、KTX2 纹理、高度图、音频
资产 CDN	Cloudflare CDN（R2 公开桶）	世界资产的边缘缓存投递
AI 生成	GPU 实例（Hetzner/Lambda/RunPod）	3D 模型生成、地形生成、纹理生成
资产流水线	Cloudflare Queue + Workers	LOD 生成、网格优化、格式转换
认证	Auth0	创作者身份、权限
数据库	Cloudflare D1	世界元数据、创作者库存、权限
实时	Cloudflare Durable Objects + Pub/Sub	玩家在线、聊天、事件广播

数据流

1. 玩家在浏览器中打开世界
2. 客户端认证，连接到其出生块的最近 Durable Object
3. DO 发送当前块状态（地形 + 物体 + 附近玩家）
4. 客户端开始渲染，从 R2/CDN 请求相邻块
5. 随玩家移动，客户端连接到相邻 DO，从远 DO 断开
6. 创作者放置物体：客户端发送编辑到 DO，DO 验证并通过 CRDT delta 广播给所有连接客户端
7. DO 在每次编辑时持久化块状态（防抖）
8. 其他玩家在 100-200ms 内看到新物体出现

性能预算

对中端桌面（RTX 3060 / M1 Mac / 16GB RAM）的 60fps 体验：

资源	预算	备注
绘制调用	每帧 < 500	批处理、实例化、LOD
三角形	每帧 < 200 万	LOD 控制这个
纹理内存	< 512 MB	KTX2 压缩、流送、atlas 池
几何内存	< 256 MB	共享缓冲、池、激进卸载
JavaScript 堆	< 512 MB	ECS 用类型化数组，不用对象
网络	< 500 KB/s 持续	Delta 压缩、空间相关性过滤
初始加载	< 10 MB，< 5 秒	渐进加载、地形优先
块加载	< 200 KB，< 200ms	预取相邻块

成功的浏览器游戏及其证明

浏览器游戏不是小众。它们是最大游戏市场之一。Poki 月服务超过 1 亿玩家。CrazyGames、Newgrounds 和 itch.io 服务数百万更多。在浏览器中成功的游戏有具体架构模式值得学习。

今天发布的浏览器 3D 游戏

Hordes.io：持久 3D 浏览器 MMO 中 200+ 玩家。自定义 WebGL、低多边形风格、5 秒内加载。由一人开发者构建。

Hordes.io 是最相关的浏览器 MMO。由独立开发者用自定义 WebGL 渲染构建，它把 200+ 玩家放入带实时战斗、公会、职业和 PvP 的持久 3D 世界。整个游戏 5 秒内加载。世界分成带激进剔除的区域。玩家模型简单（低多边形带平着色），但粒子效果和动画让战斗感觉响应。Hordes.io 证明三件事：浏览器 MMO 可处理一个场景中数百并发玩家、独立开发者可构建，以及风格化图形在浏览器中比写实图形性能更好。

Krunker.io：1000 万月玩家、构建在 Three.js 上、带完整浏览器内地图编辑器和用户生成内容市场。

Krunker.io 峰值超 1000 万月玩家，被 FRVR 收购。它是带完整地图编辑器、自定义游戏模式、用户生成内容和市场的基于浏览器 FPS。构建在 Three.js 上，由于其方块艺术风格和激进优化，即使在低端硬件上也 60fps+ 运行。关卡编辑器特别相关。玩家用类似体素的块系统构建地图，在市场上分享，其他人在其上玩。这是迷你版创作者世界循环：建造、分享、他人体验。Krunker 证明如果创建工具足够简单，用户生成 3D 内容可在浏览器中工作。

ev.io 是构建在 Babylon.js 上的浏览器 FPS。它在大多数硬件上运行良好，支持自定义地图，演示 Babylon 的 WebGL 渲染器可在浏览器标签中处理快节奏 3D 动作。游戏使用激进纹理压缩和低多边形环境以保持在性能预算内。

Shell Shockers（超 500 万月玩家）是 3D 多人射击游戏，你扮演蛋。构建在 Three.js 上，它在浏览器中处理实时多人带响应命中检测。卡通艺术风格保持资产需求最小同时仍看起来精致。

Townscaper：点击放置建筑，系统自动生成街道、拱门和阶梯。无菜单、无目标。仅凭创意快乐卖出 100 多万份。

Townscaper 不是浏览器游戏，但其世界构建方法高度相关。玩家在水面上点击放置建筑。游戏基于放置模式自动生成建筑细节、街道、拱门和阶梯。无菜单、无设置、无目标。只是点击和建造。它卖出 100 多万份。教训：有时最简单创意工具产生最吸引人体验。如果我们能让在世界中放置物体感觉像 Townscaper 那样即时，创作者会花数小时建造。

A-Frame / 8th Wall 体验。 A-Frame（构建在 Three.js 上）驱动数千基于 Web 的 3D 体验。8th Wall（现为 Niantic 一部分）在移动浏览器中运行 AR 体验。这些不是游戏，但它们演示带物理和交互的复杂 3D 渲染在浏览器标签中无插件工作。这些体验中的许多在 2-3 秒内加载并在中端手机上运行。

Vuntra City：活程序化城市实验室

Vuntra City 是原生 UE5 项目，不是浏览器游戏，所以它不是我们栈的直接性能基准。它仍是我们开放世界架构最有用的公开案例研究之一，因为开发日志在真实生产压力下系统设计权衡上异常具体。

一个有力收获是速度感知细节策略。在运输和优化视频中，高速穿越被移到屋顶之上，世界细节随速度上升缩减，所以流管理器不会被内部搅动呛到（快速运输、优化技术）。这干净地映射到我们的浏览器计划，速度应直接控制预取半径、内部激活范围和每帧生成预算。

另一收获是拓扑数据与渲染对象之间的硬分离。地图和地址实现使用全局拓扑控制器，能回答未加载区域的位置和地址查询（地图和地址）。这正是我们需要的模式，用于服务器权威路由、POI 查询和不应依赖单个客户端当前内存中有什么的世界级查询。

NPC 工作也高度相关。百万 NPC 系统全局计算粗略日程状态，然后只在玩家相邻空间模拟昂贵行为（百万持久 NPC、幕后）。对我们，这强化了两层模拟模型：便宜确定性远场状态，AOI 内丰富近场行为。

最后，Vuntra City 的环境设计强化了在技术规划中容易忘记的事情：分布设计就是内容设计。项目避免均匀随机放置、用加权异常值带来惊喜，并通过故事性地图和地址而不是无处不在的小地图标记驱动发现（程序化环境不必无聊、我们要去的地方不需要小地图）。

火爆的浏览器游戏

Agar.io（2015）证明浏览器多人可达数百万。峰值时跨服务器有超 10 万并发玩家。游戏 2D 且机制简单（通过吸收较小细胞成长），但网络架构通过空间划分处理大规模并发。每个服务器运行游戏世界的一个区域。玩家只接收其视野中实体的更新。这是 3D 开放世界需要的同样兴趣管理模式，仅是 2D。

Slither.io 在 Agar.io 成功上构建并证明模型扩展。月活峰值 6700 万。游戏使用 WebSocket 做实时位置同步和空间划分限制网络流量。一个值得注意的细节：Slither.io 服务端碰撞检测对远玩家以较低 tick 率（5 Hz）运行，比近玩家（30 Hz）。这种按距离的可变 tick 率适用于 3D 开放世界。

Surviv.io 是基于浏览器的大逃杀，在被 Kongregate 收购前达 5000 万月玩家。它完全在浏览器中运行 80 玩家大逃杀比赛，带实时网络物理、可破坏环境和物品拾取。地图从预设计建筑模板程序化布置，是我们可用于创作者放置结构的模式。

Zombs Royale 在浏览器中运行 100 玩家大逃杀，带快速加载和响应网络。像 Surviv.io，它证明实时浏览器游戏中大玩家数商业上可行，不只是技术上可能。

所有这些浏览器热门的共同主线：它们加载快（5 秒以下），它们在任何设备工作，艺术风格简单但一致，网络为具体玩法优化（空间划分、可变更新率、远状态激进剔除）。

RuneScape：移到浏览器的 MMO

RuneScape：带 20+ 年内容的完整 MMO 在浏览器标签中运行。自定义二进制协议、基于瓦片流送、每服务器 2000 并发玩家。规模化浏览器 MMO 的证明。

RuneScape 是基于浏览器开放世界最重要案例研究，因为它真的发生了。Jagex 把带 20 年内容的整个 MMO 移到浏览器。

RuneScape 最初作为 Java 小程序运行。浏览器放弃 Java 支持时，Jagex 在 C++ 中重建客户端，并发布完全可用的 HTML5/WebGL 客户端。Old School RuneScape（复古版）现在通过通过 Emscripten 编译为 WebAssembly 的客户端完全在浏览器中运行。游戏处理大持久世界、带每服务器数百玩家的实时多人、带运转 grand exchange（拍卖行）的经济，以及带深度进度系统的 23 个技能。

重要技术细节：

• 世界分成地图方块（64x64 瓦片区域）。客户端加载玩家周围 13x13 区域网格（104x104 可见瓦片）。该网格外区域完全剔除。
• 地形基于瓦片，每瓦片角有高度值。地形覆盖（路径、水边、海滩过渡）使用每形状 12 个旋转变体的形状系统。这比高度图受约束但极紧凑且流送快。
• 网络协议是 WebSocket 上的自定义二进制。每个包类型有定义结构。玩家位置更新使用 2 字节做地图方块坐标和移动类型的变长编码。聊天、交易和战斗事件有自己的紧凑二进制格式。整个协议为最小带宽重度优化。
• 物体渲染使用模型系统，服务器发送模型 ID，客户端渲染缓存模型。大部分模型加载一次后复用。这意味着世界作为元数据流送（什么模型去哪），而不是流送几何。
• 每个服务器实例在整个游戏世界处理 2000 并发玩家。世界未空间分片。单服务器进程在 600ms 游戏 tick 上管理所有玩家、所有 NPC 和所有游戏逻辑。这工作是因为每 tick 的游戏逻辑简单：处理玩家动作、更新 NPC AI、解决战斗、广播状态变化。

RuneScape 对我们案例的证明： 带持久世界状态、数千玩家、复杂游戏系统和真实经济的完整 MMO 可在浏览器标签中运行。客户端下载 50 MB 以下，几秒加载，在笔记本上运行。如果一个 20 年的 Java MMO 能完成过渡，专为浏览器构建的世界约束更少。

RuneScape 方法不适合之处： RuneScape 渲染是等距/固定相机，不是第一/第三人称 3D。视觉保真度按现代标准低。世界不是创作者可编辑的。但网络架构、基于瓦片流送，以及浏览器 MMO 数十年留住玩家的证明，都直接相关。

Habbo Hotel：持续 25 年的社交空间

Habbo Hotel 2000 年发布，仍在运行。它是 2D 等距社交世界，用户创建和装饰房间、访问其他人房间并社交。峰值时月用户 900 万。整个体验在 Flash 中运行（Flash 弃用后现在是 HTML5）。

Habbo 重要是因为它如何长久维持创作者社区。房间系统实际是我们构建之物的 2D 版：用户在网格上放置家具物体、定制布局、邀请他人访问。经济模型（用户用真钱买虚拟家具）产生超过 10 亿美元终身收入。

Habbo 教什么：

• 如果创建工具简单且社交功能强，带用户创建内部的基于房间空间作为社交平台可工作数十年。
• 虚拟家具经济维持长期参与。用户购买、交易和收藏物品。物品无玩法效用。它们是纯自我表达和身份。
• 社交空间中的审核需要不断投资。Habbo 经历多次审核危机。自动内容过滤加人工审核员加社区举报是最小可行方法。
• 从 Flash 到 HTML5 的过渡（约 2020-2021 完成）证明大社交世界可迁移渲染技术不失社区。用户关心其房间和朋友，不是底层技术。

Among Us 和空间社交游戏

Among Us 不是开放世界，但其成功揭示了关于多人空间的重要事：玩家想在一起在某个地方，不只是在游戏中一起。爆红的空间近距聊天 mod 显示，在带方向音频的同一虚拟房间中把多人从游戏机制变为社交体验。

增强创作者世界的空间社交功能：

• 近距语音聊天音量随距离淡化。走近某人说话。走开他们淡出。这创建自然社交集群，无需语音频道管理。
• 表情和手势系统让玩家不通过语音表达。挥手、跳舞、指向手势。这些实现便宜（玩家头像上的动画）且不成比例地增加社交参与。
• 世界内发生的共享活动（不通过菜单）把空间变为场所。如果两个创作者可坐在虚拟桌旁一起看 3D 模型，世界有超越显示静态内容的存在理由。

在 Poki 和 CrazyGames 上规模化的浏览器游戏

Poki 和 CrazyGames 合计服务超 1.5 亿月玩家。这些平台上表现最好的游戏提供关于浏览器中具体什么有效的洞见。

浏览器游戏门户上的顶级模式：

• 即时游玩（3 秒内交互）。无需登录。无需教程。游戏应在落地 5 秒内有意义。
• 会话灵活性。玩家投入 2 分钟或 2 小时。游戏适应两者。对创作者世界，这意味着世界应可探索而无需投入会话。走走、看酷东西、离开。或留下来建造数小时。
• 移动兼容。Poki 流量 60% 以上是移动。仅桌面工作的浏览器世界失去大部分潜在访客。
• 不需朋友的社交功能。排行榜、对其他玩家内容的反应、异步功能（无需同时在线看其他玩家建造了什么）。

这些门户上最成功 3D 游戏（如 Shell Shockers、1v1.LOL、Smash Karts）保持多边形数低、纹理简单、帧率高。它们证明如果体验平滑响应，玩家接受简单图形。

基于浏览器的创作者平台

Mozilla 的 Hubs（现社区维护）。 构建在 Three.js 和 A-Frame 上的浏览器多用户 3D 空间。支持语音聊天、头像和共享物体。不是开放世界（基于房间），但网络和渲染架构相关。Mozilla 在关闭托管服务前开源它，所以完整代码库可研究。GitHub。

Hyperfy。 完全在浏览器中运行的基于 Web 的元宇宙平台。Three.js 渲染、多人、头像定制和世界构建。比 Hubs 更接近我们目标，因为它强调创作者工具。世界在浏览器标签加载无需下载。hyperfy.io。

Ethereal Engine（原 XREngine）。 构建在 Three.js 和 bitECS 上的多用户世界开源引擎。支持 WebXR、空间音频和世界编辑。有内置 ECS 架构、网络层和编辑器工具。最接近我们描述的现有开源项目。值得研究他们如何整合 bitECS 与 Three.js 做实体管理，以及其网络如何处理空间状态。GitHub。

Dusk（原 Rune）。 Web 游戏的多人游戏 SDK。处理网络层，让开发者专注玩法。其状态同步方法使用预测状态带服务器协调，是响应多人的标准模型。SDK 抽象 rollback netcode 复杂度。值得研究他们的开发者体验。

Niantic 的 OnRamp。 来自 Pokemon GO 开发者的基于浏览器 3D 世界构建器。用户创建和分享其他人可访问和探索的 3D 空间。演示非技术创作者如果工具易用可在浏览器中构建 3D 世界。

PlayCanvas Editor。 不是游戏本身，但 PlayCanvas 基于云的 3D 编辑器显示协作世界构建工具可在浏览器中运行。多个团队成员同时编辑同一场景。编辑器通过实时同步层通信变化。这是我们需要的协作创建模型，只是世界作为画布而不是游戏编辑器。

原生创作者平台（浏览器的教训）

这些平台作为原生应用运行，但其关于创作者工具、世界持久性和社交动态的设计决策直接适用。

Roblox：8000 万+ 日用户、2023 年付给创作者 7.4 亿美元。创建发生在引擎内。发现是社交的。证明创作者平台可自我维持的商业模型。

Roblox 是创作者世界的单一最重要参考。8000 万+ 日活用户。创作者构建其他玩家访问的完整 3D 体验（游戏、社交空间、商店）。平台处理托管、网络、发现和变现。

Roblox 做对的事：

• 创建在引擎内。 Roblox Studio 是玩家体验的同样环境。创作者瞬间测试其作品。无导出/上传/等待循环。对浏览器世界，编辑器应是世界本身。
• 脚本可达。 Lua（Roblox 脚本语言）足够简单，儿童学习。复杂行为可能但可选。地板低天花板高。
• 发现是社交的。 你找体验是因为朋友在玩。主页显示热门体验。对浏览器世界，世界本身是发现表面。你通过走动探索和找到东西。
• 变现工作。 创作者赚真钱（Roblox 在 2023 年付给创作者 7.4 亿美元）。这吸引严肃创意努力。无经济激励，创作者平台变为褪色的爱好项目。
• Roblox 的渲染引擎是自定义的且在原生应用中运行，不是浏览器。但每体验的资产预算按现代标准适中（推荐最大 100 MB）。大多数成功 Roblox 体验使用低多边形风格化艺术，与浏览器渲染约束一致。

Fortnite Creative / UEFN（Unreal Editor for Fortnite）。 Epic 把虚幻引擎的完整编辑器带给 Fortnite 创作者。结果是人们用专业级工具构建岛屿（自包含世界）的平台。Fortnite 处理托管、多人和分发。

相关洞见：

• 专业工具吸引专业内容。 UEFN 产生视觉惊艳的体验，因为创作者有 UE5 完整能力。权衡是复杂度。UEFN 有陡峭学习曲线。
• 基于岛屿的实例化（每个创作是独立世界）避免单一共享世界的审核和冲突问题。但这也意味着创作者不通过探索自然发现彼此作品。你通过菜单访问岛屿，不通过走动。
• 商业模型工作。 Fortnite 创作者计划基于参与度付款。顶级创作者年赚数百万。经济激励再次驱动质量。

Dreams（Media Molecule / PlayStation）。 Dreams 给主机玩家完整 3D 创作套件（建模、动画、音乐、逻辑、关卡设计）和分享创作平台。工具深度上是有史以来最雄心勃勃的创作平台。

相关洞见：

• 基于雕塑建模而不是多边形编辑。创作者用移/抓/平滑工具塑形软体积，类似 ZBrush 但更直观。学习曲线温和。这方法很好映射到浏览器内创建，因为不需理解顶点和 UV 图。
• 一切是共享资产。 如果某人创建树模型，任何人可在自己创作中使用（带归属）。这创建复合创意生态，每个创作让平台更有价值。
• Dreams 商业上挣扎尽管评论好。问题是分发：它锁定在 PlayStation，创建工具如此深以至于大多数玩家从未超越消费内容。教训：创建工具需要简单到大多数用户尝试，即使只有少数变成认真建造者。

Core（Manticore Games）。 基于虚幻引擎和简化编辑器构建多人游戏的免费平台。Core 编辑器作为原生应用运行，但哲学相关。模板和社区共享脚本让初学者从预制组件组装游戏。高级创作者可写 Lua 脚本做自定义行为。Core 挣扎找大受众，部分因为游戏必须通过 Core 启动器玩。基于浏览器版本不会有此摩擦。

VRChat 和 Rec Room 是创作者构建他人访问空间的社交平台。VRChat 使用 Unity 在 PC/VR 上运行。Rec Room 在包括移动的所有上运行。两者证明用户生成 3D 世界可维持大社区。VRChat 技术上更令人印象深刻（自定义着色器、复杂头像）。Rec Room 更易达（应用内创建工具、更简单图形、更广平台支持）。对浏览器世界，Rec Room 的简单应用内创建工具方法比 VRChat 的外部工具工作流更适用。

Second Life：2003 年发布，仍带 20 万+ 日用户运行。完全用户创建。基于地块所有权、年虚拟经济价值约 5 亿美元。20 年持久性和审核经验。

Second Life 是所有创作者世界的祖父。2003 年发布，仍带 20 万+ 日活用户运行。整个世界用户创建。土地被拥有和交易。创作者出售物体、服装和建筑。游戏内脚本语言（LSL）启用交互内容。

Second Life 20 多年教什么：

• 持久性比图形重要。 Second Life 视觉过时，但世界持久。创作留在你放置之处。关系和历史累积。这持久性让人们一直回来。
• 经济驱动创建。 Second Life GDP 估计年 5 亿美元。创作者建造因为能卖。无经济激励，创作者内容的量和质下降。
• 用户生成内容需要审核基础设施。 Second Life 经历 20 年审核挑战。任何用户可在共享空间放置任意内容的平台需要自动扫描、举报工具和人工审核。
• 基于土地的空间组织工作。 Second Life 把世界分成用户拥有的地块。每地块有 prim（物体）限制。这自然防止任何一个创作者消耗所有资源。对浏览器世界，带每块物体预算的基于块所有权是等价模式。

比较分析：每个游戏教我们什么

游戏	关键教训	适用技术	忽略风险
Skyrim	带 cell 网格的基于块流送	高度图地形、LOD 分级、内/外部分离	世界不适合浏览器内存
巫师 3	由独立团队分层世界组合	内容感知流送、假体渲染	创作者不能独立工作
旷野之息	系统化规则胜过脚本内容	材质交互系统、物理驱动玩法	世界感觉静态死寂
GTA V	环境生命让世界感觉真实	NPC 行为系统、交通、昼夜	创作者世界感觉像空博物馆
艾尔登法环	密度变化和资产复用	模块化资产库、稀疏 + 密集区域	要么太空要么填充太昂贵
无人深空	程序化生成做画布、创作者内容做灵魂	基于种子地形、紧凑基地数据模型	无限但无聊的地形
Minecraft	完全可编辑世界、简单工具、无限深度	块流送、调色板压缩、块编辑协议	创作者不能重塑世界本身
Roblox	创建在引擎内、经济驱动质量	世界内编辑器、创作者变现	没人建造因为没理由
Krunker.io	浏览器 UGC 用简单工具规模化	Three.js 渲染、基于体素编辑器、市场	创建工具对普通创作者太复杂
Hordes.io	浏览器 3D 中 200+ 玩家、独立开发者可行	自定义 WebGL、空间剔除、风格化艺术	过度工程化多人层
Vuntra City（原生参考）	速度感知流送和两层世界模拟保持巨大程序化城市连贯	速度耦合 LOD 策略、拓扑查询层、远场日程模拟 + 近场行为	高速穿越导致弹出和模拟峰值
Agar.io / Slither.io	空间划分启用大规模并发	按距离的可变 tick 率、兴趣管理	规模化时网络崩溃
Second Life	持久性和经济维持 20 年社区	基于地块所有权、物体预算、市场	无长期留存
Dreams	基于雕塑创建比多边形编辑直观	基于体积建模、共享资产库	创建工具感觉像 CAD 程序
Fortnite Creative	专业工具吸引专业内容	平台中的完整编辑器能力	内容质量上限太低
RuneScape	完整 MMO 通过 Wasm、二进制协议在浏览器中工作	Emscripten、自定义二进制 WebSocket 协议、瓦片流送	低估浏览器能处理什么
Habbo Hotel	简单房间创建维持 25 年社区	基于网格放置、虚拟家具经济	过度复杂化创建工具

对我们具体案例（基于浏览器、创作者聚焦、多人）最重要的游戏是 Minecraft（可编辑世界、紧凑数据）、Roblox（引擎内创建、经济）、Krunker（浏览器 UGC 规模化）和 Hordes.io（浏览器 MMO 架构）。AAA 作品（Skyrim、BotW、巫师 3）教渲染和流送。浏览器热门（Agar.io、Slither.io、Surviv.io）教规模化网络。创作者平台（Roblox、Dreams、Second Life）教社区动态。Vuntra City 为速度感知流送、故事性导航和现代程序化城市中百万代理模拟模式增加了当前的实现级参考。

Skyrim 和巫师在浏览器中会是什么样

让我们具体些。如果把 Skyrim 的 Whiterun 重建为浏览器投递：

地形： Whiterun 周围区域大约 2km x 2km。在我们块大小（64m）下，约 32x32 = 1024 块。每块高度图 2-4 KB，是 2-4 MB 地形数据。地形纹理（草、土、岩石、雪）作为 KTX2 atlas 瓦片可能再加 5 MB。地形总计：整个区域不到 10 MB。

结构： Whiterun 本身有约 40-50 建筑。每建筑作为优化 GLB（3 LOD 等级）在最高细节可能 200-500 KB。但你只需为最近 5-10 建筑做全细节。其余是中或低 LOD（每个 50-100 KB）。任意时刻可见结构总计：2-5 MB。

植被： Skyrim 在 Whiterun 周围的树和草都实例化。你需要约 10 个独特树模型（全 LOD 每个 200 KB，作为广告板假体 20 KB）和从密度图在 GPU 上生成叶片的草系统。植被资产总计：2-3 MB。5x5 块区域的实例化数据（位置、旋转、缩放）：500 KB 以下。

NPC： Whiterun 有约 70 命名 NPC 加守卫。中等质量每头像：100-200 KB。但任意时刻只有 10-20 可见。NPC 渲染数据总计：2-4 MB。

Whiterun 规模区域任意时刻可见总计：15-25 MB。 这在浏览器中绝对可行。初始加载会在宽带 3-5 秒内显示地形和主要结构，细节在接下来几秒内填入。

巫师 3 的 Novigrad 更大更密，但相同原则适用。你需要更激进的 LOD 和流送，但任意时刻可见数据总计保持在浏览器内存限制内。

我们会先构建什么

完整开放世界是多年项目。这里是快速把真实东西交给创作者的路径：

阶段 1：共享岛屿（3 个月）。 单地形块（512x512m 岛）带高度图地形、水、基本植被、昼夜循环。通过 Durable Objects 多人（最多 50 并发用户）。创作者可从其现有 Cinevva 库放置 AI 生成 3D 资产。把它视为共享立体模型。

阶段 2：可扩展世界（3 个月）。 4x4 km 世界的块流送。创作者拥有的地块他们有编辑权限。地形和物体的 LOD 系统。持久世界状态。跨世界最多 200 并发用户。

阶段 3：活世界（6 个月）。 AI 辅助地形雕塑。程序化植被和大气。任务/事件系统，所以创作者可构建交互体验，不只是静态场景。语音聊天。头像定制。世界成为目的地，不是演示。

开放问题

艺术风格。 风格化（低多边形、卡通渲染）渲染更便宜，对 AI 生成资产更宽容。写实需要更高质量资产和更多渲染预算。Skyrim 因为艺术指导一致尽管图形过时仍工作。BotW 在平板级硬件上美观，因为卡通渲染风格隐藏低多边形数。Minecraft 使用 16x16 纹理，是有史以来最具辨识度游戏之一。Krunker.io 和 Hordes.io 都在浏览器中用简单风格化图形成功。证据压倒性偏向浏览器世界的风格化方向。我们需要早期选择具体视觉身份并跨 AI 生成资产强制一致。

世界持久性 vs 实例化。 每个人共享一个世界（像 MMO 或 Second Life）还是创作者各自得到他人可访问的实例（像 Minecraft 服务器或 Fortnite 岛屿）？技术支持两者，但社交动态完全不同。Second Life 的持久共享世界创造偶遇发现（你通过走动偶然碰到他人作品）。Fortnite 的实例化岛屿需要菜单或门户系统做发现。Roblox 使用基于中枢方法：游戏分开但通过共享接口浏览和发现。混合可工作：持久共享上层世界，创作者拥有地块（像 Second Life 地块），通过门户进入独立体验的选项。

创建工具深度。 Dreams 证明深创建工具打动评论员但吓退用户。Townscaper 证明最小工具可卖百万份。Roblox Studio 在中间：对孩子简单，对专业人士深。Krunker 的体素编辑器更简单。对浏览器世界，我们应从 Townscaper 级简单（放置物体，它们对齐和连接）开始，随时间增加深度。在世界中放置首个物体的初始体验应不到 30 秒。

经济。 Roblox、Second Life 和 Fortnite Creative 都证明经济激励是把玩具变为平台的东西。无创作者能从其作品赚钱的方式，最有才创作者会在别处建造。这不需要第一天发布，但架构应支持（物体所有权、访问跟踪、创作者归属）。

移动。 移动上的 WebGPU 距可靠还有几年。移动体验需要降级版本：更简单地形、更少物体、更短视距。Rec Room 在一切上运行带适配质量的方法值得研究。或我们为移动发布原生应用，浏览器中保留完整体验。

审核。 任何人可放置任何东西的开放世界是审核噩梦。Second Life 处理这个 20 年。每个放置资产需要在对他人可见前自动内容审核。这给创作过程加延迟，但不可妥协。我们还应考虑基于地块内容评级（如 Second Life 的 General/Moderate/Adult 系统），让创作者选择内容边界。

系统化交互。 BotW 和 Minecraft 都显示基于材质交互系统比静态物体放置创造指数级更有趣世界。如果创作者放置木桥，另一创作者在附近生火，桥应燃烧吗？如果某人放置坝，水应在其后汇集吗？这些交互让世界感觉鲜活，但要求跨所有创作者内容一致物理和材质规则。决定系统化设计走多远是早期架构决策。

关键要点

浏览器 3D 开放世界今天可行。Hordes.io 在浏览器中 3D 运行 200+ 玩家。Krunker.io 带完整 3D 地图编辑器有 1000 万月玩家。.io 游戏证明浏览器多人扩展到数百万。技术不是推测。

渲染就绪。Three.js 和 Babylon.js 处理与 2010 年代初 AAA 游戏相当的 3D 场景。WebGPU 解锁地形和植被的 compute shader。Wasm 物理引擎在原生 2-3x 内运行。Whiterun 规模区域适合 15-25 MB 可见数据。

网络就绪。Cloudflare Durable Objects 在边缘给你每块权威服务器。CRDT 处理协作编辑无冲突。空间划分（从 Agar.io 到 Skyrim 每个游戏证明）在数百并发玩家保持网络流量可管理。

AAA 开放世界（Skyrim、巫师 3、BotW、艾尔登法环、Minecraft、无人深空）不只是图形基准。它们是块流送、LOD 管理、程序化生成、系统化设计和世界组合的教科书。它们使用的每个技术都有浏览器兼容等价物。

创作者平台（Roblox、Second Life、Fortnite Creative、Dreams）教社交和经济教训。创建必须在世界内发生，不在外部工具。经济激励驱动质量。持久性创造依恋。简单工具比强大工具达到更多创作者。

创意流水线是 Cinevva 有优势之处。我们已经生成 3D 资产、纹理和音频。把流水线连到世界放置系统是缺失部分。AI 生成内容填充世界。创作者策划和布置给它灵魂。

我们最终得到的不是浏览器中的 Skyrim。它更接近 Minecraft（可编辑世界）、Roblox（创作者经济）和 BotW（系统化交互）的交集，在浏览器标签中带 AI 驱动创建工具运行。构建它的技术存在。问题是执行。

研究论文和学术参考

本指南中技术不是从零发明。它们基于数十年研究。这些是每个子系统最重要的论文，附说明如何应用到浏览器开放世界。

地形生成和渲染

「An Image Synthesizer」 —— Ken Perlin（SIGGRAPH 1985）。DOI。引入 Perlin 噪声的论文。1985 年以来每个游戏中的每个程序化地形生成器都追溯到这。噪声函数产生平滑随机性，叠加 octave（分形布朗运动）时生成自然外观高度图。Simplex 噪声（Perlin，2001）是更快的继承者。对我们地形流水线，这是基础：基于噪声的高度图生成在 WebGPU compute shader 中以交互速度运行。

「Texturing and Modeling: A Procedural Approach」 —— Ebert, Musgrave, Peachey, Perlin, Worley（1994，第 3 版 2003）。程序化生成的教科书。Musgrave 关于地形建模的章节，包括带侵蚀状特征的多分形地形，是现代游戏地形生成器的直接基础。这里描述的 fBm 参数（lacunarity、persistence、octave 数）是我们会向创作者暴露做地形定制的参数。

「Geometry Clipmaps: Terrain Rendering Using Nested Regular Grids」 —— Losasso 和 Hoppe（SIGGRAPH 2004）。DOI。这论文解决了如何用同心 LOD 环（clipmap）以交互速率渲染巨大地形。地形网格是固定的、以相机为中心的嵌套网格集。相机移动时，网格偏移和更新。这是地形章节中为 WebGL 2 推荐的技术，工作因为 GPU 工作量不论世界大小都恒定。原始实现先于 WebGL，但直接映射到它。

「Fast Hydraulic Erosion Simulation and Visualization on GPU」 —— Mei, Decaudin, Hu（2007）。PDF。把水力侵蚀从 CPU 受限离线过程移到实时 GPU 计算。论文的浅水模拟模型（把水视为高度场，计算网格 cell 间流）在 compute shader 中运行。对我们流水线，服务端 GPU 侵蚀可在不到一秒内把噪声生成地形变换为地质合理景观，让 AI 生成地形看起来手工雕刻。

「Real-Time Rendering of Procedurally Generated Planets」 —— 无人深空 GDC 演讲的混合方法和 Sean Murray 的描述。虽然不是单论文，但 Hello Games 的 Innes McKendrick 在 GDC 2017 演讲「Building Worlds Using Maths」详述无人深空如何使用堆叠噪声函数、带 marching cubes 的体素表示和 GPU 侧生成生成行星级地形。直接相关我们的程序化地形方法，特别对生成高度图无法表示的地形特征（洞穴、拱门）。

「C-DBLOD: Hybrid LOD for Terrain Rendering」 —— Filip Strugar（2014）。论文。geometry clipmap 的改进，增加基于四叉树选择以在相机位置周围更好适应性。关键洞见：不是固定同心环，使用四叉树选择不同分辨率的地形 patch。这比纯 clipmap 更好处理不规则地形（一些区域比其他需要更多细节）。可在 WebGL 2 中实现，带小 CPU 侧四叉树遍历。

3D 高斯泼溅和神经渲染

「3D Gaussian Splatting for Real-Time Radiance Field Rendering」 —— Kerbl, Kopanas, Leimkühler, Drettakis（SIGGRAPH 2023）。项目页。引发高斯泼溅革命的论文。场景表示为数百万 3D 高斯，每个带位置、协方差（形状）、不透明度和球谐颜色系数。渲染按深度排序泼溅并光栅化为 2D 高斯。方法比 NeRF 训练快 100-1000x，以实时速率渲染。存在多个 WebGL/WebGPU 实现。对我们平台，这启用创作者用手机照片捕获真实物体并放入浏览器世界。

「NeRF: Representing Scenes as Neural Radiance Fields for View Synthesis」 —— Mildenhall 等（ECCV 2020）。项目页。基础神经场景表示论文。神经网络把 3D 坐标映射到颜色和密度，启用从输入照片集的写实新视图合成。虽然 NeRF 在浏览器中渲染太昂贵（需要每像素网络评估），NeRF 到网格提取流水线（训练 NeRF，然后在密度场上运行 marching cubes）从照片产生高质量纹理网格。

「Instant Neural Graphics Primitives with a Multiresolution Hash Encoding」 —— Müller, Evans, Schied, Keller（SIGGRAPH 2022）。项目页。用多分辨率哈希表做空间编码把 NeRF 训练从数小时减到数秒。这使 NeRF 实用于生产。哈希编码技术也适用于浏览器世界中的其他空间数据（大 3D 数据集中快速查找）。

「Neuralangelo: High-Fidelity Neural Surface Reconstruction」 —— Li 等（CVPR 2023）。项目页。使用多分辨率哈希编码和 SDF（有符号距离函数）估计的数值梯度从神经表示提取高质量三角网格。输出网格直接可用在浏览器 3D 引擎。对我们资产流水线，Neuralangelo（或类似工具如 NeuS2）可把 NeRF 捕获转换为带干净几何和烘焙纹理的 Web 就绪 GLB 文件。

多人网络和状态同步

「Interest Management in Massively Multiplayer Online Games」 —— Boulanger, Kienzle, Verbrugge（2006）。DOI。MMO 兴趣区（AOI）管理技术综合调查。覆盖基于网格、基于光环和混合方法做基于空间相关性过滤网络更新。基于网格方法（映射到我们块系统）对均匀密度世界最高效。基于光环方法（每实体影响半径）对变化密度更好工作。我们推荐基于块 AOI 带 AOI 内基于优先级更新率从此研究汲取。

「Dead Reckoning: Latency Hiding for Networked Games」 —— Pantel 和 Wolf（2002）。DOI。形式化 dead reckoning（基于上次已知速度预测实体位置）用于网络游戏。论文量化权衡：更高预测阈值减少带宽但增加修正期间可见位置误差。对带 50-200ms 延迟的浏览器游戏，0.5-1.0 米预测阈值保持修正不可见，同时减少位置更新带宽 60-80%。

「Conflict-free Replicated Data Types」 —— Shapiro, Preguiça, Baquero, Zawirski（2011）。DOI。基础 CRDT 论文。定义无需协调收敛的基于状态和基于操作 CRDT。对我们世界编辑系统，相关 CRDT 是：LWW-Register（Last-Writer-Wins Register）用于有单值的物体属性（位置、旋转、颜色），OR-Set（Observed-Remove Set）用于块中物体集合（处理并发 add/remove 无冲突）。Yjs 在 JavaScript 中高效实现这些。

「Time Warp: A Mechanism for Distributed Simulation」 —— Jefferson（1985）。DOI。原始乐观分布模拟论文。虽然 Time Warp 本身对浏览器游戏太复杂，但核心洞见（乐观处理事件，如果来自另一节点的冲突到达则回滚）是带服务器协调的现代客户端预测的基础。这是每个响应多人游戏工作方式：客户端本地预测、发送动作到服务器、如果服务器不同意则修正。

「The TRIBES Engine Networking Model」 —— Frohnmayer 和 Gift（GDC 1999）。带兴趣管理、优先化状态更新和带宽预算的客户端-服务器游戏网络的最早实用描述之一。「ghost manager」概念（服务器维护每客户端看到了什么的视图，仅发送该视图的 delta）正是我们基于块的 Durable Object 架构实现的。这 GDC 演讲是大多数现代游戏网络的智力祖先。

「Source Multiplayer Networking」 —— Valve（2009）。开发者文档。Valve 对 Source 引擎网络模型（用于半条命 2、CS:GO、军团要塞 2）的文档。覆盖客户端预测、实体插值、延迟补偿和「快照」系统，服务器以规则间隔发送完整世界状态而客户端在快照间插值。这是权威服务器网络的金标准，直接适用我们架构。

程序化生成

「Model Synthesis: A General Procedural Modeling Algorithm」 —— Merrell（2007）。DOI。Wave Function Collapse 的前身之一。从示例模型通过传播局部约束生成 3D 结构。算法通过迭代坍缩可能性最少 cell（最小熵启发式）确保全局一致性。这是 Townscaper 和类似生成器从简单用户输入产生连贯结构的方式。

「WaveFunctionCollapse」 —— Maxim Gumin（2016）。GitHub。不是传统论文，但带广泛文档的开创性开源项目。算法接受小示例图像或瓦片集并生成在局部与输入相似的更大输出。对创作者世界，WFC 可从小创作者定义规则集生成建筑布局、道路网络、地下城地图和地形细节。多个 JavaScript 实现存在。

「Wave Function Collapse is Constraint Solving in the Wild」 —— Karth 和 Smith（FDG 2017）。DOI。WFC 的学术分析，澄清其与约束满足关系，显示如何分析和扩展。相关用于理解 WFC 的限制（可能卡住需要回溯）以及如何设计避免这些问题的瓦片集。

「Superposition Theorem and Its Implications for the Procedural Generation of Game Content」 —— Sandhu 等（2022）。探索使用量子启发叠加概念做程序化内容生成。虽然推测，但在最终配置前维护多个可能状态的数学框架正是 WFC 工作方式，可启示更复杂的生成系统。

实时渲染技术

「Real-Time Rendering」 —— Akenine-Möller, Haines, Hoffman（第 4 版，2018）。标准教科书。第 19 章（加速结构）、第 20 章（高效着色）和第 21 章（虚拟和增强现实）特别相关。这里描述的视锥剔除、遮挡剔除和 LOD 算法是 Three.js、Babylon.js 和每个游戏引擎实现的。不是论文，但权威参考。

「A Survey on Baking Neural Radiance Fields for Real-Time View Synthesis」 —— Reiser 等（2023）。DOI。调查把 NeRF 转换为实时渲染格式（网格、纹理、稀疏体素网格）的方法。直接相关我们资产流水线，服务端神经捕获需产生浏览器可渲染输出。

「Scalable and Accurate Online Feature Matching Using 3D Gaussian Splatting」 —— 多个组（2024-2025）。多个最近论文探索高斯泼溅的编辑、合成和动态场景。相关因为创作者世界需要把多个泼溅场景（每个创作者的捕获物体）合成到单一连贯场景。泼溅编辑（重新上色、形变、合成）的方法是活跃研究领域。

「Efficient GPU Screen-Space Ray Tracing」 —— McGuire 和 Mara（JCGT 2014）。DOI。我们水渲染部分使用的屏幕空间反射背后的论文。通过深度缓冲追踪光线做近似反射，无全光线追踪成本。「分层追踪」变体（使用最小-最大深度 mipmap）在 WebGL 2 上高效运行。

「Simulating Ocean Water」 —— Jerry Tessendorf（2001）。PDF。基于 FFT 海洋模拟的基础论文。描述 Phillips 谱（海洋波统计模型）以及如何通过逆 FFT 把它变换为空间位移图。每个带写实海洋的主要游戏（Sea of Thieves、刺客信条、神秘海域）使用。FFT 计算干净映射到 WebGPU compute shader。

「Precomputed Atmospheric Scattering」 —— Bruneton 和 Neyret（EGSR 2008）。DOI。物理准确天空渲染背后的论文。把大气散射预计算到片元着色器在实时采样的查找表。从第一原理产生正确天空颜色、空气透视（远物体看起来发蓝/朦胧）和日落/日出颜色。预计算表小（几百 KB），运行时着色器便宜。Three.js 的 Sky 着色器和 Babylon.js 的程序化天空都是这方法的简化版。

「Ambient Occlusion Volumes」 —— McGuire（HPG 2010）和**「Scalable Ambient Obscurance」** —— McGuire, Mara, Luebke（HPG 2012）。PDF。现代 SSAO 实现背后的论文。SAO 是浏览器 3D 引擎中最常实现的变体，因为它高效（每像素一次深度缓冲采样）且产生合理接触阴影。算法采样每像素周围的深度缓冲估计它被附近几何「遮挡」多少。Three.js 和 Babylon.js 都实现 SAO 衍生 SSAO。

人群渲染和动画

「GPU Crowd Rendering」 —— Dudash（2007）以及随后 GDC/SIGGRAPH 关于实例化人群渲染的演讲。核心技术：把骨骼动画帧烘焙到纹理（Vertex Animation Texture），然后把人群渲染为实例化网格，每个实例基于当前帧从动画纹理读其骨骼变换。这把动画评估与绘制调用解耦，允许单次实例化绘制调用渲染数百独特动画角色。

「Position Based Dynamics」 —— Müller 等（2007）。DOI。PBD 基础论文，是现代游戏引擎如何模拟布、头发和软体。Rapier（我们推荐 Wasm 物理引擎）使用 PBD 衍生求解器。对头像定制（披风、飘动头发、宽松服装），PBD 在游戏帧率提供响应模拟。Wasm 实现保持它在主 JavaScript 线程之外。

「FABRIK: A Fast, Iterative Solver for the Inverse Kinematics Problem」 —— Aristidou 和 Lasenby（2011）。DOI。我们头像部分推荐 IK 求解器背后的论文。FABRIK 通过交替从末端到根和根到末端达到工作，3-5 次迭代收敛。它比基于雅可比 IK 快，自然处理关节约束，简单实现（基本求解器约 50 行代码）。Three.js 和 Babylon.js IK 实现都从 FABRIK 衍生。

虚拟世界和协作环境

「Massive Multiplayer Online Games: A Survey of the State-of-the-Art」 —— Yahyavi 和 Kemme（2013）。DOI。MMO 架构综合调查，覆盖客户端-服务器模型、点对点方法、兴趣管理、一致性模型、可扩展性技术和防作弊。一致性模型分类（严格、最终、因果）映射到我们基于 CRDT 方法（带通过向量时钟因果排序的最终一致性）。

「A Distributed Architecture for Multiplayer Interactive Applications on the Internet」 —— Diot 和 Gautier（1999）。DOI。识别核心张力的分布虚拟环境早期研究：严格一致性需要协调（增加延迟），而弱一致性允许响应但冒可见不一致风险。论文主张「本地滞后」（延迟本地显示一小段时间给远程更新到达时间）作为中间方案。对世界编辑（放置物体），100-200ms 本地滞后不可察觉，给服务器验证时间。

「The Second Life Grid: The Architecture of a Near-Contemporary Open Source Virtual World」 —— Linden Lab 技术文档和社区反向工程。虽然不是单论文，Second Life 架构的技术分析广泛记录。关键洞见：每 256x256m 区域运行在专用服务器实例。物体存储为「primitive」（带变换、纹理和脚本的基本形状）树。查看器按需流送物体描述和纹理。这种带每物体持久性的基于地块模型是我们构建之物最接近的现有架构，Second Life 20+ 年运营证明它扩展。

Web 图形和浏览器性能

「WebGPU: A High-Performance Graphics API for the Web」 —— W3C GPU for the Web 工作组（2023-持续）。规范。WebGPU 的正式规范。不是研究论文，但浏览器 GPU 编程的权威技术文档。Compute shader 规范（第 23 节）特别相关我们整指南描述的地形生成、植被散布和粒子系统。

「WebAssembly: A Framework for Running Compiled Code in the Browser」 —— Haas 等（PLDI 2017）。DOI。来自浏览器供应商的原始 WebAssembly 论文。证明 Wasm 对计算密集工作负载达到原生 2x 内性能。这验证我们对浏览器开放世界推荐 Wasm 编译物理引擎（Rapier、Havok）。论文性能分析显示开销主要来自边界检查和间接函数调用，不是编译模型本身。

「Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code」 —— Jangda 等（USENIX ATC 2019）。PDF。Wasm vs 原生性能的严格基准。发现 Wasm 在 SPEC CPU 基准套件平均比原生 C 慢 1.45x-1.55x。具体对游戏物理（浮点重、少系统调用），开销在下端（约 1.3x）。这确认浏览器中 Wasm 物理对实时游戏工作负载可行。

「Bringing the Web up to Speed with WebAssembly」 —— Rossberg 等（2018）。DOI。描述 WebAssembly 的设计理由和形式语义。特别相关：内存安全保证讨论（第 3 节）解释 Wasm 模块如何能与 JavaScript 安全共享浏览器标签而无原生插件的安全风险。这是让运行物理引擎（传统是 C++ 库）在浏览器中安全的原因。

AI 驱动内容生成

「Text-to-3D Generation with Bidirectional Diffusion Using Both 2D and 3D Priors」 —— 多个组（2023-2025）。多个最近论文（DreamFusion、Magic3D、ProlificDreamer、MVDream、Zero-1-to-3++）通过使用 2D 扩散模型作为 3D 优化先验，探索从文本提示生成 3D 资产。质量从 2023 年初到 2025 年大幅改善，从团块形状到详细纹理网格。对我们平台，这些模型（服务端 GPU 上运行）是创作者资产流水线中的「AI 生成」步骤。

「DreamFusion: Text-to-3D using 2D Diffusion」 —— Poole 等（ICLR 2023）。项目页。Score Distillation Sampling（SDS）的基础论文，使用预训练 2D 扩散模型引导 3D 优化。关键洞见：如果你能用现有 2D 模型评估 3D 物体的渲染视图是否匹配文本提示，你不需要 3D 训练数据。这打开了文本到 3D 生成大门，是后续工作（Magic3D、ProlificDreamer）改善质量和速度的基础。

「LRM: Large Reconstruction Model for Single Image to 3D」 —— Hong 等（ICLR 2024）。项目页。在单 GPU 上 5 秒从单图像重建 3D 模型。模型输出可转换为网格的类 NeRF 表示。对创作者世界，这意味着创作者可拍任何真实世界物体的照片并在几秒内得到 3D 模型。速度使它作为交互工具可行，而不是批处理。

「Procedural Content Generation via Machine Learning (PCGML)」 —— Summerville 等（2018）。DOI。游戏中使用机器学习做程序化内容生成的调查。覆盖关卡生成、物品生成、叙事生成和世界生成。特别相关：「可控生成」讨论，设计师设高层参数，ML 模型填细节。这是 AI 辅助世界构建的范式：创作者设意图（「让这个区域变恐怖森林」），AI 填几何、纹理和填充。

这些论文如何连接到我们的架构

研究按层映射到我们架构：

地形流水线： Perlin/simplex 噪声（Perlin 1985、2001）生成基础高度图。水力侵蚀（Mei 等 2007）增加地质真实感。Geometry clipmap（Losasso 和 Hoppe 2004）或 CDLOD（Strugar 2014）在浏览器中高效渲染地形。大气散射（Bruneton 和 Neyret 2008）让远地形看起来正确。

资产流水线： 文本到 3D（DreamFusion 等）和图像到 3D（LRM）服务端生成资产。高斯泼溅（Kerbl 等 2023）启用照相测量捕获。Neuralangelo（Li 等 2023）从神经捕获提取干净网格。所有输出处理为浏览器就绪 GLB/KTX2。

渲染： SSAO（McGuire 2012）增加深度。屏幕空间反射（McGuire 和 Mara 2014）驱动水。FFT 海洋（Tessendorf 2001）模拟水。顶点动画纹理（Dudash 2007）渲染人群。FABRIK（Aristidou 和 Lasenby 2011）驱动角色 IK。

网络： 兴趣管理（Boulanger 等 2006）按空间相关性过滤更新。Dead reckoning（Pantel 和 Wolf 2002）减少带宽。CRDT（Shapiro 等 2011）处理协作编辑。带服务器协调的客户端预测（Jefferson 1985、Valve Source Networking）提供响应。

世界生成： WFC（Gumin 2016、Karth 和 Smith 2017）生成结构和布局。PCGML（Summerville 等 2018）提供 AI 辅助生成框架，创作者设意图，模型填细节。

研究成熟。这些技术中大多数已在已发布游戏中使用多年。把它们带到浏览器的创新不是算法，而是工程化让它们在浏览器内存、GPU 和网络约束内工作，这是本指南其余部分讲的。

延伸阅读

• 2026 年 Web 游戏技术栈 涵盖 WebGL、WebGPU 和 WebAssembly 基础
• Web 游戏引擎对比 对比浏览器投递引擎
• Three.js + USDC 技术报告 关于在浏览器中加载 3D 资产
• 前沿开源生成 AI 模型 用于 AI 生成流水线
• 合作游戏设计 关于让玩家保持参与的多人设计模式
• 浏览器开放世界的景观生成 —— 地形、侵蚀和植被渲染
• WebSocket 多人基础 —— 浏览器多人网络入门
• WebGPU 入门 —— 下一代浏览器 3D 渲染 API
• 流式资产加载 —— 大 3D 世界的渐进加载模式