Web 3D 遮挡剔除与硬件遮挡查询：消灭视锥体内被遮挡物体的过度绘制

/* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */
#content_views .toc,
/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */
#content_views.markdown_views > p:empty:has(+ .toc),
#content_views.markdown_views > .toc + p:empty,
/* 富文本旧版目录标记 */
#content_views.htmledit_views #main-toc,
#content_views.htmledit_views #hr-toc,
#content_views.htmledit_views p[id*=\”-toc\”] {
display: none !important;
}
/* 目录去掉后，紧跟的首个标题不再多出一块上边距 */
#content_views.markdown_views > .toc + h1,
#content_views.markdown_views > .toc + h2,
#content_views.markdown_views > .toc + h3,
#content_views.markdown_views > .toc + h4,
#content_views.markdown_views > .toc + p:empty + h1,
#content_views.markdown_views > .toc + p:empty + h2,
#content_views.markdown_views > .toc + p:empty + h3,
#content_views.markdown_views > .toc + p:empty + h4 {
margin-top: 0 !important;
}

在大型 Web 3D 场景（如数字室内展馆、智慧建筑楼宇、复杂地下管廊或密集城市街区）中，很多前端工程师在实施了“八叉树视锥体剔除”（Frustum Culling）之后，往往会遇到第二道严重的渲染瓶颈：

相机正对着一堵厚重的大理石展墙，视锥体范围内明明只露出了这一堵墙；但帧率依然低迷，显卡的片元着色器（Fragment Shader）负载居高不下。原因极其残酷：在视锥体的纵深方向上，这堵墙背后整整隐藏着另外 5 个展厅、数百件高精雕塑与上千盏射灯！

虽然这些雕塑完全被前方的墙体遮挡得严严实实，但因为它们确实落在相机的视锥体锥角之内，传统的视锥体剔除对它们完全无能为力。CPU 依然会忠实地为这些看不见的物体发射数百次 Draw Call，GPU 依然要在片元着色器里为它们解算复杂的 PBR 材质与法线光影，直到最终写入帧缓冲区时才被深度测试（Depth Test）丢弃。这种极其恶劣的算力浪费，在计算机图形学中被称为过度绘制（Overdraw）。

在美院传统写实油画技法中，画师在画室内静物时，绝不会先在画布上把苹果背后的衬布皱褶死抠几百笔，最后再用红颜料把苹果盖上去——那纯粹是浪费颜料与时间的蠢事。

在 Web 3D 渲染管线中，终结这种无效内耗的终极武器，便是遮挡剔除（Occlusion Culling）与硬件遮挡查询（Hardware Occlusion Queries）。

本文将深入现代图形硬件深度测试底层，带你拆解如何用极小的代理几何体探测可见性，将过度绘制彻底清零。

遮挡剔除的物理本质：为什么深度测试救不了 Draw Call？

很多初学者经常混淆“深度测试（Z-Buffer Test）”与“遮挡剔除（Occlusion Culling）”：

• 深度测试（发生极晚）：物体已经经历了 CPU 的 Draw Call 提交、顶点着色器的矩阵变换、光栅化三角化，甚至部分片元着色器的光照计算。直到最后一步准备把像素写进显存颜色缓冲时，才发现被前面的墙挡住了。此时 80% 的算力已经白白挥霍殆尽！
• 遮挡剔除（发生极早）：在 CPU 下发 Draw Call 之前，或者在着色器执行昂贵光照计算之前，就提前预判出该物体必然被前方的遮挡体（Occluder）挡住，从而直接连 Draw Call 都不发、连顶点都不算！

视点 (Camera) ──> [ 前方巨型实心墙体 (Occluder) ] ──> | 视线阻断 | ──> [ 背后 500 件高精雕塑 ]
(完全遮挡) (完全无需渲染!)

破局利器：WebGL 2.0 / WebGPU 硬件遮挡查询

图形硬件在芯片底层提供了专门的遮挡查询接口（Occlusion Query）：允许我们向显卡提交一个极简的“包围盒虚影代理体”（Bounding Box Proxy），硬件会自动统计这个代理体在光栅化后，究竟有没有哪怕一个像素真正通过了深度测试写入缓冲区！

如果硬件返回的测试通过像素数等于 0，就意味着该物体被前方的巨型遮挡物 100% 严密挡死，后续的高精渲染直接全量跳过！

规避致命陷阱：异步两帧延迟判定法（Two-Frame Lag Strategy）

硬件遮挡查询最大的阿喀琉斯之踵，是查询结果的异步延迟性：如果在同一帧内发出查询，并强行等待显卡返回结果，会造成 CPU-GPU 跨总线硬停顿（Pipeline Stall）。工业级标准做法是**“拿上一帧的查询结果，来指导当前帧的网格绘制”**：由于相机的移动在两帧之间（16 毫秒）极其平滑微弱，上一帧被遮挡的物体，这一帧有 99.8% 的概率依然被遮挡。这种“时间换流水线流畅”的架构设计，完全消除了任何总线同步阻塞。

生产级硬件遮挡剔除引擎实现

下面是基于 Three.js 与 WebGL 2.0 原生查询指令的高性能遮挡剔除控制器实现：

// occlusionCullingEngine.ts
import * as THREE from 'three';

export interface OcclusionTarget {
id: number;
mesh: THREE.Mesh;
boundingMesh: THREE.Mesh; // 极简代理盒 (仅 12 个三角形的粗糙立方体)
query: WebGLQuery | null;
isOccluded: boolean;
queryActive: boolean;
}

export class HardwareOcclusionEngine {
private gl: WebGL2RenderingContext;
private camera: THREE.Camera;
private targets: Map<number, OcclusionTarget> = new Map();
private depthMaterial: THREE.MeshBasicMaterial;

constructor(renderer: THREE.WebGLRenderer, camera: THREE.Camera) {
this.gl = renderer.getContext() as WebGL2RenderingContext;
this.camera = camera;

// 专用于绘制不可见代理盒的纯深度材质 (关闭颜色写入，仅测试深度)
this.depthMaterial = new THREE.MeshBasicMaterial({
colorWrite: false,
depthWrite: false
});
}

public registerEntity(id: number, mesh: THREE.Mesh): void {
// 为该物体自动生成外接 AABB 代理盒
mesh.geometry.computeBoundingBox();
const box = mesh.geometry.boundingBox!;
const size = new THREE.Vector3();
box.getSize(size);

const proxyGeo = new THREE.BoxGeometry(size.x, size.y, size.z);
const proxyMesh = new THREE.Mesh(proxyGeo, this.depthMaterial);
proxyMesh.position.copy(mesh.position);
proxyMesh.quaternion.copy(mesh.quaternion);

const query = this.gl.createQuery();

this.targets.set(id, {
id,
mesh,
boundingMesh: proxyMesh,
query,
isOccluded: false,
queryActive: false
});
}

/**
* 阶段一：在绘制具体物体前，拉取上一帧的异步查询判定
*/
public pollPreviousResults(): void {
for (const target of this.targets.values()) {
if (!target.queryActive || !target.query) continue;

// 核心：使用非阻塞式检查，绝不停顿 CPU！
const available = this.gl.getQueryParameter(target.query, this.gl.QUERY_RESULT_AVAILABLE);

if (available) {
// 获取通过深度测试的样本数 (Sample Count)
const samplesPassed = this.gl.getQueryParameter(target.query, this.gl.QUERY_RESULT);

// 若通过像素为 0，说明被前方大物严实遮挡！
target.isOccluded = (samplesPassed === 0);
target.queryActive = false;

// 动态控制真实高精物体的渲染可见性
target.mesh.visible = !target.isOccluded;
}
}
}

/**
* 阶段二：发射新一轮轻量代理体遮挡探测指令
*/
public issueOcclusionQueries(renderer: THREE.WebGLRenderer, scene: THREE.Scene): void {
const gl = this.gl;

for (const target of this.targets.values()) {
if (target.queryActive || !target.query) continue;

// 开启硬件遮挡计数
gl.beginQuery(gl.ANY_SAMPLES_PASSED, target.query);

// 仅渲染 12 个面的简陋代理立方体，光栅化开销几乎为零
renderer.renderBufferDirect(
this.camera,
null,
target.boundingMesh.geometry,
this.depthMaterial,
target.boundingMesh,
null
);

gl.endQuery(gl.ANY_SAMPLES_PASSED);
target.queryActive = true;
}
}

public destroy(): void {
for (const t of this.targets.values()) {
if (t.query) this.gl.deleteQuery(t.query);
}
this.targets.clear();
}
}

业务渲染流水线完整接入

在主渲染循环中，执行严格的三阶段流水线调度：

// 业务应用层渲染装配
const occlusionEngine = new HardwareOcclusionEngine(renderer, camera);

// 注册 500 个复杂的展厅高精陈列品…

function renderLoop() {
requestAnimationFrame(renderLoop);

// 步骤 1: 异步拉取上一帧的遮挡判定结果，秒级切换 target.mesh.visible
occlusionEngine.pollPreviousResults();

// 步骤 2: 渲染场景中绝对可见的大型实心遮挡物（如主承重墙体、地面）
// 必须先画遮挡体，将深度图填满，后续的遮挡测试才有基准！
renderPrimaryOccluders();

// 步骤 3: 仅对通过遮挡测试的高精 Mesh 执行正常的重度渲染
renderer.render(scene, camera);

// 步骤 4: 发射新一轮代理盒遮挡探测，为下一帧提供决策数据
occlusionEngine.issueOcclusionQueries(renderer, scene);
}

工业实测性能对比与收益

在一个包含 5 个连续展间、总计 600 件平均面数 25,000 面雕塑的复杂室内展厅 中进行了深度压力测试：

生产避坑黄金守则：

三维图形优化的终极哲学，不是去把无意义的计算加速十倍，而是用精确的几何直觉在最前端把无意义的计算彻底消灭。学会让看不见的物体在显存入口前悄然隐退，你才能真正将最极致纯粹的算力，献给用户眼眸聚焦处最璀璨的艺术高光。