AO 重构

[jayli]

17eaa2f

提示词：

/superpowers:brainstorm 我正在优化游戏的 fps 性能问题，前几次提交对chunk的加载性能做了优化，现在性能的瓶颈基本上是在 AO 阴影的绘制上。现在 AO 阴影的绘制是很久之前重构的，经过chunk加载的性能优化后，AO 阴影的绘制已经不太匹配现在的游戏架构，导致玩家在跟主世界互动的时候（新增或者删除方块、或者用mag7消除方块），存在部分方块的 AO 没有正确绘制的现象。所以我想站在性能优先的角度，完全的重构 AO 阴影的实现，完全重新设计并实现，以跟当前的 chunk 加载、删除方块时的及时补面、faceculling、以及 instancedMesh 管理和consolidation时机很好的兼容。做到玩家放置方块、移除方块、tnt炸毁方块、Mag7 批量清除方块、机枪快速删除方块等场景都能很好的跟进 AO 阴影绘制。

所以请你全面review当前代码中的 AO 的实现，不论在主进程中，还是在 worker中，都要完全掌握。在完全掌握的情况下，给出你的重构方案。

我的AO阴影绘制的要求：

1. 我对方块AO阴影绘制的实时性要求不高，即当放置方块后，先完成 faceculling，然后完成consolidation，当新放置的方块完成实例化并集成到 blockData 后，方块的数据都同步妥当后，最后执行一次 AO 的绘制。
2. AO 阴影的绘制的计算要尽可能的放在 worker 中，对算力的消耗尽量不要干扰主进程的逻辑。
3. AO 阴影的绘制的范围，在合理的基础上要尽可能的少，比如玩家跟主世界互动的时候，AO 的绘制应当只覆盖受影响的方块，比如删除方块的邻居，放置方块的相邻和相交的方块。再比如chunk刚加载的时候，如果cpu算力很紧张的话，可以先不绘制 AO 阴影，可以后续流程中补刷 AO 阴影。当然如果能在不影响cpu计算压力的前提下，能在chunk生成时携带AO阴影也可以。
4. AO 阴影的绘制应当只绘制必要的 方块面，比如裸露在空气的面应当绘制，非裸露在空气中或者水中的面是不应该有 AO 阴影，因为面不可见。再比如，山体深处的方块的面因为被 faceculling 掉了，也不会有 AO 绘制。
5. AO 阴影只在非透明的实心方块的面上才绘制，其他类型的方块的面不做绘制，跟现在的规则一致。
6. 还有一种情况，可能不太会出现，有可能极低概率出现，就是一个方块的面有可能会被重复绘制，这种情况要避免，当一个位置的方块的面绘制了AO，如果在方块格局没有变化的情况下，另外一个进程或者逻辑又想重新绘制它，不应当重复绘制，除非出现了方块放置和删除等动作。即方块的面着色的 AO 阴影不应当重叠。
   方块坐标的处理要一致，要用整数坐标，不要用浮点坐标。

在实现机制上，玩家放置和删除方块后，我只要求视觉上不要出现空洞，即及时补面的动作要立即完成，后续会有 face culling 和 consolidation 的动作，最后才是 AO 的绘制，尽量遵守这个时序。AO 阴影只影响视觉效果，不影响功能，所以放在时序的最后较为合理。

最后有一个坑，就是避免mag7快速消除方块时，AO 跟不上的bug，之前的AO的绘制的实现花了很大的精力解决这个问题，在这次提交后03bd0158af99ac35563a72f148f5c460ae4255ac当时解决了问题，目前随着功能的迭代，这个问题又出现了，请你考虑新的重构不要再次出现这种遗留问题。

另外还有一个坑，74c1052422e2e54684f54b1bae56f636648ad877 这次提交修复的问题，一个方块会被不同的chunk同时拥有，导致会被绘制多份 AO，目前应该已经修复了，请你顺便检查不要复现这个问题。

请注意 ，方块面的 AO 的绘制，不要受到方块方向的影响。f48ceedf2198408ded5c6ef94710602df21c5153 和 2a6de61 这2次提交修复了AO不受方块方向的影响，且修复了及时补面的问题。

再请注意几个事项：

1. 删除一个方块的时候，这个方块紧邻的面不要都是黑色，紧邻的面刚因为没接触空气，不应该有AO阴影，删除时的动作应该是及时补面的面不带AO阴影，待后续刷新时补刷AO阴影。
2. AO 刷新应该只刷新跟删除方块相邻的方块的面的 AO 阴影，即以删除方块为中心，前后、上下、左右一共六个方块的AO面要做刷新，不是整个chunk的所有方块的面要做刷新。
3. 更新AO阴影的时候，应该直接把新的AO替换到老的 AO，不要先删除再着色，中间间隔了几十毫秒，避免感觉到明显的闪烁。
4. 如果玩家连续1秒内删除方块时，删除方块A后，设定了定时器1秒后等consolidation后执行 AO 刷新，在1秒内删除了方块B，应该把删除方块A后设定的定时器删除，同时设定一个新的定时器，等B被删除1秒后等consolidation后执行 AO 刷新，也就是说，连续快速放置或者删除方块后，只在最后一次 consolidation 后执行一遍 AO 刷新。我还是那个原则，不要让 AO 和其他方块操作重叠，等所有方块的处理都完成后，最后再执行 AO 刷新。甚至你可以为了确保时序性，把 AO 定时器比 consolidation 再晚100毫秒都可以。
5. 在强调一遍，我不需要玩家在放置和删除方块的时候立即进行AO计算，我也不需要隐藏面（不接触空气的面）进行 AO 着色计算。因此隐藏起来的面（被faceculling的面，接触另外的实心非透明方块的面）都不应该绘制 AO
   着色（因为玩家看不到，所以不用AO着色），只有接触空气、水、玻璃等等透明非实心方块的面才会绘制 AO。
6. 你的重构不要破坏消除方块时的及时补面的逻辑，这一步是确保基本的视觉元素不破损的关键。当前代码的及时补面的逻辑是正确的，不要破坏当前的及时补面的功能。
7. 通常情况，当删除或者放置方块的时候，先移除/或新增 InstancedMesh 中的实例，然后创建动态网格，这个过程会产生闪烁。你的重构请避免这种情况的发生。即当方块被删除时，邻居方块的 AO 值会从旧值变为新值，这个变化过程导致了闪烁。
8. 重构过程中最容易忽略的问题就是跨chunk的实体方块的 AO 的绘制容易丢失，这个问题很容易发生在新chunk（特别是玩家奔跑过程中新加载的chunk）携带的跨chunk方块上。也有可能是当 AO 计算需要查找邻居方块时，邻居可能位于另一个 Chunk 中，而当前 Chunk 的 blockMap 中没有那个邻居的数据，这时非常容易出错，请你注意处理好。
   重构过程中容易引入的问题是实体被Chunk切割，现在的代码是好的，注意这类实体被chunk切割的问题不要被引入进来。
   连续放置和删除方块时（不超过1秒内），当玩家连续不超过1秒间隔删除方块时，要记录被删除方块的位置，放入一个队列，最后统一刷新AO的时候，要依次将1秒内删除方块的队列中的方块位置周边六个方块都要做AO刷新，刷新完成后清空队列。这个动作是防止过快的删除方块或者放置方块时，避免最后刷新AO的方块只刷新最后一次操作的方块的邻居方块的面，而是所有未来得及刷新的操作方块的周边六个方块的面的 AO 都要做刷新，所以需要一个队列来记住快速操作的方块。刷新完后再清空这个队列。

当前代码的 AO 功能上是ok的，只是性能有问题。你的实现需要参照当前AO的逻辑，确保功能上是完整的。核心解决性能问题。我需要你重新实现，实现方式要足够的清，在设计上就要规避多管线冲突的问题，渲染时序的问题，对方块行为依赖的问题等。

请你详细review代码，为我重构AO的实现，要求功能完整,性能最优。

[jayli]

#61

[jayli]

  AO 系统重构代码审查报告

  一、变更概览

  ┌──────────────────────────────────┬──────────┬──────────────────────────────────────────────┐
  │               文件               │ 变更类型 │                   主要改动                   │
  ├──────────────────────────────────┼──────────┼──────────────────────────────────────────────┤
  │ src/workers/AOWorker.js          │ 新增     │ 专用 AO 计算 Worker                          │
  ├──────────────────────────────────┼──────────┼──────────────────────────────────────────────┤
  │ src/core/AOSystem.js             │ 大幅删减 │ 从复杂类简化为空壳                           │
  ├──────────────────────────────────┼──────────┼──────────────────────────────────────────────┤
  │ src/world/Chunk.js               │ 大量修改 │ 添加脏集管理、AO 调度、结果应用              │
  ├──────────────────────────────────┼──────────┼──────────────────────────────────────────────┤
  │ src/world/ChunkConsolidation.js  │ 修改     │ 创建 AOWorker 实例， consolidation 后触发 AO │
  ├──────────────────────────────────┼──────────┼──────────────────────────────────────────────┤
  │ src/world/World.js               │ 修改     │ 移除旧 AO 队列，添加 AO 刷新触发             │
  ├──────────────────────────────────┼──────────┼──────────────────────────────────────────────┤
  │ src/workers/FaceCullingWorker.js │ 简化     │ 移除 AO 相关消息处理                         │
  └──────────────────────────────────┴──────────┴──────────────────────────────────────────────┘

  ---
  二、设计亮点

  1. 架构清晰，职责分离 ✅

  - AOWorker 专职计算，Chunk 管理脏集，ChunkConsolidation 协调时序
  - 消息协议简单明确：{requestId, chunkKey, positions, blockData, neighborChunks}

  2. 脏集机制最小化计算范围 ✅

  // Chunk.js:459-482 _markDirtyAO
  // 标记 3x3x3 邻居（26邻居全覆盖），AO 顶点着色依赖对角线方向
  for (let dx = -1; dx <= 1; dx++) {
    for (let dy = -1; dy <= 1; dy++) {
      for (let dz = -1; dz <= 1; dz++) {
        if (dx === 0 && dy === 0 && dz === 0) continue;
        this._addDirtyAOPosition(fx + dx, fy + dy, fz + dz);
      }
    }
  }
  这是正确的，AO 计算确实需要 26 邻居。

  3. 防抖机制避免重复计算 ✅

  // Chunk.js:525-536 _scheduleAORefresh
  _scheduleAORefresh(options = {}) {
    if (this.aoRefreshTimer) clearTimeout(this.aoRefreshTimer);
    this.aoRefreshTimer = setTimeout(() => {
      this.aoRefreshTimer = null;
      this._executeAORefresh();
    }, 100);
  }
  连续操作只刷新一次，解决 Mag7 快速删除的 AO 跟不上问题。

  4. 时序正确 ✅

  方块操作 → 补面(neutral AO) → consolidation → 100ms后 AO 刷新
  AO 刷新在 consolidation 之后，确保 InstancedMesh 已生成。

  5. 跨 Chunk AO 处理 ✅

  - _addDirtyAOPosition 自动处理跨 Chunk 标记
  - AOWorker 接收 neighborChunks 快照用于跨边界计算
  - _markBoundaryDirtyAO 只刷新边界列，避免全量重算

  6. 结果应用无闪烁 ✅

  // Chunk.js:676-735 _applyAOResults
  // 直接覆写 attribute 值，无删除-重建中间态
  aoLowAttr.array[idx] = r.aoLow;
  aoHighAttr.array[idx] = r.aoHigh;

  ---
  三、潜在问题

  1. AO 操作队列可能重复标记 ⚠️

  // Chunk.js:459-482 _markDirtyAO
  this._aoOperationQueue.push({ x: fx, y: fy, z: fz, includeSelf });

  // 同时立即标记 3x3x3 邻居
  for (let dx = -1; dx <= 1; dx++) {
    // ...
  }
  _markDirtyAO 立即标记了 3x3x3 邻居，_flushAOOperationQueue
  又会基于队列再次标记，存在重复工作。但功能上正确，只是效率略低。

  2. 内存占用：blockData 快照 ⚠️

  // Chunk.js:661-667 _executeAORefresh
  blockData: { ...this.blockData },
  neighborChunks
  每次 AO 刷新都创建 blockData 浅拷贝，对于大 Chunk 可能有 GC 压力。建议后续监控性能。

  3. 回调映射未清理超时 ⚠️

  // ChunkConsolidation.js:275-282
  aoCallbacks.set(requestId, callback);
  // Worker 返回后删除
  aoCallbacks.delete(requestId);
  如果 Worker 从不返回（如异常），回调会永久留在 Map 中。建议添加超时清理。

  4. AOSystem.js 空壳保留 ⚠️

  // AOSystem.js
  export class AOSystem {
    constructor() {
      console.warn('AOSystem is deprecated...');
    }
  }
  保留空壳是安全的迁移策略，但应在后续版本完全移除。

  ---
  四、代码质量评分

  ┌───────────────┬──────┬───────────────────────────────────────────────────────┐
  │     维度      │ 评分 │                         说明                          │
  ├───────────────┼──────┼───────────────────────────────────────────────────────┤
  │ 架构设计      │ 9/10 │ 脏集 + Worker 架构清晰，职责分离良好                  │
  ├───────────────┼──────┼───────────────────────────────────────────────────────┤
  │ 性能优化      │ 8/10 │ 最小计算范围、防抖、异步，但 blockData 拷贝有优化空间 │
  ├───────────────┼──────┼───────────────────────────────────────────────────────┤
  │ 时序正确性    │ 9/10 │ consolidation → AO 刷新顺序正确，跨 Chunk 处理完整    │
  ├───────────────┼──────┼───────────────────────────────────────────────────────┤
  │ 代码可读性    │ 8/10 │ 注释充分，命名清晰，逻辑易于理解                      │
  ├───────────────┼──────┼───────────────────────────────────────────────────────┤
  │ 历史 Bug 防护 │ 9/10 │ Mag7、跨 Chunk 双重绘制、方向影响 AO 等问题都有防护   │
  ├───────────────┼──────┼───────────────────────────────────────────────────────┤
  │ 边界处理      │ 8/10 │ 跨 Chunk 场景、Chunk 加载/卸载边界处理完善            │
  └───────────────┴──────┴───────────────────────────────────────────────────────┘

  综合评分：8.5/10

  ---
  五、建议

  1. 短期优化：
    - 为 aoCallbacks 添加超时清理机制
    - 考虑使用 structuredClone 或 JSON.parse/stringify 确保快照隔离
  2. 长期优化：
    - 监控 AO 刷新频率和耗时，必要时引入优先级队列
    - 完全移除 AOSystem.js 空壳
  3. 测试建议：
    - 测试快速连续放置/删除 50+ 方块，验证防抖效果
    - 测试跨 Chunk 边界放置方块，验证 AO 正确性
    - 测试 Chunk 加载/卸载时的 AO 边界一致性

  ---
  六、结论

  这次 AO 系统重构是一次高质量的架构升级。核心改进：

  1. 性能：AO 计算从主线程移到 Worker，脏集机制避免全量遍历
  2. 稳定性：防抖 + 正确时序解决历史 Bug
  3. 可维护性：职责分离，代码清晰

  推荐合并，但建议补充超时清理机制后再合并。

[jayli]

TODO：

3x3x3 的 AO 刷新范围，刷新之前要先去重

[jayli]

2380e5e...8b977a8

完整的代码变更

[jayli]

0bf0a5a...8b977a8

修复幻影方块的问题

[jayli]

---

[jayli]

当前AO系统的review：

---

AO 阴影系统审查报告

执行摘要

经过全面代码审查，发现 AO 系统存在关键性能问题：被隐藏的面（不可见面）仍然进行
AO 计算，浪费了大量计算资源和内存。同时发现若干内存使用优化空间。

---

一、系统架构概览

AO 系统采用三层架构：

┌────────┬───────────────────┬─────────────────────────────┐
│ 层级 │ 职责 │ 关键文件 │
├────────┼───────────────────┼─────────────────────────────┤
│ 计算层 │ AO 值计算 │ AOWorker.js, AOUtils.js │
├────────┼───────────────────┼─────────────────────────────┤
│ 数据层 │ AO 数据存储与更新 │ Chunk.js (dirtyAOPositions) │
├────────┼───────────────────┼─────────────────────────────┤
│ 渲染层 │ AO 数据传递到 GPU │ Chunk.js, WorldWorker.js │
└────────┴───────────────────┴─────────────────────────────┘

数据流：
方块操作 → dirtyAOPositions (脏集) → 100ms 防抖 → AOWorker 计算 →
_applyAOResults → 更新 InstancedMesh geometry attributes (aAoLow/aAoHigh)

---

二、发现的关键瓶颈

🔴 严重问题：被隐藏面仍进行 AO 计算

位置：AOWorker.js:86-104, AOUtils.js:113-136

问题描述：

• calculateAOForBlock 函数无条件计算所有 6 个面的 AO 值
• 没有检查面是否实际可见（即是否被相邻方块遮挡）
• 这导致大量不可见面的 AO 计算完全是浪费

代码证据：
// AOWorker.js:100-103 - 无条件计算所有面
for (let i = 0; i < positions.length; i++) {
// ...
const { aoLow, aoHigh } = calculateAOForBlock(ix, iy, iz, isOccluding);
// 计算了所有6个面，不管是否可见
}

// AOUtils.js:117-133 - 计算所有6个面
export function calculateAOForBlock(x, y, z, isOccludingFn) {
for (let faceIdx = 0; faceIdx < 6; faceIdx++) {
const aos = getAOForFace(x, y, z, faceIdx, isOccludingFn);
// 所有面都被计算...
}
}

影响：

• 一个完全封闭的方块（6面都被遮挡）本不需要 AO 计算，但仍计算 24 个顶点
• 大量内部方块被不必要地计算
• CPU 资源浪费严重

---

🟠 中等问题：AO 数据存储冗余

位置：WorldWorker.js:195-196, buildMeshData

问题描述：

• 每个可见方块都分配 aoLow 和 aoHigh Float32Array
• 透明方块（玻璃、水等）本不需要 AO，但仍可能分配存储
• 对于大量方块的 chunk，内存占用可观

代码证据：
// WorldWorker.js:195-196
const aoLow = new Float32Array(count); // 每个实例一个 float
const aoHigh = new Float32Array(count); // 每个实例一个 float

计算：

• 一个 chunk 最多 16×16×16 = 4096 个方块
• AO 数据 = 4096 × 2 × 4 bytes = 32KB/chunk
• 如果只有 50% 方块有可见面，仍存储全部 AO 数据

---

🟠 中等问题：动态方块 AO 计算在主线程

位置：Chunk.js:971-976, _createDynamicBlockMesh

问题描述：

• 动态放置方块时，AO 计算在主线程同步执行
• createOcclusionChecker 遍历 blockData 创建检测函数
• 可能影响帧率

代码证据：
// Chunk.js:971-976
if (applyAO) {
const isOccluding = createOcclusionChecker(
{ chunk: this, chunks: this.world.chunks }, CHUNK_SIZE, getBlockProps
);
({ aoLow, aoHigh } = computeBlockAOPacked(x, y, z, isOccluding)); //
同步计算
}

---

🟡 轻微问题：AO 脏集范围过大

位置：Chunk.js:686-707, _addDirtyAOPosition

问题描述：

• 脏集标记使用 3×3×3 邻居范围（26个邻居）
• 实际上 AO 只需要检查直接相邻的6个正交邻居
• 对角线邻居对 AO 计算贡献极小，却增加了计算量

当前实现：
// Chunk.js:44-60 - 26邻居范围
for (let dx = -1; dx <= 1; dx++) {
for (let dy = -1; dy <= 1; dy++) {
for (let dz = -1; dz <= 1; dz++) {
// 包含对角线邻居
}
}
}

---

🟡 轻微问题：跨 Chunk AO 数据合并开销

位置：AOWorker.js:29-57, createOcclusionChecker

问题描述：

• Worker 中创建合并查找表，涉及大量数据拷贝
• 每次 AO 计算请求都要重建 merged 对象

代码证据：
// AOWorker.js:31-46
const merged = {};
for (const key in blockData) {
merged[key] = blockData[key]; // 拷贝当前 chunk
}
for (const neighbor of neighborChunks) {
for (const key in neighbor.blockData) {
merged[key] = neighbor.blockData[key]; // 拷贝邻居
}
}

---

三、正确性评估

✅ 正确的设计

┌────────────┬────────────────────────────────────────────────────────────┐
│ 方面 │ 评价 │
├────────────┼────────────────────────────────────────────────────────────┤
│ 脏集机制 │ 使用 dirtyAOPositions Set │
│ │ 延迟计算，满足"不要求高实时性"需求 │
├────────────┼────────────────────────────────────────────────────────────┤
│ 异步计算 │ AOWorker 异步处理，不阻塞主线程 │
├────────────┼────────────────────────────────────────────────────────────┤
│ 增量更新 │ _applyAOResults 只更新变化的 AO 数据，不重建 InstancedMesh │
├────────────┼────────────────────────────────────────────────────────────┤
│ 跨 Chunk │ 正确收集 8 个方向邻居 chunk 数据，边界 AO 计算正确 │
│ AO │ │
└────────────┴────────────────────────────────────────────────────────────┘

⚠️ 需要注意的问题

┌─────────────────────────────────┬───────────────────────────────────────┐
│ 问题 │ 影响 │
├─────────────────────────────────┼───────────────────────────────────────┤
│ 邻居 chunk 未就绪时 AO 返回 │ 可能导致边界 AO 偏亮（但可以接受） │
│ false │ │
├─────────────────────────────────┼───────────────────────────────────────┤
│ 动态方块使用"中性 AO"填充 │ 可能导致临时方块 AO │
│ │ 不一致，但视觉影响小 │
└─────────────────────────────────┴───────────────────────────────────────┘

---

四、优化建议（按优先级）

🔴 P0：跳过被隐藏面的 AO 计算

实现方案：

修改 AOWorker.js，在计算 AO 前传入面可见性掩码：

// 修改 handleComputeAO，接收 faceVisibility 数据
function handleComputeAO(data) {
const { requestId, chunkKey, positions, blockData, neighborChunks,
faceVisibility } = data;

for (const pos of positions) {
  // 只计算可见面的 AO
  const visibleMask = faceVisibility[`${pos.x},${pos.y},${pos.z}`] ||

0b111111;
const { aoLow, aoHigh } = calculateAOForBlockWithMask(
pos.x, pos.y, pos.z, isOccluding, visibleMask
);
}
}

修改 AOUtils.js：

export function calculateAOForBlockWithMask(x, y, z, isOccludingFn,
visibleMask) {
for (let faceIdx = 0; faceIdx < 6; faceIdx++) {
// 只计算可见的面
if ((visibleMask & (1 << faceIdx)) === 0) continue;

  const aos = getAOForFace(x, y, z, faceIdx, isOccludingFn);
  // ...
}

}

预期收益：

• 内部方块（无可见面）：AO 计算从 6面→0面，减少 100%
• 边缘方块（1-2个可见面）：AO 计算减少 60-80%
• 显著提升 FPS，特别是在洞穴、建筑内部场景

---

🟠 P1：透明方块跳过 AO 存储

实现方案：

修改 WorldWorker.js 的 buildMeshData：

// 只对有可见面的实心不透明方块存储 AO
const props = getBlockProperties(type);
const needsAO = props.isSolid && !props.isTransparent && hasVisibleFaces;
if (needsAO) {
aoLow[i] = pos.aoLow || 0;
aoHigh[i] = pos.aoHigh || 0;
} else {
aoLow[i] = 0; // 默认值
aoHigh[i] = 0;
}

---

🟠 P1：减少脏集邻居范围

实现方案：

修改 Chunk.js 的 _addDirtyAOPosition：

// 只标记正交邻居（6个方向），排除对角线
const isOrthogonal = Math.abs(dx) + Math.abs(dy) + Math.abs(dz) === 1;
if (!isOrthogonal) continue;

收益：脏集大小减少约 70%（26→6）

---

🟡 P2：缓存遮挡检测函数

实现方案：

在 AOWorker.js 中缓存 createOcclusionChecker 结果，避免每次重建 merged 对象。

---

五、内存使用分析

┌─────────────────────────┬────────────┬─────────────────────────┐
│ 组件 │ 当前使用 │ 优化后预期 │
├─────────────────────────┼────────────┼─────────────────────────┤
│ AO 数据 (aoLow/aoHigh) │ 32KB/chunk │ 16KB/chunk (跳过隐藏面) │
├─────────────────────────┼────────────┼─────────────────────────┤
│ 脏集 (dirtyAOPositions) │ 可变 │ 减少 70% (缩小邻居范围) │
├─────────────────────────┼────────────┼─────────────────────────┤
│ Worker 合并表 │ 临时 │ 可缓存复用 │
└─────────────────────────┴────────────┴─────────────────────────┘

---

六、总结

AO 系统架构设计总体正确，采用脏集+Worker
异步计算满足"不要求高实时性"的需求。但存在关键性能瓶颈：

1. 被隐藏面仍进行 AO 计算 - 这是最严重的问题，导致大量无效计算
2. AO 数据存储冗余 - 透明方块和不透明方块的隐藏面都存储了 AO 数据

建议优先实施 P0 优化，这将显著提升
FPS，特别是在复杂场景（洞穴、建筑内部）。其他优化可后续逐步实施。

---

审查完成 - 已识别关键瓶颈并给出具体优化方案。

[jayli]

AO 只计算非隐藏面：

3208e3d