实时3D交互技术：WebGL/WebGPU实时渲染

CH-09-06-021·约 18 分钟·计算机图形学与可视化·更新 2026-08-11

想象你走进一家顶级餐厅的后厨：切配、过油、装盘、传菜，一条流水线严丝合缝地运转，每 16 毫秒就端出一道完整菜品，全年无休。这间后厨就是显卡里的 GPU，那套出菜流程就是实时渲染管线。而 WebGL 与 WebGPU，是两种风格迥异的“厨房管理制度”。WebGL 像老师傅掌勺的老式灶台——所有火候、油量都挂在墙上的一组“全局旋钮”上，改一个，全厨房跟着变；WebGPU 则像现代化的中央厨房——菜单、备料单、动线提前写成工单，一键开火，几十道菜同时出锅。本文会从备料、切配到出菜，带你完整认识这两套系统的每一道工序：顶点如何被搬运、三角形如何被切成像素、光与影如何被“烹饪”出来，以及怎样让后厨在高客流下依然保持 60 帧的翻台率。读完你就能明白，浏览器里的 3D 世界原来是一帧一帧“炒”出来的。

岗位关联

对 AI 从业者而言，实时渲染是把模型输出“画”成用户看得见、玩得转的实时世界的底层能力，掌握 WebGL/WebGPU，是通往 3D 可视化、数字孪生与智能交互产品落地的一条捷径。

可视化演示
1. 渲染管线基础
2. WebGL技术核心
3. WebGPU新特性
4. 实时渲染算法
5. 性能优化策略
6. 工程实践落地
AI 应用场景
Python 演示
常见误区
面试题

可视化演示

展示系统处理流水线、实时性能指标曲线及多方案对比分析，包含数据流转、吞吐延迟监控与方案评估。

本节配有交互动效（进入视口后自动加载，约 3KB）。

系统可视化处理流程：输入→处理→模型→输出性能监控：实时指标 P=L×T

1. 渲染管线基础

餐厅后厨的每一道菜都要经过固定流程：备料、切配、烹制、装盘、传菜。GPU 渲染图形也有一条不能跳步的流水线，叫作渲染管线。无论多复杂的 3D 场景，都必须沿这条流水线走完，才能变成屏幕上的像素。管线中的每一站都有专人负责，工序之间环环相扣，谁也不能越权。

这条管线由 GPU 中一个个“工位”串联而成：顶点着色器负责把每个顶点从模型本地坐标搬到屏幕坐标——相当于切配师按主厨要求把食材摆成特定造型；光栅化器把三角形“切成”一颗颗像素大小的碎片，相当于把整块食材切成入口小粒；片元着色器再给每粒上色调味，最后由帧缓冲装盘上桌。

具体来说，管线分四大阶段：顶点处理、图元组装、光栅化、片元处理，终点是帧缓冲。前两阶段对每个顶点执行一次，光栅化按三角形逐像素做固定计算，片元着色器则逐像素运行可编程逻辑。顶点搬运的数学核心是矩阵乘法：一个顶点要依次乘上模型矩阵、视图矩阵和投影矩阵，才能从三维世界落进屏幕。

就像流水线上每道工序都有明确职责，渲染管线把“谁在什么阶段做什么”规定得死死的——游戏里的角色、地图上的建筑、AI 生成的 3D 模型，都必须沿着这条流水线走一遭才能上桌。理解了这条流水线，后文的 WebGL 与 WebGPU 之争就好比“两套厨房如何组织同样的工序”。

\displaystyle \mathbf{v}_{clip} = M_{proj} \times M_{view} \times M_{model} \times \mathbf{v}_{local}

通俗地说，这个公式就是把“食材在备料台的位置”经过“搬到餐桌”和“从主厨视角看过去”两步，最后“投进餐盘”的完整坐标变换过程。

本地坐标 v_local物体在建模软件里的原始坐标，相当于食材刚从冰库取出的原始状态。
$\mathbf{v}_{local} = (x, y, z, 1)^T$
模型矩阵 M_model把本地坐标摆到世界场景中，决定物体的位置、旋转与缩放。
$M_{model} = T \times R \times S$
视图矩阵 M_view把世界坐标挪到“摄像机视角”，相当于换成主厨的眼睛看世界。
$\mathbf{v}_{view} = M_{view} \times \mathbf{v}_{world}$
投影矩阵 M_proj把三维场景压到屏幕裁剪空间，像把立体食材摆进扁平的餐盘。
$\mathbf{v}_{clip} = M_{proj} \times \mathbf{v}_{view}$

2. WebGL技术核心

老式餐厅的后厨墙上挂满旋钮：灶火大小、油温、调料位置……任何时候全厨房共享同一套“当前状态”。WebGL 就是这样一个“旋钮厨房”——它本质上是一个庞大的状态机，所有绘制行为都依赖当前已设置的一堆全局状态。

WebGL 是浏览器对 OpenGL ES 2.0 的封装，每个 API 调用都在读写全局状态：绑定哪个顶点缓冲、启用哪个着色器程序、是否开启深度测试。你画三角形前必须拧好所有旋钮，一旦漏拧，出菜就会“串味”——这也是新手最常见的翻车原因之一。这正对应思维导图中的“状态机机制”。

开发一个 WebGL 应用要做四件事：把顶点数据装进缓冲区对象（好比把切好的食材送进备料间）；编写并编译 GLSL 着色器（好比把菜谱写进后厨系统）；配置顶点属性指针（告诉 GPU 食材怎么摆）；最后调用一次绘制命令触发整条流水线。光栅化阶段还会对顶点携带的属性做线性插值，颜色、法线、纹理坐标都靠它平滑过渡。

老厨房的锅气没得说，但想同时出十道菜时，频繁拧旋钮就成了瓶颈——每次状态切换都让 GPU 停顿。这一处“旋钮之痛”，正是后文 WebGPU 要解决的痛点，也是性能优化章节埋下的伏笔。

\displaystyle f(\alpha) = (1 - \alpha) \times f_0 + \alpha \times f_1

这条公式描述的就是“颜料在两端的渐变混合”：三角形内部每一个像素的属性，都由两个顶点上的值按距离比例调和而成，就像一勺辣油从锅中一端到另一端逐渐变淡。

插值因子 α0 到 1 之间的小数，表示当前片元在两个顶点之间的比例位置。
$0 \le \alpha \le 1$
起点值 f0三角形第一个顶点携带的属性（颜色、法线等）。
$f_0 = f(0)$
终点值 f1第二个顶点携带的属性值。
$f_1 = f(1)$
线性混合按比例把两端属性混合，接近一端就偏向哪一端的值。
$f(\alpha) = f_0 + \alpha \times (f_1 - f_0)$

3. WebGPU新特性

现代中央厨房不再依赖老师傅的临场手感，而是把“菜品工艺卡”提前写好：面粉多少克、烘焙几分钟、模具用哪个，全部固化成一张张工单。WebGPU 就是这套“工单制厨房”——它把渲染所需的全部状态、资源、步骤预先编成对象，执行时一键推进。

WebGPU 是新一代 Web 图形 API，设计理念对标 Vulkan 与 DirectX 12，核心变化有三：管线（Pipeline）编译成不可变对象，绘制过程组织成渲染通道（Render Pass），资源通过绑定组（Bind Group）统一登记。画图时不再现场调旋钮，而是照工单一键执行，状态管理更安全、更高效。

另一大杀器是计算着色器（Compute Shader）——GPU 不再只能画图，还能执行通用并行计算，跑 AI 推理、粒子模拟、图像后处理。调度时按工作组划分线程，启动多少个工作组由一条公式决定：任务总量除以每个工作组的线程数，再向上取整。

工单制让厨房的并行能力大幅提升：不必等上一道菜完成再开下一道，几十个灶同时开工，这正是 WebGPU 高性能的秘密，也是未来浏览器端重型 3D 应用的首选地基。

\displaystyle gridSize = \left\lceil \frac{N}{workgroupSize} \right\rceil

这就像把 1000 盘菜分给每桌 8 人的流水线，需要 125 桌同时开工；如果除不尽，就多开一桌，宁可有一两个空位也不能漏掉任何一盘菜。

任务总数 N需要并行处理的数据量，比如 100 万像素或 10 万粒子。
$N = \text{数据总量}$
工作组大小每个工作组内的线程数，GPU 以工作组为基本调度单位。
$N_{group} = 64 \ \text{（常见取值）}$
向上取整除不尽时补满一个工作组，确保所有数据都被覆盖。
$gridSize = \left\lceil \frac{N}{N_{group}} \right\rceil$
总线程数实际启动的线程数略大于数据量，多余线程做空转保护。
$N_{threads} = gridSize \times N_{group} \ge N$

4. 实时渲染算法

后厨要想拿得出手，光会做“原味白灼”不行，还得有声有色：灯光是给菜品打光，阴影是让菜肴立体，纹理则是用印花模具快速压出花纹，避免每道菜都手工雕花。这四项正是实时渲染的“招牌技法”。

首先是帧缓冲（Framebuffer）——它就是那张最终出菜的餐盘，所有颜色、深度数据都要先汇聚到它身上再呈现到屏幕。接着是光照模型，最简单的漫反射模型叫 Lambert 模型：表面亮度由光源颜色、材质基色和光线与法线的夹角共同决定，夹角越大越暗，背光面直接归零。

阴影贴图（Shadow Mapping）先把场景从灯光视角渲染出一张深度图，再判断每个片元是否被遮挡；纹理映射（Texture Mapping）用一张图贴出千变万化的表面细节；抗锯齿（MSAA/SSAA）则把像素边缘的“锯齿毛边”打磨平滑。四者组合起来，才有了逼真的三维观感。

一道好菜靠综合技法而非单一秘方。真实场景往往要同时叠加光照、阴影、纹理和抗锯齿，每一层都在为“真实”加分。若只做其中一项，画面就会像“只有咸味没有鲜味”的菜一样平淡。

\displaystyle C_{diffuse} = C_{light} \times C_{base} \times \max(\mathbf{N} \cdot \mathbf{L}, 0)

这条公式是“灯光喷枪”的调色原理：射灯颜色乘上食材本色，再乘上一个代表“光照角度是否正对表面”的系数——正对最亮，斜照变暗，背对全黑。

光源色 C_light灯光携带的颜色与强度，厨师手里“灯光喷枪”的颜色。
$C_{light} = (R, G, B)$
表面基色 C_base物体材质本身的颜色，相当于食材本色。
$C_{base} = (R_m, G_m, B_m)$
法线 N 与光照方向 L表面朝外的指向与顶点指向光源的方向，两者点乘得到夹角余弦。
$\mathbf{N} \cdot \mathbf{L} = |\mathbf{N}| \times |\mathbf{L}| \times \cos\theta$
max 夹取夹角大于 90 度时光照为负，说明表面背光，夹取到 0。
$\max(\mathbf{N} \cdot \mathbf{L},\ 0)$

5. 性能优化策略

餐厅最怕高峰期的翻台率上不去。后厨绩效的关键，不在锅有多好，而在工序有多省：能不能一次多炒几份？能不能少洗几次锅？实时渲染的性能优化，本质也是这三件事——减少绘制调用、减少状态切换、复用好资源。

GPU 最怕两件事：频繁的绘制调用（Draw Call）和频繁的状态切换。每次绘制命令都是一次 CPU 到 GPU 的“传菜铃”，铃按多了、旋钮拧多了，GPU 光顾着响应命令，就没什么时间真正炒菜。所以优化第一板斧是合并调用：把同材质的物体拼成一个大几何体一次画完，或用实例化（Instancing）一次绘制成千上万个相同模型。

第二板斧是减少状态切换：按材质排序批量渲染，让 GPU 少“变脸”；第三板斧是资源生命周期管理：顶点数据、纹理提前上传显存并复用，避免每帧重复搬运。把这些都做对之后，还要盯住硬指标——帧时间预算。

翻台率才是餐厅盈利的核心。几万棵树、上万个粒子，通过实例化一次绘制搞定，这就是“以少胜多”的厨房哲学。记住：性能不是靠蛮力堆硬件，而是靠工序精简挤出来的。

\displaystyle T_{frame} = \frac{1000}{FPS} \approx 16.7\ \text{ms}

这是“翻台率”的数学表达：60 FPS 意味着每 16.7 毫秒必须端出一道菜，CPU 提交命令、GPU 跑完整条管线，加起来不能超过这个预算，超时就要掉帧卡顿。

帧率 FPS每秒刷新的画面张数，游戏的及格线通常是 60。
$FPS = 60$
毫秒换算1 秒等于 1000 毫秒，帧时间用毫秒计量。
$1\ \text{s} = 1000\ \text{ms}$
帧时间一帧允许的总耗时，由 CPU 提交与 GPU 渲染共同占用。
$T_{frame} = \frac{1000}{FPS} = \frac{1000}{60} \approx 16.7\ \text{ms}$
预算思想渲染必须在预算内完成，超时即掉帧，优化就是“省着花”。
$T_{frame} \le 16.7\ \text{ms} \Rightarrow 60\ \text{FPS}$

6. 工程实践落地

灶台再好，还得有人把店开起来。真实项目里很少从裸 WebGL 造轮子，而是用成熟的三方库和调试工具搭起整套后厨。Three.js 就是最流行的“连锁后厨方案”，它把渲染器、场景图、相机、灯光全部封装好，开发者用十几行代码就能开店。

Three.js 底层仍是 WebGL 渲染器，新版本也支持 WebGPU 后端，但它把复杂的状态管理、矩阵运算、几何体创建都藏了起来，让工程师专注于场景与交互。调试时用 Spector.js 抓取每一帧的绘制命令（相当于回放后厨的完整操作录像），配合 Chrome DevTools 的 Performance 面板，能快速定位瓶颈在 CPU 还是在 GPU。

跨平台适配是另一道必答题：不同浏览器对 WebGL2、WebGPU 的支持程度不一，要用特性检测并准备回退方案；移动端要压缩纹理、控制显存；大场景则靠 LOD 与 Mipmap 让远处细节自动降级。Mipmap 选取哪一层贴图，靠下面的公式决定。

稳定出菜才是好餐厅。掌握了 WebGL/WebGPU 的工程化套路，你就能在浏览器里搭出数字孪生、3D 展厅、在线游戏这些“招牌门店”，把图形学知识真正变成用户手里的交互体验。

\displaystyle \lambda = \log_2 \rho

这是“远小近大”的自动选料逻辑：贴图在屏幕上缩小得越厉害，就自动换用更小号的“印花模具”，既省显存又避免远处花纹闪烁。

像素-纹素比 ρ屏幕上一个像素覆盖的纹理像素（纹素）个数，衡量贴图被放大还是缩小。
$\rho = \frac{\text{纹素个数}}{\text{像素个数}}$
取对数把缩放倍数映射成连续层级序号，便于在预设的 Mipmap 层中定位。
$\lambda = \log_2 \rho$
向下取整选层λ 的整数部分决定使用哪一层预生成的降采样贴图。
$LOD = \lfloor \lambda \rfloor$
两层混合小数部分用于相邻两层间的双线性插值，过渡更平滑。
$\lambda = LOD + t,\quad 0 \le t < 1$

AI 应用场景

电商 3D 商品互动展示

阶段：模型输出到前端呈现阶段

解决的问题：传统电商只有多角度静态图片和视频，用户无法自由旋转查看细节，退货率居高不下。借助 AI 三维重建技术生成商品模型后，需要一套浏览器端实时渲染方案来承载展示。WebGL + Three.js 能将重建出的模型实时渲染成可 360 度旋转、缩放、更换材质的交互页面，让用户在“把玩”中决定是否购买。

具体案例：某鞋类品牌在商品详情页嵌入 3D 展示组件，用户可拖拽旋转查看鞋底纹理，页面帧率稳定在 60 FPS，详情页停留时长提升 40%，退货率明显下降。

数字孪生智慧园区

阶段：数据可视化与实时交互环节

解决的问题：智慧园区有海量传感器点位、楼宇模型和人员轨迹数据，传统 2D 图表难以表达空间关系，而桌面端渲染又无法满足随时访问。WebGPU 的计算着色器可并行处理点云数据与轨迹插值，再以实时渲染管线绘制建筑与设备状态，实现浏览器端高帧率数字孪生大屏。

具体案例：某园区管理平台将 3 万栋建筑模型与 20 万条实时设备数据叠加渲染，通过实例化批处理将绘制调用从 5 万次降到 300 次，在普通办公电脑上依然流畅运行。

AI 生成 3D 内容的实时预览器

阶段：生成式模型结果的可视化验证

解决的问题：文本生 3D、图像生 3D 等 AI 模型输出的是网格与材质数据，开发者迫切需要一款浏览器内实时预览编辑器来完成质检与修形。WebGL/WebGPU 渲染管线可实时展示 PBR 材质、动态光照与骨骼动画，让 AI 产出从“数据文件”变成“可见可改的作品”。

具体案例：某 AIGC 团队搭建了基于 Three.js 的模型预览工作台，AI 生成的每个模型自动加载为可旋转、可换装、可导出的 3D 场景，美术人员无需安装任何软件即可在线评审。

Python 演示

python51 行

import mathimport time # 立方体 8 个顶点(本地坐标)VERTS = [(-1, -1, -1), (1, -1, -1), (1, 1, -1), (-1, 1, -1),         (-1, -1, 1), (1, -1, 1), (1, 1, 1), (-1, 1, 1)]# 6 个面(顶点下标)FACES = [(0, 1, 2, 3), (5, 4, 7, 6), (4, 0, 3, 7),         (1, 5, 6, 2), (4, 5, 1, 0), (3, 2, 6, 7)]  def rotate_and_project(ay, ax, v):    cy, sy = math.cos(ay), math.sin(ay)    cx, sx = math.cos(ax), math.sin(ax)    # 模型矩阵: 绕 Y 轴和 X 轴旋转    x = v[0] * cy + v[2] * sy    z = -v[0] * sy + v[2] * cy    y = v[1] * cx - z * sx    z2 = v[1] * sx + z * cx    # 透视投影: 近大远小    s = 3.0 / (3.0 - z2)    return (int(x * s * 9) + 20, int(y * s * 6) + 12)  def draw_line(buf, x1, y1, x2, y2):    # 光栅化: 把线段切成一串像素点    steps = max(abs(x2 - x1), abs(y2 - y1), 1)    for i in range(steps + 1):        x = int(x1 + (x2 - x1) * i / steps)        y = int(y1 + (y2 - y1) * i / steps)        if 0 <= x < 40 and 0 <= y < 24:            buf[y][x] = '#'  def render(ay, ax):    # 顶点着色: 逐顶点执行变换    pts = [rotate_and_project(ay, ax, v) for v in VERTS]    buf = [[' '] * 40 for _ in range(24)]    # 图元组装: 按面绘制四条边    for f in FACES:        for k in range(4):            draw_line(buf, pts[f[k]][0], pts[f[k]][1],                      pts[f[(k + 1) % 4]][0], pts[f[(k + 1) % 4]][1])    return '\n'.join(''.join(row) for row in buf)  if __name__ == '__main__':    # 渲染循环: 不断变换角度输出新帧    for i in range(10):        print(render(i * 0.15, i * 0.10))        time.sleep(0.08)

目的：演示 WebGL 渲染管线的四个关键环节——顶点变换、投影、光栅化与渲染循环，帮助理解浏览器中 3D 渲染的本质。

pts = [rotate_and_project(ay, ax, v) for v in VERTS]对每个顶点执行模型旋转加透视投影，相当于顶点着色器逐个处理顶点。
s = 3.0 / (3.0 - z2)透视投影的除法，实现“近大远小”的镜头感。
draw_line(buf, ...)把几何边线切成一串离散像素，正是光栅化的核心操作。
buf[y][x] = '#'把像素写入字符画布，对应片元写入帧缓冲的过程。
if __name__ == '__main__':可执行入口，循环输出 10 帧动画，模拟 requestAnimationFrame 驱动的渲染循环。

常见误区

误区“WebGL 就是 JavaScript 在浏览器里一个像素一个像素地画 3D，所以效果越复杂，JS 就越卡。”

正解WebGL 的真正渲染在 GPU 的并行流水线上完成，JS 只扮演“传菜员”——配置状态、提交绘制命令。逐像素计算由 GPU 成千上万个线程同时完成，好比切配、炒锅、装盘各有专人，而不是一个厨师从头忙到尾。JS 卡通常卡在 CPU 侧的提交与状态切换，而不是“画像素”本身。

为何常见：JS 是浏览器里唯一能写逻辑的语言，新手自然把它当成“执行一切”的主体，忽视了 GPU 这块幕后的大厨房。

误区“WebGPU 就是 WebGL 加了光追的升级版，学完 WebGL 换个 API 名就能用了。”

正解WebGPU 是全新架构，不是补丁式的版本升级。它借鉴 Vulkan/DirectX 12，采用显式资源管理、不可变管线对象、渲染通道与计算着色器，连“资源绑定”“编码命令”等概念都完全不同。好比新厨房不只是换了口锅，而是整个动线和工单体系都重写了。

为何常见：两者名字都带“Web“、都能画 3D，很容易被理解成”同一个东西的版本号差异”，忽略了底层设计哲学的天壤之别。

误区“画面卡顿就把模型顶点砍到最少，多边形越少帧率一定越高。”

正解顶点数只是瓶颈之一，很多时候真正卡在绘制调用数量和状态切换上。现代 GPU 消化几百万顶点很轻松，但一万次绘制调用足以让 CPU 忙到冒烟。与其无脑减模，不如合并绘制调用、减少状态切换、压缩纹理带宽。

为何常见：“面数越低越快”是旧游戏时代留下的直觉，在现代 GPU 并行架构下，瓶颈往往在数据搬运与命令提交，而非顶点计算本身。

误区“只要着色器代码能编译通过，屏幕上就会出现我预期的效果，毕竟代码即真理。”

正解着色器能跑只是第一步，渲染结果还依赖深度测试、混合模式、颜色空间、纹理采样次数等一堆周围状态。GPU 千万线程并行执行时，一个 if 分支可能让整组线程空转，如同后厨一人点单、全厨房停火等菜。

为何常见：CPU 编程养成的“线性执行”直觉，搬到 GPU 的并行模型上就会失灵——写对逻辑不等于算得快，更不等于画得对。

面试题

Q1. WebGL 技术基座是基于下列哪个图形标准构建的？

单选题 · easy

A.OpenGL ES 标准← 正确答案
B.DirectX 12 标准
C.Vulkan 标准
D.Metal 标准

答案：A。WebGL 是浏览器对 OpenGL ES 2.0/3.0 的封装，好比老厨房沿用的是 OpenGL 家族传下来的老灶台规范。DirectX、Vulkan、Metal 是其他平台（Windows 原生、跨平台、苹果生态）的标准，浏览器环境里用不上。

Q2. 顶点着色器在渲染管线中主要负责哪项工作？

单选题 · mid

A.顶点坐标变换← 正确答案
B.像素颜色填充
C.三角形光栅化
D.深度缓冲测试

答案：A。顶点着色器负责把顶点经 MVP 矩阵搬到屏幕上，相当于切配师按工单摆盘。像素填色属于片元着色，光栅化是既定的切粒工序，深度测试是遮挡裁决环节——这三者都不归顶点着色器管。

Q3. 渲染管线中将连续三角形转换为屏幕离散像素片段的阶段是？

单选题 · mid

A.光栅化阶段← 正确答案
B.顶点处理阶段
C.片元着色阶段
D.纹理采样阶段

答案：A。光栅化把几何图形切成像素粒，是全管线最“硬核”的固定功能阶段，相当于把牛排切成入口小粒。顶点处理在它之前，片元着色在它之后，纹理采样只是着色阶段里的一个工具环节。

Q4. WebGPU 相比 WebGL 最核心的设计理念差异是什么？

单选题 · easy

A.显式资源管理← 正确答案
B.全自动内存回收
C.更简单的 API
D.无需着色器编程

答案：A。WebGPU 强调显式资源管理与可预测性能，像工单制厨房，所有资源、管线状态提前登记清楚。它并不自动回收内存、设计上也更复杂，更不可能去掉着色器——毕竟没人能不开火就炒菜。

Q5. 下列哪些属于常见的渲染性能优化手段？

多选题 · mid

A.合并绘制调用← 正确答案
B.减少状态切换← 正确答案
C.压缩纹理资源← 正确答案
D.增加动态光源

答案：ABC。合并绘制调用（少按传菜铃）、减少状态切换（少拧旋钮）、压缩纹理（减少带宽占用）都是经典优化。增加动态光源会大幅加重光照计算，属于加大负载而不是优化——就像给后厨多加几个灶台火头，翻台率只会更紧张。

Q6. 稳定 60 FPS 时，单帧允许的渲染时间约为多少？

单选题 · hard

A.约 16.7 毫秒← 正确答案
B.约 60 毫秒
C.约 1.7 秒
D.约 6 毫秒

答案：A。1 秒等于 1000 毫秒，60 帧平均每帧耗时 1000 ÷ 60 ≈ 16.7 毫秒，也就是后厨每 16.7 毫秒要出一盘菜。60 毫秒约等于 16 帧的水准，1.7 秒连 1 帧都不到，6 毫秒则只够支撑 166 帧的高配需求。

Q7. 深度缓冲（Z-Buffer）在实时渲染中起什么作用？

单选题 · hard

A.丢弃被遮挡的片元← 正确答案
B.增加顶点数据量
C.提升光照的强度
D.压缩纹理的内存

答案：A。深度缓冲记录每个像素的深度值，片元写入前先比较，被挡住的直接丢弃，像后厨排队的先来后到——后面的菜不能盖住前面的。它既不增加顶点，也不提升光照，更不压缩纹理，只回答“谁在前面”这一个问题。

Q8. 关于 WebGL 绘制调用的描述，下列哪些是正确的？

多选题 · extreme

A.每次调用都存在 CPU 与 GPU 的通信开销← 正确答案
B.合并几何体可以减少绘制调用次数← 正确答案
C.频繁切换状态会拉低渲染帧率← 正确答案
D.绘制调用数量与帧率完全无关

答案：ABC。每次绘制调用都要由 CPU 打包命令交给 GPU，确有通信开销；把同材质几何体合并成一个大缓冲区，能显著减少调用次数；频繁切换管线状态会打断 GPU 连续作业，拉低帧率。说“完全无关”显然不对——翻台率怎么可能和工序数量无关？

Q9. 下列哪个是常见的 WebGL 3D 渲染引擎库？

单选题 · easy

A.Three.js 引擎库← 正确答案
B.React.js 组件库
C.Vue.js 前端框架
D.Node.js 运行环境

答案：A。Three.js 是围绕 WebGL/WebGPU 的 3D 渲染引擎，相当于“连锁后厨方案”。React 和 Vue 是界面组件框架，Node.js 是服务端运行时，它们都不负责渲染 3D 场景——选引擎要认准“3D 渲染”这个功能标签。

Q10. 纹理映射（贴图）的主要价值包括哪些？

多选题 · mid

A.增加表面细节表现← 正确答案
B.降低几何建模复杂度← 正确答案
C.替代所有光照计算
D.减少片元着色器运行

答案：AB。纹理映射用图片给表面增加细节，不必为每处凹凸都建几何模型，显著降低建模成本——印花模具能压花纹，但替代不了光照：明暗仍需光照模型计算，片元着色器也不会因此减少运行次数。