光栅化。这个词我刚学WebGL那会儿盯着屏幕看了很久也没完全想明白——明明是三角形怎么最后就变成了屏幕上那一堆像素后来做地形可视化和WebGL渲染性能调优天天跟GPU内部行为打交道才把这件事彻底吃透。WebGL的渲染管线从顶点数据到最终像素中间最容易被忽略、也最能拉开水平差距的一环就是光栅化。这篇文章我打算从光栅化的本质讲起把图元装配、扫描转换、属性插值、深度处理这些环节各自干什么讲清楚然后结合我在WebGL里实际调试光栅化输出的操作经验和踩过的坑最后把光栅化在地形高程数据可视化、网格流体模拟这些真实场景里的用法串起来。适合刚入门WebGL、写过几个demo但觉得渲染管线还是模模糊糊的人也适合做图形应用开发、想真正理解GPU行为的人。我尽量少讲废话直接给你能用的东西。1. 光栅化图形管线里那道看不见的分界线1.1 从顶点到像素光栅化到底在做什么先理清一个最基础的问题光栅化是渲染管线里的哪一步一条完整的WebGL渲染流程是这样的你把顶点数据坐标、颜色、UV、法线交给顶点着色器顶点着色器把这些数据变换到裁剪空间输出若干个顶点接下来GPU把这些顶点组装成三角形这一步叫图元装配然后三角形进入光栅化阶段被拆成屏幕上的一个个像素像素再被组织成“片段”fragment交给片段着色器最后经过深度测试、混合等逐片元操作写到帧缓冲里。整条链路里“三角形被拆成像素”这一件事就是光栅化。它前面的管线输出的是几何顶点坐标它后面的管线输入的是像素片段它是连续几何世界和离散屏幕世界的分界线。很多人学WebGL时会有一个误区觉得顶点着色器算完坐标画面就应该出来了。实际上顶点着色器跑完之后GPU根本不知道屏幕上有哪些位置发光。举个生活里的类比顶点着色器像是建筑设计师画出了大楼的钢架结构图而光栅化是施工队把钢架填充成一面面墙体最后贴上瓷砖片段着色器做颜色处理。没有这一步结构图再精确你看到的也只是几条线不是一面完整的墙。光栅化这个阶段在WebGL里对开发者是不可编程的。你写不了shader去控制它也不能通过API直接调用某个函数去“手动栅格化”。它完全由GPU内部固定的硬件单元完成。这种“不可控”恰恰是很多初学者觉得它神秘的原因——但其实它的行为是有明确规则的理解了这些规则你就能解释很多渲染现象也能预判GPU的性能瓶颈。1.2 为什么光栅化决定WebGL画面的上限光栅化虽然不归你管但它决定了你画面的两个基本盘画得对不对和跑得快不快。画得对不对体现在几何覆盖上。三角形哪些像素被覆盖、缝隙处是露底还是变黑、共享边的像素是否被画了两次导致闪线这些都由光栅化规则决定。你没法通过“改几行shader”去修只能理解规则后绕开它。跑得快不快也同样悬在光栅化头上。图形学里有个词叫填充率fill rate指GPU每秒钟能把多少像素写进栅格。一个屏幕有1920x1080个像素大约是207万个如果你的场景里有大量三角形重叠在一个区域每个像素可能被写入十几遍填充率消耗就是两千万级别。这种消耗不是顶点着色器能决定的完全取决于光栅化阶段产生了多少片段。我见过不少人做WebGL项目场景里一二十万三角形顶点数量完全在GPU能力范围内但帧率就是上不去。查来查去发现是三角形太小、太碎光栅化时大量覆盖在同一个像素上把填充率打满了。这就是典型的“死在光栅化手里”。2. 光栅化前半程图元装配与覆盖判定2.1 图元装配GPU如何把顶点连成三角形光栅化真正开工之前GPU需要先把顶点“组装”成几何形状也就是图元装配。这一步虽然发生在光栅化正式计算之前但它的输出格式直接决定了光栅化怎么扫描。你在WebGL里调用gl.drawArrays(gl.TRIANGLES, 0, 3)时GPU拿到的是三个顶点。如果调用gl.drawElementsGPU会先通过索引缓冲找到对应的顶点再组装。图元装配做的事就是根据drawArrays/drawElements的mode参数TRIANGLES、TRIANGLE_STRIP、TRIANGLE_FAN、POINTS、LINES等把顶点流切成一个个图元。这个阶段的性能问题主要出在顶点缓存上。GPU内部有一个顶点缓存vertex cache专门缓存最近处理过的顶点。当你用TRIANGLE_STRIP或索引绘制时相邻三角形会共享顶点缓存命中率高图元装配就快。反过来如果每次draw都重新上传大量顶点顶点在缓存里留不住图元装配就要反复读数据性能受影响。我记得在优化一个地图瓦片渲染项目时把16个三角形拼接的区域从单独的16次drawArrays改成一次索引绘制后顶点装配耗时下降了接近一半——因为共享顶点被缓存命中了。这件事虽然和光栅化本身没关系但图元装配的快慢会影响整条管线的利用效率热点渲染时CPU和GPU都不会闲着等对方。图元装配完成后每个三角形就带着三个顶点的屏幕坐标其实此时还在窗口坐标空间但已经做了视口变换准备进入真正的光栅化计算。2.2 覆盖测试像素中心点说了算光栅化的第一个核心计算是判断一个三角形覆盖了哪些像素。这个判断在图形学里叫“覆盖率测试”coverage test或“扫描转换”scan conversion。传统软件渲染里一条经典算法是对屏幕上的每条水平扫描线算出扫描线与三角形三条边的交点然后把交点之间的像素填充上颜色。GPU硬件光栅化器虽然做了一堆并行化优化但底层逻辑和这个算法是同一个祖宗——它也是在逐扫描线、逐像素地判断三角形的覆盖范围。关键点来了判断“覆盖”时不看像素的整个正方形区域只看像素中心点是否落在三角形内部。像素中心在三角形内这个像素就算被覆盖生成一个片段中心点不在三角形内无论三角形边缘擦过这个像素多少面积这个像素也不会被点亮。这个规则叫“像素中心规则”pixel center convention。这个规则直接导致了一个经典现象——锯齿。三角形边缘是斜线时一条斜线扫过一行像素有的像素中心在线上方有的在下方于是边缘变成了一格一格的“楼梯”。理解了这一点你就会明白MSAA多重采样抗锯齿为什么有效它不是改变像素中心的判定规则而是在每个像素内部多放几个采样点看有多少采样点落在三角形内然后按比例混合颜色。光栅化仍然在看“点”只是看的点变多了。还有一个很细的规则共享边不重复覆盖。相邻两个三角形共有一条边时正常情况应该一个像素只被一个三角形光栅化否则这条边上的像素会被片段着色器执行两次像素最后写哪个值可能出现闪线和深度冲突。GPU内部用了一套“上边-左边规则”top-left rule来处理即只有三角形的上边缘或左边缘才产生覆盖。你不用写代码去控制它但如果你在工程里做地形网格、水面网格这种大量共享边的几何体遇到“网格接缝处出现暗线”时要意识到很可能是光栅化覆盖规则配合浮点精度抖动导致的而不是单纯的shader写错了。3. 光栅化后半程插值、透视校正与逐片元操作3.1 重心坐标与属性插值颜色和UV是怎么“均匀”流动的覆盖测试只能告诉你“哪些像素被点亮”还不能回答“这个像素该是什么颜色”。三角形的三个顶点可能各自有不同的颜色、UV、法线那中间某个像素的值是怎么来的答案是插值。光栅化器会为每个像素计算一组重心坐标barycentric coordinates。给定三角形三个顶点A、B、C以及三角形内一点P存在三个权重系数α、β、γ使得P α·A β·B γ·Cα β γ 1当P恰好是顶点A时α1、β0、γ0当P在三角形中心时三个系数各为1/3。只要这三个系数算出来像素P处的任意顶点属性X都可以通过 X α·X_A β·X_B γ·X_C 插值得到。这就是你看一个三角形的UV贴图不会一块一块撕裂的原因。重心坐标的计算本质上就是解一个线性方程组等价于用面积比去算。一个像素离哪个顶点越近对应的权重就越大属性值就越接近那个顶点。很多WebGL学习者看到shader里varying关键字知道顶点着色器的输出经过插值能平滑地传到片段着色器但对“插值发生在哪里”没有概念。其实插值发生在光栅化阶段不在顶点着色器也不在片段着色器。顶点着色器输出的varying变量会被光栅化器“记住”然后逐像素用重心坐标算出一个插值版本最后交给片段着色器执行。这个细节解释了为什么flat限定符在GLSL里存在——它告诉光栅化器“这个属性不要插值直接用第一个顶点或末个顶点的值”适合法线、实例ID这类不能线性插值的数据。3.2 透视校正让纹理和深度在3D里“不飘”插值听上去很简单但三角形一旦进入3D视角事情就变了。回想一下透视除法顶点坐标从裁剪空间变成NDC再变成屏幕窗口坐标这个过程中坐标被除以了w分量。问题在于经过透视除法后屏幕空间坐标和世界空间坐标之间不再是线性关系。如果你直接在线性光栅化的框架里对UV坐标做线性插值远处的纹理就会扭曲、抖动像贴了张会飘的纸。这是图形学里的经典问题透视校正插值perspective-correct interpolation。解决办法是在光栅化时大家约定“在屏幕空间里插值的是属性/w和1/w两个量。像素处先用重心坐标线性插值1/w再插值 属性/w最后相除除以1/w得到真正的属性值。这套操作本质上是在屏幕空间做线性插值却能得到透视空间里正确的结果。现代OpenGL和WebGL的GLSL里默认的varying插值已经是透视校正的你不用写任何额外代码。但如果你有两个疑问——第一为什么全屏后处理时感觉插值结果不太对第二为什么自定义的深度值插出来会抖动——多半就是没把透视校正这件事搞清楚。比如你想在片段着色器里手动重建世界坐标直接对NDC坐标做线性插值再用就很容易出错正确做法是接收一个约定好的世界坐标varying让光栅化器完成透视校正而不是自己在shader里算。有个noperspective关键字可以强制GLSL做线性插值而不做透视校正。在需要屏幕空间均匀分布的效果比如某些边缘光、扫描线效果里它反而有用。不过新手阶段默认用perspective就好别乱改。3.3 深度测试、MSAA与Early-Z光栅化之后还有多少事要办光栅化为每个被覆盖的像素生成一个片段这个片段还没上屏后面还排着一堆测试。其中最重要的就是深度测试每个片段都会带一个深度值通常是从插值后的z坐标算出来的GPU拿它和深度缓冲里对应位置已存的深度值比较决定是否通过。所以光栅化产出的每一个片段都会消耗一次深度测试的运算。如果你的场景里三角形重叠严重同一个像素上光栅化出十个片段深度测试就要运行十次其中九次大概率被丢弃。这部分开销你看不到但帧率会告诉你。GPU为此做了一个优化叫Early-Z早期深度测试。在不透明场景下深度值不需要在片段着色器里被修改GPU可以在光栅化刚结束、shader还没跑的时候先做一遍深度测试没通过的片段直接扔掉根本不用执行片段着色器。这能省下大量计算。但只要你使用了带透明度的绘制或者shader里写了修改gl_FragDepth的逻辑Early-Z就会失效GPU只能老老实实跑完整个片段着色器再测深度。MSAA多重采样抗锯齿的机制也和光栅化相关。开启MSAA后光栅化器会在每个像素内生成多个采样点比如4x就是4个采样点逐个做覆盖测试。一个像素只要有一个采样点落在三角形内就会生成一个片段但片段着色器仍只执行一次。最终resolve阶段再按采样点的覆盖率把颜色摊匀。这也是MSAA能在抗锯齿的同时不大幅牺牲性能的原因——它增加的是光栅化覆盖测试的开销而不是片段着色器的开销。反过来如果你在片段着色器里做了特别重的计算比如循环一堆光照开MSAA通常比超采样抗锯齿(SSAA)划算得多因为着色次数没涨。4. WebGL里的光栅化现场实操与调试4.1 用FBO把光栅化结果拿到手说了这么多原理来点实操。想亲眼验证光栅化规则最直接的办法是绕开浏览器把光栅化产物读回到内存里看。这就要用到帧缓冲对象FBO和readPixels了。一个最小操作流程是这样的创建一个WebGL2上下文。创建一个纹理或渲染缓冲对象作为FBO的颜色附件。绑定FBOgl.clear清屏。绘制一个三角形哪怕只是最简单的三顶点单色三角形。调用gl.readPixels把FBO里的像素读回数组。把数组输出到控制台或转成图片查看。你会发现在readPixels读回来的数据里三角形边界刚好落在“像素中心点进入三角形”的那一圈像素上。边缘上的像素颜色是纯色如果没开抗锯齿或者是混合后的颜色如果开了MSAA。这能直接验证“覆盖测试看像素中心点”的规则。实操中有几个坑得提醒注意readPixels读回的像素原点在左下角而浏览器里图片、canvas的坐标原点在左上角。你读回的数组顺序和下屏图片是上下倒着的处理时要自己翻转不然排查半天以为光栅化错了其实是坐标方向弄反了。另一个坑是读取FLOAT类型的颜色缓冲时WebGL1需要检查OES_texture_float扩展WebGL2则要确认格式组合匹配比如gl.R32F带gl.RED、gl.FLOAT。直接按UNSIGNED_BYTE去读一个浮点纹理读回来的数全是错的。我在做流体模拟调试时踩过这个坑光栅化后把速度场读回来检查数值结果全是一串看起来正常的垃圾数据折腾了一晚上才意识到是读取格式不匹配。用readPixels虽然能拿到精确的像素值但性能很慢因为它需要GPU把数据拷贝回CPU内存还会打断GPU的流水线。所以调试时用它看数据没问题千万别在每帧渲染里调它——帧率会直接崩给你看。4.2 常见问题排查半像素偏移、锯齿和过绘制实际操作中光栅化相关的问题有很高的出现频率我整理了几类最典型的附上排查思路现象根源排查与解决全屏后处理画面边缘模糊或偏了半像素视口变换时像素中心对齐不一致NDC坐标到窗口坐标的映射有半像素偏移检查gl.viewport设置做全屏quad时把顶点坐标和gl_FragCoord.xy对照必要时偏移半个像素微调纹理贴图远处扭曲、抖动使用了非透视校正插值检查GLSL里是否误用了noperspective或者手动插值了NDC/窗口坐标属性网格接缝、边缘暗线共享边的覆盖规则和浮点精度抖动或法线插值后光照方向不一致把三角形顶点稍微焊住、统一网格精度检查贴图是否有边缘色差先排除光栅化问题场景FPS低但顶点数量不多三角形过碎大量像素被重复覆盖填充率打满做depth prepass、减少深度测试失败开销对细小几何做LOD合并或剔除透明物体排序乱边缘有锯齿透明物体不能Early-Z片段shader执行了但被丢弃透明物体按距离排序、减少透明面重叠MSAA与alpha blend结合不佳时可考虑alpha-to-coverage画点粒子时点的大小上限不够用gl_PointSize有实现相关的最大值限制点光栅化后不是想象那么大查询gl.ALIASED_POINT_SIZE_RANGE需要更大的粒子可以用billboard三角形替代GL_POINTS这里面最容易被忽略的是半像素偏移。OpenGL/WebGL体系的窗口坐标里像素中心落在整数坐标上比如像素(0,0)的中心在(0.5,0.5)这一点要分情况看你用的坐标系定义这个细节在普通三角形绘制里感知不强但在做全屏后处理、粒子拖尾、UI叠加效果时偏差半个像素就会导致明显的边缘模糊或错位。遇到这种问题先把视口变换公式自己写一遍确定映射关系再去调顶点坐标。过绘制问题则是性能排查的重灾区。早期我做地形渲染地形瓦片网格非常密大部分三角形在地平线附近被压得极小光栅化器要在这些巴掌大的三角形上来回覆盖像素帧率惨不忍睹。后来做的优化有两个一是根据屏幕空间误差调度LOD远处的瓦片用更稀疏的网格二是做一次深度预通道depth prepass先只写深度不跑光照shader把被遮挡的像素提前扔掉第二遍再跑完整着色。这个改法把同一场景的帧率从40帧拉到60帧代价只是一次额外的几何绘制。4.3 全屏三角形光栅化作为“逐像素计算引擎”聊到后处理和流体模拟有一个光栅化的特殊用法特别值得单独拎出来讲全屏三角形。所谓全屏三角形就是绘制一个覆盖整个视口的大三角形或两个组成屏幕的三角形。这个三角形经过常规的光栅化流程之后会把每一个像素都点亮生成一个片段。然后你在对应的片段着色器里做大规模逐像素计算——采样纹理、做卷积、解方程、写回结果。整个过程本质上是在“用光栅化器驱动一个逐像素的并行计算机”。现代WebGL里很多“计算型”效果都是靠全屏三角形实现的最典型的就是流体模拟。比如最近网上热度很高的Vortex Fluid Simulation、Cyclone这类基于WebGL的涡流流体模拟项目核心思想是把流体速度场、密度场存成一张张纹理每一帧渲染两三个全屏三角形在片段着色器里完成“平流-扩散-外力-投影”这些流体步骤。光栅化在这里的角色是给每个像素提供一个统一的着色入口。你不需要关心三角形长什么样子只要它能把屏幕铺满就能让GPU在一个像素一个像素地执行你的算法。全屏三角形有个实现细节要注意不要用两个小三角形拼成的全屏quad直接给一个覆盖屏幕的大三角形。这样可以节省对角线上的重复扫描还能减少一些对角边缘的插值偏差。顶点坐标给(-1,-1)、(3,-1)、(-1,3)这样超出视口的范围让光栅化器裁剪掉多余部分只留下屏幕区域。这种方法在地形可视化和流体效果里我用过很多次稳定且性能更好。5. 光栅化在真实项目里的延伸地形、引擎与流体5.1 高程数据与地形可视化每块网格都在过光栅化光栅化离你最近的重度应用应该是三维地球和地形可视化。Cesium这类地理场景里高程数据DEM通常组织成规整的网格每块瓦片就是一张高度图。开发时上传高度图纹理或几何数据顶点着色器根据高程值修改顶点的y坐标然后交给光栅化器把网格三角形转成屏幕上的像素最终呈现起伏的山体。理解光栅化规则对做地形有一个实在的好处你能判断一个网格三角形在屏幕上到底占了几个像素。如果三角形太小一个像素被好几个三角形轮番覆盖填充率白烧如果三角形太大地形细节又不够。Cesium里有个核心指标叫屏幕空间误差Screen Space Error, SSE本质就是在控制三角形光栅化后的屏幕尺度。LOD切分的逻辑说白了就是在“三角形太大、细节不够”和“三角形太小、光栅化浪费”之间找平衡。我做地形项目时的经验是尽量保持网格三角形在屏幕上的投影边长不小于2~3个像素小于这个阈值就切到低精度的LOD瓦片。这样光栅化器的覆盖测试不会过度浪费地形又不会丢失轮廓。5.2 大规模地理渲染引擎如何“绕着光栅化优化”在GIS可视化领域常会用到一些面向海量地理数据的WebGL渲染引擎比如Loca这类专注于地理空间可视化的渲染引擎。做大数据量热力图、轨迹线、建筑群的时候三角形数量动不动就是几十万上百万这时候你会发现大家的优化思路高度一致——都是在想办法减轻光栅化阶段的负担。常见的手段包括把点和线用GL_POINTS和TRIANGLE_STRIP绘制减少重复顶点把多个几何体合并到同一个drawArrays调用里减少绘制命令的切换在地图缩放时动态调整几何密度避免一堆三角形挤在几个像素里。这些优化表面上是在处理CPU和顶点数据实际上最后都在服务同一个目标——让光栅化器产生的片段数量更合理。有一类地理可视化效果特别典型在大量点数据上做发光光晕。如果你对每个点都渲染一个有渐变边缘的大三角形光栅化生成的片段数量会非常可观。引擎的做法往往是分层绘制、预计算光晕纹理、缩小点的绘制范围让光栅化只在真正需要的像素上工作。我记得有一次对照Loca的源码排查一个发光点图层掉帧的问题最后发现是我把光晕半径设得太大同一块区域里重叠了十几个点光晕填充率直接超了。把光晕半径缩小并合并批次后帧率恢复了。5.3 流体模拟里的网格法与粒子法光栅化如何“客串计算单元”流体模拟是WebGL里最炫的光栅化延伸应用之一也是理解“光栅化不只是画三角形”的绝佳案例。目前WebGL上常见的流体模拟有两种思路。一种是欧拉网格法把空间划分成网格每个格子存储速度、密度等物理量。模拟时每一帧渲染全屏三角形在片段着色器里迭代求解Navier-Stokes方程的各个项。这里的难点是迭代过程必须把结果写入纹理下一帧再读回来所以要用双缓冲ping-pong纹理。光栅化器负责逐像素驱动这套计算它产出的不是最终画面而是“下一帧的物理场”。另一种是粒子法比如SPH把流体离散成大量粒子每个粒子用一个小点或小球表示。渲染时可以把粒子看作是GL_POINTS的点图元光栅化器对每个点做覆盖测试生成圆形粒子。这类粒子数量大时光栅化器同样要处理海量小图元的覆盖所以粒子半径、粒子数量、屏幕分辨率三者的平衡直接决定帧率。仔细观察那些热门的WebGL流体模拟项目你会发现它们大多同时用了这两种思路先用网格法算速度场和密度场再把密度场的最终结果显示出来。显示的那一步本质上仍然是一个全屏三角形的光栅化纹理采样过程。理解光栅化在这里的角色后遇到“流体模拟帧率上不去”“网格纹理出现小白点”这类问题你排查起来就有方向了——白点通常就是偏移太小或精度问题导致光栅化覆盖测试的边界抖动要把物理量存储格式从UNSIGNED_BYTE换成浮点纹理或者调整模拟步长。5.4 关于光栅化性能的一些实操心得最后分享几条我在项目里反复用到的性能优化经验都是围绕光栅化的特性总结出来的控制过绘制。场景里不透明物体多时先做一遍深度预通道再跑正式渲染能让片段着色器少执行一大半“肉眼看不见”的像素。这个策略在地形、城市建模、粒子系统里都有效。少画小三角形。三角形越小光栅化器在覆盖测试上的相对开销越大。能用顶点多、面积大的面片模拟出细节就不要硬切碎网格。LOD的本质就是让屏幕上的三角形大小保持合理区间。能合批就合批。减少drawArrays调用次数让图元装配阶段不空转光栅化器才能持续满载干活。注意纹理和帧缓冲格式。在FBO里做后处理或流体迭代时能用HALF_FLOAT就不上FLOAT能读UNSIGNED_BYTE就不读浮点不然readPixels效率低纹理带宽也紧张。MSAA不是万能的。开启MSAA后光栅化覆盖测试的采样点数量增加三角形太小的情况下MSAA的收益也有限。粒子、细线大量出现时通常还不如靠透明度排序和形态学抗锯齿FXAA来处理。说到底光栅化是图形渲染里最“实在”的一段计算。它没有花哨的算法炫技但它的规则决定了每一帧画面的边界和性能底盘。把重心坐标、覆盖测试、透视校正这些概念真正吃透之后你再看WebGL的报错、画面瑕疵和性能瓶颈很多问题一眼就能定位到管线的正确环节。这比背几十个API参数有用得多。
WebGL光栅化全解析：从三角形到像素的渲染核心
光栅化。这个词我刚学WebGL那会儿盯着屏幕看了很久也没完全想明白——明明是三角形怎么最后就变成了屏幕上那一堆像素后来做地形可视化和WebGL渲染性能调优天天跟GPU内部行为打交道才把这件事彻底吃透。WebGL的渲染管线从顶点数据到最终像素中间最容易被忽略、也最能拉开水平差距的一环就是光栅化。这篇文章我打算从光栅化的本质讲起把图元装配、扫描转换、属性插值、深度处理这些环节各自干什么讲清楚然后结合我在WebGL里实际调试光栅化输出的操作经验和踩过的坑最后把光栅化在地形高程数据可视化、网格流体模拟这些真实场景里的用法串起来。适合刚入门WebGL、写过几个demo但觉得渲染管线还是模模糊糊的人也适合做图形应用开发、想真正理解GPU行为的人。我尽量少讲废话直接给你能用的东西。1. 光栅化图形管线里那道看不见的分界线1.1 从顶点到像素光栅化到底在做什么先理清一个最基础的问题光栅化是渲染管线里的哪一步一条完整的WebGL渲染流程是这样的你把顶点数据坐标、颜色、UV、法线交给顶点着色器顶点着色器把这些数据变换到裁剪空间输出若干个顶点接下来GPU把这些顶点组装成三角形这一步叫图元装配然后三角形进入光栅化阶段被拆成屏幕上的一个个像素像素再被组织成“片段”fragment交给片段着色器最后经过深度测试、混合等逐片元操作写到帧缓冲里。整条链路里“三角形被拆成像素”这一件事就是光栅化。它前面的管线输出的是几何顶点坐标它后面的管线输入的是像素片段它是连续几何世界和离散屏幕世界的分界线。很多人学WebGL时会有一个误区觉得顶点着色器算完坐标画面就应该出来了。实际上顶点着色器跑完之后GPU根本不知道屏幕上有哪些位置发光。举个生活里的类比顶点着色器像是建筑设计师画出了大楼的钢架结构图而光栅化是施工队把钢架填充成一面面墙体最后贴上瓷砖片段着色器做颜色处理。没有这一步结构图再精确你看到的也只是几条线不是一面完整的墙。光栅化这个阶段在WebGL里对开发者是不可编程的。你写不了shader去控制它也不能通过API直接调用某个函数去“手动栅格化”。它完全由GPU内部固定的硬件单元完成。这种“不可控”恰恰是很多初学者觉得它神秘的原因——但其实它的行为是有明确规则的理解了这些规则你就能解释很多渲染现象也能预判GPU的性能瓶颈。1.2 为什么光栅化决定WebGL画面的上限光栅化虽然不归你管但它决定了你画面的两个基本盘画得对不对和跑得快不快。画得对不对体现在几何覆盖上。三角形哪些像素被覆盖、缝隙处是露底还是变黑、共享边的像素是否被画了两次导致闪线这些都由光栅化规则决定。你没法通过“改几行shader”去修只能理解规则后绕开它。跑得快不快也同样悬在光栅化头上。图形学里有个词叫填充率fill rate指GPU每秒钟能把多少像素写进栅格。一个屏幕有1920x1080个像素大约是207万个如果你的场景里有大量三角形重叠在一个区域每个像素可能被写入十几遍填充率消耗就是两千万级别。这种消耗不是顶点着色器能决定的完全取决于光栅化阶段产生了多少片段。我见过不少人做WebGL项目场景里一二十万三角形顶点数量完全在GPU能力范围内但帧率就是上不去。查来查去发现是三角形太小、太碎光栅化时大量覆盖在同一个像素上把填充率打满了。这就是典型的“死在光栅化手里”。2. 光栅化前半程图元装配与覆盖判定2.1 图元装配GPU如何把顶点连成三角形光栅化真正开工之前GPU需要先把顶点“组装”成几何形状也就是图元装配。这一步虽然发生在光栅化正式计算之前但它的输出格式直接决定了光栅化怎么扫描。你在WebGL里调用gl.drawArrays(gl.TRIANGLES, 0, 3)时GPU拿到的是三个顶点。如果调用gl.drawElementsGPU会先通过索引缓冲找到对应的顶点再组装。图元装配做的事就是根据drawArrays/drawElements的mode参数TRIANGLES、TRIANGLE_STRIP、TRIANGLE_FAN、POINTS、LINES等把顶点流切成一个个图元。这个阶段的性能问题主要出在顶点缓存上。GPU内部有一个顶点缓存vertex cache专门缓存最近处理过的顶点。当你用TRIANGLE_STRIP或索引绘制时相邻三角形会共享顶点缓存命中率高图元装配就快。反过来如果每次draw都重新上传大量顶点顶点在缓存里留不住图元装配就要反复读数据性能受影响。我记得在优化一个地图瓦片渲染项目时把16个三角形拼接的区域从单独的16次drawArrays改成一次索引绘制后顶点装配耗时下降了接近一半——因为共享顶点被缓存命中了。这件事虽然和光栅化本身没关系但图元装配的快慢会影响整条管线的利用效率热点渲染时CPU和GPU都不会闲着等对方。图元装配完成后每个三角形就带着三个顶点的屏幕坐标其实此时还在窗口坐标空间但已经做了视口变换准备进入真正的光栅化计算。2.2 覆盖测试像素中心点说了算光栅化的第一个核心计算是判断一个三角形覆盖了哪些像素。这个判断在图形学里叫“覆盖率测试”coverage test或“扫描转换”scan conversion。传统软件渲染里一条经典算法是对屏幕上的每条水平扫描线算出扫描线与三角形三条边的交点然后把交点之间的像素填充上颜色。GPU硬件光栅化器虽然做了一堆并行化优化但底层逻辑和这个算法是同一个祖宗——它也是在逐扫描线、逐像素地判断三角形的覆盖范围。关键点来了判断“覆盖”时不看像素的整个正方形区域只看像素中心点是否落在三角形内部。像素中心在三角形内这个像素就算被覆盖生成一个片段中心点不在三角形内无论三角形边缘擦过这个像素多少面积这个像素也不会被点亮。这个规则叫“像素中心规则”pixel center convention。这个规则直接导致了一个经典现象——锯齿。三角形边缘是斜线时一条斜线扫过一行像素有的像素中心在线上方有的在下方于是边缘变成了一格一格的“楼梯”。理解了这一点你就会明白MSAA多重采样抗锯齿为什么有效它不是改变像素中心的判定规则而是在每个像素内部多放几个采样点看有多少采样点落在三角形内然后按比例混合颜色。光栅化仍然在看“点”只是看的点变多了。还有一个很细的规则共享边不重复覆盖。相邻两个三角形共有一条边时正常情况应该一个像素只被一个三角形光栅化否则这条边上的像素会被片段着色器执行两次像素最后写哪个值可能出现闪线和深度冲突。GPU内部用了一套“上边-左边规则”top-left rule来处理即只有三角形的上边缘或左边缘才产生覆盖。你不用写代码去控制它但如果你在工程里做地形网格、水面网格这种大量共享边的几何体遇到“网格接缝处出现暗线”时要意识到很可能是光栅化覆盖规则配合浮点精度抖动导致的而不是单纯的shader写错了。3. 光栅化后半程插值、透视校正与逐片元操作3.1 重心坐标与属性插值颜色和UV是怎么“均匀”流动的覆盖测试只能告诉你“哪些像素被点亮”还不能回答“这个像素该是什么颜色”。三角形的三个顶点可能各自有不同的颜色、UV、法线那中间某个像素的值是怎么来的答案是插值。光栅化器会为每个像素计算一组重心坐标barycentric coordinates。给定三角形三个顶点A、B、C以及三角形内一点P存在三个权重系数α、β、γ使得P α·A β·B γ·Cα β γ 1当P恰好是顶点A时α1、β0、γ0当P在三角形中心时三个系数各为1/3。只要这三个系数算出来像素P处的任意顶点属性X都可以通过 X α·X_A β·X_B γ·X_C 插值得到。这就是你看一个三角形的UV贴图不会一块一块撕裂的原因。重心坐标的计算本质上就是解一个线性方程组等价于用面积比去算。一个像素离哪个顶点越近对应的权重就越大属性值就越接近那个顶点。很多WebGL学习者看到shader里varying关键字知道顶点着色器的输出经过插值能平滑地传到片段着色器但对“插值发生在哪里”没有概念。其实插值发生在光栅化阶段不在顶点着色器也不在片段着色器。顶点着色器输出的varying变量会被光栅化器“记住”然后逐像素用重心坐标算出一个插值版本最后交给片段着色器执行。这个细节解释了为什么flat限定符在GLSL里存在——它告诉光栅化器“这个属性不要插值直接用第一个顶点或末个顶点的值”适合法线、实例ID这类不能线性插值的数据。3.2 透视校正让纹理和深度在3D里“不飘”插值听上去很简单但三角形一旦进入3D视角事情就变了。回想一下透视除法顶点坐标从裁剪空间变成NDC再变成屏幕窗口坐标这个过程中坐标被除以了w分量。问题在于经过透视除法后屏幕空间坐标和世界空间坐标之间不再是线性关系。如果你直接在线性光栅化的框架里对UV坐标做线性插值远处的纹理就会扭曲、抖动像贴了张会飘的纸。这是图形学里的经典问题透视校正插值perspective-correct interpolation。解决办法是在光栅化时大家约定“在屏幕空间里插值的是属性/w和1/w两个量。像素处先用重心坐标线性插值1/w再插值 属性/w最后相除除以1/w得到真正的属性值。这套操作本质上是在屏幕空间做线性插值却能得到透视空间里正确的结果。现代OpenGL和WebGL的GLSL里默认的varying插值已经是透视校正的你不用写任何额外代码。但如果你有两个疑问——第一为什么全屏后处理时感觉插值结果不太对第二为什么自定义的深度值插出来会抖动——多半就是没把透视校正这件事搞清楚。比如你想在片段着色器里手动重建世界坐标直接对NDC坐标做线性插值再用就很容易出错正确做法是接收一个约定好的世界坐标varying让光栅化器完成透视校正而不是自己在shader里算。有个noperspective关键字可以强制GLSL做线性插值而不做透视校正。在需要屏幕空间均匀分布的效果比如某些边缘光、扫描线效果里它反而有用。不过新手阶段默认用perspective就好别乱改。3.3 深度测试、MSAA与Early-Z光栅化之后还有多少事要办光栅化为每个被覆盖的像素生成一个片段这个片段还没上屏后面还排着一堆测试。其中最重要的就是深度测试每个片段都会带一个深度值通常是从插值后的z坐标算出来的GPU拿它和深度缓冲里对应位置已存的深度值比较决定是否通过。所以光栅化产出的每一个片段都会消耗一次深度测试的运算。如果你的场景里三角形重叠严重同一个像素上光栅化出十个片段深度测试就要运行十次其中九次大概率被丢弃。这部分开销你看不到但帧率会告诉你。GPU为此做了一个优化叫Early-Z早期深度测试。在不透明场景下深度值不需要在片段着色器里被修改GPU可以在光栅化刚结束、shader还没跑的时候先做一遍深度测试没通过的片段直接扔掉根本不用执行片段着色器。这能省下大量计算。但只要你使用了带透明度的绘制或者shader里写了修改gl_FragDepth的逻辑Early-Z就会失效GPU只能老老实实跑完整个片段着色器再测深度。MSAA多重采样抗锯齿的机制也和光栅化相关。开启MSAA后光栅化器会在每个像素内生成多个采样点比如4x就是4个采样点逐个做覆盖测试。一个像素只要有一个采样点落在三角形内就会生成一个片段但片段着色器仍只执行一次。最终resolve阶段再按采样点的覆盖率把颜色摊匀。这也是MSAA能在抗锯齿的同时不大幅牺牲性能的原因——它增加的是光栅化覆盖测试的开销而不是片段着色器的开销。反过来如果你在片段着色器里做了特别重的计算比如循环一堆光照开MSAA通常比超采样抗锯齿(SSAA)划算得多因为着色次数没涨。4. WebGL里的光栅化现场实操与调试4.1 用FBO把光栅化结果拿到手说了这么多原理来点实操。想亲眼验证光栅化规则最直接的办法是绕开浏览器把光栅化产物读回到内存里看。这就要用到帧缓冲对象FBO和readPixels了。一个最小操作流程是这样的创建一个WebGL2上下文。创建一个纹理或渲染缓冲对象作为FBO的颜色附件。绑定FBOgl.clear清屏。绘制一个三角形哪怕只是最简单的三顶点单色三角形。调用gl.readPixels把FBO里的像素读回数组。把数组输出到控制台或转成图片查看。你会发现在readPixels读回来的数据里三角形边界刚好落在“像素中心点进入三角形”的那一圈像素上。边缘上的像素颜色是纯色如果没开抗锯齿或者是混合后的颜色如果开了MSAA。这能直接验证“覆盖测试看像素中心点”的规则。实操中有几个坑得提醒注意readPixels读回的像素原点在左下角而浏览器里图片、canvas的坐标原点在左上角。你读回的数组顺序和下屏图片是上下倒着的处理时要自己翻转不然排查半天以为光栅化错了其实是坐标方向弄反了。另一个坑是读取FLOAT类型的颜色缓冲时WebGL1需要检查OES_texture_float扩展WebGL2则要确认格式组合匹配比如gl.R32F带gl.RED、gl.FLOAT。直接按UNSIGNED_BYTE去读一个浮点纹理读回来的数全是错的。我在做流体模拟调试时踩过这个坑光栅化后把速度场读回来检查数值结果全是一串看起来正常的垃圾数据折腾了一晚上才意识到是读取格式不匹配。用readPixels虽然能拿到精确的像素值但性能很慢因为它需要GPU把数据拷贝回CPU内存还会打断GPU的流水线。所以调试时用它看数据没问题千万别在每帧渲染里调它——帧率会直接崩给你看。4.2 常见问题排查半像素偏移、锯齿和过绘制实际操作中光栅化相关的问题有很高的出现频率我整理了几类最典型的附上排查思路现象根源排查与解决全屏后处理画面边缘模糊或偏了半像素视口变换时像素中心对齐不一致NDC坐标到窗口坐标的映射有半像素偏移检查gl.viewport设置做全屏quad时把顶点坐标和gl_FragCoord.xy对照必要时偏移半个像素微调纹理贴图远处扭曲、抖动使用了非透视校正插值检查GLSL里是否误用了noperspective或者手动插值了NDC/窗口坐标属性网格接缝、边缘暗线共享边的覆盖规则和浮点精度抖动或法线插值后光照方向不一致把三角形顶点稍微焊住、统一网格精度检查贴图是否有边缘色差先排除光栅化问题场景FPS低但顶点数量不多三角形过碎大量像素被重复覆盖填充率打满做depth prepass、减少深度测试失败开销对细小几何做LOD合并或剔除透明物体排序乱边缘有锯齿透明物体不能Early-Z片段shader执行了但被丢弃透明物体按距离排序、减少透明面重叠MSAA与alpha blend结合不佳时可考虑alpha-to-coverage画点粒子时点的大小上限不够用gl_PointSize有实现相关的最大值限制点光栅化后不是想象那么大查询gl.ALIASED_POINT_SIZE_RANGE需要更大的粒子可以用billboard三角形替代GL_POINTS这里面最容易被忽略的是半像素偏移。OpenGL/WebGL体系的窗口坐标里像素中心落在整数坐标上比如像素(0,0)的中心在(0.5,0.5)这一点要分情况看你用的坐标系定义这个细节在普通三角形绘制里感知不强但在做全屏后处理、粒子拖尾、UI叠加效果时偏差半个像素就会导致明显的边缘模糊或错位。遇到这种问题先把视口变换公式自己写一遍确定映射关系再去调顶点坐标。过绘制问题则是性能排查的重灾区。早期我做地形渲染地形瓦片网格非常密大部分三角形在地平线附近被压得极小光栅化器要在这些巴掌大的三角形上来回覆盖像素帧率惨不忍睹。后来做的优化有两个一是根据屏幕空间误差调度LOD远处的瓦片用更稀疏的网格二是做一次深度预通道depth prepass先只写深度不跑光照shader把被遮挡的像素提前扔掉第二遍再跑完整着色。这个改法把同一场景的帧率从40帧拉到60帧代价只是一次额外的几何绘制。4.3 全屏三角形光栅化作为“逐像素计算引擎”聊到后处理和流体模拟有一个光栅化的特殊用法特别值得单独拎出来讲全屏三角形。所谓全屏三角形就是绘制一个覆盖整个视口的大三角形或两个组成屏幕的三角形。这个三角形经过常规的光栅化流程之后会把每一个像素都点亮生成一个片段。然后你在对应的片段着色器里做大规模逐像素计算——采样纹理、做卷积、解方程、写回结果。整个过程本质上是在“用光栅化器驱动一个逐像素的并行计算机”。现代WebGL里很多“计算型”效果都是靠全屏三角形实现的最典型的就是流体模拟。比如最近网上热度很高的Vortex Fluid Simulation、Cyclone这类基于WebGL的涡流流体模拟项目核心思想是把流体速度场、密度场存成一张张纹理每一帧渲染两三个全屏三角形在片段着色器里完成“平流-扩散-外力-投影”这些流体步骤。光栅化在这里的角色是给每个像素提供一个统一的着色入口。你不需要关心三角形长什么样子只要它能把屏幕铺满就能让GPU在一个像素一个像素地执行你的算法。全屏三角形有个实现细节要注意不要用两个小三角形拼成的全屏quad直接给一个覆盖屏幕的大三角形。这样可以节省对角线上的重复扫描还能减少一些对角边缘的插值偏差。顶点坐标给(-1,-1)、(3,-1)、(-1,3)这样超出视口的范围让光栅化器裁剪掉多余部分只留下屏幕区域。这种方法在地形可视化和流体效果里我用过很多次稳定且性能更好。5. 光栅化在真实项目里的延伸地形、引擎与流体5.1 高程数据与地形可视化每块网格都在过光栅化光栅化离你最近的重度应用应该是三维地球和地形可视化。Cesium这类地理场景里高程数据DEM通常组织成规整的网格每块瓦片就是一张高度图。开发时上传高度图纹理或几何数据顶点着色器根据高程值修改顶点的y坐标然后交给光栅化器把网格三角形转成屏幕上的像素最终呈现起伏的山体。理解光栅化规则对做地形有一个实在的好处你能判断一个网格三角形在屏幕上到底占了几个像素。如果三角形太小一个像素被好几个三角形轮番覆盖填充率白烧如果三角形太大地形细节又不够。Cesium里有个核心指标叫屏幕空间误差Screen Space Error, SSE本质就是在控制三角形光栅化后的屏幕尺度。LOD切分的逻辑说白了就是在“三角形太大、细节不够”和“三角形太小、光栅化浪费”之间找平衡。我做地形项目时的经验是尽量保持网格三角形在屏幕上的投影边长不小于2~3个像素小于这个阈值就切到低精度的LOD瓦片。这样光栅化器的覆盖测试不会过度浪费地形又不会丢失轮廓。5.2 大规模地理渲染引擎如何“绕着光栅化优化”在GIS可视化领域常会用到一些面向海量地理数据的WebGL渲染引擎比如Loca这类专注于地理空间可视化的渲染引擎。做大数据量热力图、轨迹线、建筑群的时候三角形数量动不动就是几十万上百万这时候你会发现大家的优化思路高度一致——都是在想办法减轻光栅化阶段的负担。常见的手段包括把点和线用GL_POINTS和TRIANGLE_STRIP绘制减少重复顶点把多个几何体合并到同一个drawArrays调用里减少绘制命令的切换在地图缩放时动态调整几何密度避免一堆三角形挤在几个像素里。这些优化表面上是在处理CPU和顶点数据实际上最后都在服务同一个目标——让光栅化器产生的片段数量更合理。有一类地理可视化效果特别典型在大量点数据上做发光光晕。如果你对每个点都渲染一个有渐变边缘的大三角形光栅化生成的片段数量会非常可观。引擎的做法往往是分层绘制、预计算光晕纹理、缩小点的绘制范围让光栅化只在真正需要的像素上工作。我记得有一次对照Loca的源码排查一个发光点图层掉帧的问题最后发现是我把光晕半径设得太大同一块区域里重叠了十几个点光晕填充率直接超了。把光晕半径缩小并合并批次后帧率恢复了。5.3 流体模拟里的网格法与粒子法光栅化如何“客串计算单元”流体模拟是WebGL里最炫的光栅化延伸应用之一也是理解“光栅化不只是画三角形”的绝佳案例。目前WebGL上常见的流体模拟有两种思路。一种是欧拉网格法把空间划分成网格每个格子存储速度、密度等物理量。模拟时每一帧渲染全屏三角形在片段着色器里迭代求解Navier-Stokes方程的各个项。这里的难点是迭代过程必须把结果写入纹理下一帧再读回来所以要用双缓冲ping-pong纹理。光栅化器负责逐像素驱动这套计算它产出的不是最终画面而是“下一帧的物理场”。另一种是粒子法比如SPH把流体离散成大量粒子每个粒子用一个小点或小球表示。渲染时可以把粒子看作是GL_POINTS的点图元光栅化器对每个点做覆盖测试生成圆形粒子。这类粒子数量大时光栅化器同样要处理海量小图元的覆盖所以粒子半径、粒子数量、屏幕分辨率三者的平衡直接决定帧率。仔细观察那些热门的WebGL流体模拟项目你会发现它们大多同时用了这两种思路先用网格法算速度场和密度场再把密度场的最终结果显示出来。显示的那一步本质上仍然是一个全屏三角形的光栅化纹理采样过程。理解光栅化在这里的角色后遇到“流体模拟帧率上不去”“网格纹理出现小白点”这类问题你排查起来就有方向了——白点通常就是偏移太小或精度问题导致光栅化覆盖测试的边界抖动要把物理量存储格式从UNSIGNED_BYTE换成浮点纹理或者调整模拟步长。5.4 关于光栅化性能的一些实操心得最后分享几条我在项目里反复用到的性能优化经验都是围绕光栅化的特性总结出来的控制过绘制。场景里不透明物体多时先做一遍深度预通道再跑正式渲染能让片段着色器少执行一大半“肉眼看不见”的像素。这个策略在地形、城市建模、粒子系统里都有效。少画小三角形。三角形越小光栅化器在覆盖测试上的相对开销越大。能用顶点多、面积大的面片模拟出细节就不要硬切碎网格。LOD的本质就是让屏幕上的三角形大小保持合理区间。能合批就合批。减少drawArrays调用次数让图元装配阶段不空转光栅化器才能持续满载干活。注意纹理和帧缓冲格式。在FBO里做后处理或流体迭代时能用HALF_FLOAT就不上FLOAT能读UNSIGNED_BYTE就不读浮点不然readPixels效率低纹理带宽也紧张。MSAA不是万能的。开启MSAA后光栅化覆盖测试的采样点数量增加三角形太小的情况下MSAA的收益也有限。粒子、细线大量出现时通常还不如靠透明度排序和形态学抗锯齿FXAA来处理。说到底光栅化是图形渲染里最“实在”的一段计算。它没有花哨的算法炫技但它的规则决定了每一帧画面的边界和性能底盘。把重心坐标、覆盖测试、透视校正这些概念真正吃透之后你再看WebGL的报错、画面瑕疵和性能瓶颈很多问题一眼就能定位到管线的正确环节。这比背几十个API参数有用得多。
