WebGL 低多边形模型

在网页上，3D 模型首先是一次下载，因此格式和文件大小比在任何桌面引擎中都更重要。GLB 是 WebGL 的正确选择，因为它是自包含的二进制文件，把几何体、材质和贴图打包进浏览器一次请求即可取回的单个文件。这种单文件行为很关键，因为每多一次请求都会增加延迟，而 GLB 避免了先加载几何体、再加载材质、再分别加载十几个贴图文件的来回交互。three.js 和 babylon.js 都通过各自的 GLTF 加载器原生加载 GLB，因此它是浏览器通用的模型格式。

Draco 压缩是加速 WebGL 加载的最大杠杆。Draco 压缩 GLB 内部的网格几何体，常常把顶点数据缩小一个数量级，于是原本几百千字节的模型可降到几十千字节。代价是模型加载时一点解压开销，由 worker 处理因此不阻塞主线程，在带宽是瓶颈的网络上这几乎总是值得的。再把 Draco 与 KTX2 Basis 贴图压缩配合，GPU 也以压缩格式存储贴图，同时削减下载大小和显存。对 WebGL 来说，压缩后的 GLB 是默认选择，而非事后才加的优化。

网页上的面数比桌面更紧，因为移动端 GPU 和共享的浏览器内存设定了上限。实用的网页预算是每个模型 1,000 到 10,000 三角面，主角物体靠近上限，道具靠近下限的几百面。扁平着色的低多边形风格完美契合这个区间，你仍应制作 LOD，让拥挤场景把远处物体切换为更省的网格。移动端 GPU 尤其惩罚过度绘制和高三角面数，因此保持每个模型精简、整体场景三角面数适中，才能让手机上的帧率流畅。

千字节在网页上是真实的预算，你应当如此对待。一个主角模型经 Draco 和 KTX2 之后应落在几百千字节以内，整场道具应控制在几兆字节以内，以便在典型网络下一两秒就能加载完。最大的节省来自一张共享贴图图集，道具用 512 到 1024 像素、主角最多 2048 像素，用平涂颜色或烘焙渐变绘制，这样压缩紧凑且以少量绘制调用渲染。在套件中复用一张图集意味着浏览器缓存一张贴图而非几十张，既缩小下载又加速渲染。

WebGL 的渲染性能归结于绘制调用和 GPU 工作量，而低多边形素材在两方面都有帮助。更少的三角面意味着更少的顶点处理，共享图集和材质意味着更少的状态切换，而通过 three.js 的 InstancedMesh 或 babylon.js 的 thin instances 进行实例化，让你一次调用绘制数百个相同道具。把这些技术结合起来，一个若以独立网格会卡顿的低多边形场景就能流畅运行。用平涂或轻量着色的材质保持着色器简单，在移动端避免重度后期处理，浏览器即便在普通硬件上也能保持六十帧。

实用的 WebGL 循环是：生成、导出 GLB、用 Draco 和 KTX2 压缩，再通过你的框架加载。对照你的千字节预算核对文件大小，确认加载器已注册 Draco 和 KTX2 解码器，并在真实的中端手机而非仅桌面浏览器上测试。由于你生成的素材是 AI 创建的，它们完全归你所有、可用于商业网页应用、且无需署名，因此你可以发布完全由生成式低多边形模型构建的配置器、游戏或产品查看器，没有授权负担，且负载快速轻量。