同样做一个雷达扫描效果有人直接在 Cesium 上用 Entity 加一个动态圆环结果视角一拉远画面就开始掉帧另一个人只写了二十多行 GLSL地图转得再快扫描纹路依然像贴在上面一样顺滑。差别不在电脑配置而在谁把动画放对了地方。Cesium 特效的丝滑从来不是某个参数调出来的。它背后是一整套渲染管线的取舍哪些计算留在 CPU哪些数据交给 GPU动画驱动放在哪一层。很多人看完别人的效果第一反应是“他封装了什么高级材质”其实真正拉开差距的是你能不能理解 Shader 在 WebGL 里扮演的角色。这篇文章会用地图扫描和飞线动画两个最常见的特效从实现思路一路拆到 WebGL Shader 的底层原理。看完之后你至少能判断一个特效该用 Entity 还是 Primitive该用现成 Material 还是自己写 Shader以及遇到了“WebGL 显卡似乎不能正常工作”这类报错应该从哪里查起。1. 别急着写 Shader先搞清楚 Cesium 渲染管线的关键分层在讨论“怎么写”之前得先把“在哪一层写”这件事想明白。Cesium 是跑在 WebGL 之上的三维地图引擎它暴露了两套完全不同的开发接口。一套是 Entity API另一套是 Primitive API。很多人觉得 Entity 用起来简单Primitive 写起来麻烦于是特效一律拿 Entity 凑。但“麻烦”的底层恰恰是可控性。1.1 Entity API 和 Primitive API 不是表达方式差异而是性能分水岭Entity API 的设计目标是快速搭建可交互的实体对象。你想在某个经纬度放一个广告牌、一个圆环或一条线只需几行代码。它内部帮你封装了几何生成、材质管理、渲染状态和更新策略。这种封装在业务功能开发里是好事但放到特效场景就会露馅。举一个很典型的例子。如果你用 Entity 加一个动态雷达波纹最常见的做法是在CallbackProperty里不断修改半径或位置。这个回调每帧都会触发意味着 CPU 要做几件事重新计算几何参数、更新 Entity 内部状态、请求 Cesium 刷新渲染。如果这个几何体顶点数少还好一旦波纹变成多层再加上别的飞行器、轨迹线、选中框主线程的负载会迅速上升。Primitive API 则不同。它允许你直接管理 Geometry、Appearance 和 RenderState。几何数据可以一次性创建好上传到 GPU 之后就不动了动画部分通过 Shader 里的 uniform 变量驱动例如把当前时间传进去GPU 每帧只需要重新计算颜色或位移不需要重新生成几何体。我把这两种方式的关系类比成一个项目里的两种协作模式Entity 是“你提需求我帮你做”Primitive 是“你把数据给我我自己控制流程”。前者省心后者可控。而特效这种强依赖实时变化的场景控制力比省心重要得多。1.2 特效的载体Geometry、Appearance、RenderState 三件套用 Primitive 做特效要理解三个核心对象。Geometry 负责描述“形状”和“数据布局”。它定义顶点位置、法线、纹理坐标、颜色以及这些 attribute 如何绑定到 GPU 缓冲区。比如一个圆环扫描效果你可以用 CircleGeometry 生成基础几何体也可以自己写一个 PolygonGeometry 来精确控制每个顶点的 UV 分布。Appearance 负责描述“怎么渲染”。它由一个顶点着色器和一个片元着色器组成。Cesium 内置了 MaterialAppearance、EllipsoidSurfaceAppearance 等可以应对常规材质。但自定义特效通常要自己写 GLSL 字符串然后塞进 Appearance 里。RenderState 负责描述“绘制时的状态”包括深度测试、混合模式、剔除、锯齿偏移等。很多特效出问题不是因为 Shader 写得不对而是 RenderState 没配对。比如半透明扫描波纹通常需要关闭深度写入、开启透明混合否则会出现一层层互相遮挡的瑕疵。理解这三件套再看一个丝滑特效的代码就不会觉得它是魔法了。它就是一组精确定义的几何数据加一段在 GPU 上逐像素执行的着色逻辑再配一组合适的渲染状态。2. 地图扫描 / 雷达特效的源码级实现从 UV 坐标到 uniform 时间雷达扫描、动态光照、可视域分析这几个特效在底层套路是共通的用一个随时间变化的量去驱动片元着色器里的透明度或颜色。以最常见的“雷达波纹扩散”为例我们可以拆成几步来实现。2.1 先画一个圆环Geometry 的构造与纹理坐标映射如果只是画静态圆用 Entity 里的 ellipse 就够了。要做扫描效果你需要的是“带 UV 信息”的平面几何体。这里最基本的思路是创建一个以圆心为中心的平面或者一个贴合地形的圆面。为了简化你可以先跑一个最普通的CircleGeometry然后手动把每个顶点的st属性映射成“从圆心向外 0 到 1 的归一化距离”。如果你的 UV 没有覆盖这个信息在片元着色器里就很难判断“当前像素距离中心多远”。在 Cesium 里你可以通过CustomGeometry或直接构造Geometry的 attribute把 position 和 st 一起放进去。假设圆心是原点半径是 R一个顶点坐标为 (x, y)那么 st 可以设置成u x / R / 2 0.5 v y / R / 2 0.5这样 UV 的中心是 (0.5, 0.5)边缘则是更接近 0 或 1 的值。你也可以直接传一个 distance 属性给片元着色器省去在 Shader 里做距离计算的步骤。2.2 Shader 里怎么让扫描圆环动起来uniform time 与 mod 函数拿到 UV 之后接下来的逻辑全部在片元着色器里完成。核心思路是这样的计算当前片元到中心点的距离dist。用时间u_time不断改变扫描环的半径。用取余函数mod生成周期性波纹。用smoothstep把硬边变成柔边避免锯齿。下面是一段简化的 GLSL 片段风格是示意不是直接抄进工程就能用uniform float u_time; uniform vec4 u_color; varying vec2 v_st; void main() { vec2 center vec2(0.5); float dist distance(v_st, center); // 用时间偏移波纹相位 float wave mod(dist * u_scale - u_time, 0.2); // 用平滑步长生成一条宽度可控的亮带 float ring smoothstep(0.0, 0.03, wave) * (1.0 - dist); gl_FragColor vec4(u_color.rgb, ring * u_color.a); }这里面的u_scale是控制波纹密度的系数u_time是每帧在渲染循环里更新的 uniform。为什么用mod而不是if因为 GPU 在分支处理上和大规模并行计算并不友好遇到不同片元走不同分支时可能存在严重的性能回退。用mod做周期函数本质上是在把所有片元放在同一个数学公式里统一计算这更贴合 GPU 的架构。要让这段 Shader 跑起来你还需要在 update 回调里不断更新u_time。这一步很轻CPU 的工作量只是赋值一个 float而不是每帧重新生成几何体。这就是它丝滑的根源。2.3 从雷达扫描延伸到动态光照和可视域分析的思路雷达扫描理解之后其他几个效果就不会觉得神秘了。动态光照的本质是把一个表示“光源位置”的 uniform 传入场景然后在片元着色器里根据片元法线和光线方向的夹角动态调节亮度。你可以把它理解成“用 Shader 画一个会移动的手电筒”。可视域分析也是同理。常见的做法是先生成一张视锥或半球形的遮挡体再用 Shader 对可见区域和不可见区域做颜色区分。你不需要每帧重新计算遮挡只需要把视角方向和地形采样结果作为 uniform 传进去就能在 GPU 上完成实时渲染。这种效果如果用 CPU 做射线求交顶点一多基本就卡死了。所以判断一个特效能不能做成“丝滑”有一个简单的标准如果这个特效需要每帧改变成千上万个顶点的坐标那它就适合把变化放入 Shader 里用 uniform 驱动如果特效真的需要每帧改变拓扑结构那就得慎重评估数据规模和 CPU 计算成本。3. 飞线动画的拆解曲线路径、UV 分配与高光推进飞线动画是另一个高频特效也是很多 Cesium 项目里被做得最“油腻”的效果之一。有人做出来像一根根彩色的毛毛虫在爬有人做出来像真实的光束在传导。差别出在哪里多半是对“飞线”这个抽象概念的理解不到位。3.1 飞线不是“画一条线”而是一条带随时间前进的色带如果你只用PolylineGraphics加一个动态颜色回调做出来的效果基本就是整条线在闪烁或变色。这不是飞线而是变色线。飞线的核心在于“局部高光移动”也就是线上有一个亮点和渐变色尾迹在不断前进。要实现这一点至少需要两个信息线路上每个点在整个路径中的长度比例ratio以及一个控制进度的 uniformu_progress。通过比较ratio和u_progress的差值来确定当前片元处于高光前、高光区还是高光后。另一种实现方式是给不同顶点分配不同的v_ratioattribute在顶点着色器里把它作为 varying 传到片元。这样线段上的每个像素就能知道自己在整条线中的位置。3.2 用样条曲线生成顶点数据把线的长度映射到 0-1飞线的路径通常不是直线。从 A 点到 B 点如果直接画一条线视觉上非常僵硬。常见的做法是用 Catmull-Rom 样条或三次贝塞尔曲线在 A 点和 B 点之间插入多个控制点生成一条平滑的弧线。生成好坐标后要把“累积长度”归一化到 0 到 1。这一步很关键因为 Shader 里需要知道当前顶点处于路径的哪个进度。如果你直接用顶点索引除以顶点总数遇到顶点分布不均匀时高光移动速度会忽快忽慢。正确做法是遍历顶点计算每个顶点到起点的弧长再除以总长度。这个数据准备好之后几何体就包含了两个重要属性position世界坐标或相对坐标。lineRatio当前顶点在整条路径中的进度范围 0 到 1。有了这两个属性剩下的动画逻辑就可以全部交给 Shader。3.3 片元着色器里做高光移动为什么用 fract 而不是 sin飞线在 Shader 里的核心逻辑长得像这样uniform float u_progress; // 0 到 1控制飞线进度 uniform float u_width; // 高光宽度 varying float v_lineRatio; void main() { // 当前片元的进度与全局进度之间的差值 float diff v_lineRatio - u_progress; // 生成一个向前平滑渐变、向后快速衰减的光带 float head smoothstep(0.0, 0.05, diff); float tail 1.0 - smoothstep(-0.1, 0.0, diff); float glow head * tail; gl_FragColor vec4(u_color.rgb, glow * u_color.a); }如果希望一条飞线路上同时有多个光点可以用fract(u_progress * 3.0 v_lineRatio)这样的形式让进度在一个周期内重复出现。这就是为什么很多 Shader 代码里出现fract或mod而不是直接写一个sin。因为sin适合做连续波浪而飞线需要的是“一段一段向前推进”的非对称高光用取小数部分的思路更容易控制亮带长度和间隔。这里还有一个细节透明飞线叠加时要保证渲染顺序正确。如果多段飞线互相穿插又没有关深度写入就可能出现前一条线挡住后一条线的瑕疵。一般建议把飞线放在半透明队列再配合深度测试必要时调整RenderState中的depthMask为false。4. WebGL Shader 底层原理GPU 为什么比 CPU 快以及常见误区到了这一步你会发现所有丝滑特效共同依赖一个底层能力Shader。但 Shader 不是一段“魔法代码”它是运行在 GPU 上的可编程单元。理解 GPU 的并行模型你才能准确地判断什么时候该用 Shader什么时候不该用。4.1 顶点着色器与片元着色器各管哪一段WebGL 的渲染管线可以简化成CPU 提交顶点数据 → 顶点着色器处理每个顶点 → 图元装配 → 光栅化生成像素 → 片元着色器计算每个像素颜色 → 深度测试和混合 → 输出到屏幕。顶点着色器是逐顶点执行的。它的输入包括顶点位置、法线、UV 等 attribute以及全局的 uniform。它要做的是把模型坐标转换到裁剪坐标顺便把需要后续插值的数据传给片元着色器。片元着色器是逐像素执行的。它接收从顶点着色器插值过来的 varying计算最终颜色和透明度。你写的扫描环、飞线高光、动态光照都在这一层发生。这两段程序都很短但它们会被 GPU 复制成千上万份并行跑在成百上千个核心上。正因为每个像素的计算互相独立GPU 才能用多核心把所有像素一起算完。这是 Shader 表现力强、又不容易卡顿的根本原因。4.2 坐标系变换链从模型坐标到屏幕坐标很多新手写 Shader 一头雾水是因为没搞懂坐标变换链。一个顶点从“本地坐标”到“屏幕上可见的像素”中间要经过多层变换模型坐标 - 世界坐标 - 视图坐标 - 裁剪坐标 - NDC - 屏幕坐标在 Cesium 里这些变换通常由内置函数自动完成比如czm_modelViewProjection矩阵。你可以在顶点着色器里看到类似gl_Position czm_modelViewProjection * vec4(position, 1.0);的写法。理解这条链的意义是当你发现特效位置对不上不要急着改颜色先检查是不是坐标变换漏乘了一个矩阵。一个很容易踩的坑是把“经纬度”直接当成“平面坐标”放进 Shader。Cesium 默认处理的是三维地球坐标如果你要在地球上绘制一道扫描圆环最好直接用 Cesium 的几何工具生成贴合范围的几何体而不是在 Shader 里自己做经纬度换算。4.3 为什么你会遇到“WebGL 显卡似乎不能正常工作”排查链路这一条几乎是所有浏览器三维应用的“劝退点”。当你打开某页面看到黑屏或一段提示“WebGL 显卡似乎不能正常工作”通常不是代码问题而是浏览器没有启用硬件加速或显卡驱动不被 WebGL 认。常见的排查顺序是打开浏览器的硬件加速开关。在地址栏输入about:gpu查看 WebGL 状态确认 WebGL 是“Hardware accelerated”而不是“Software only”或“Disabled”。更新显卡驱动尤其是 Windows 系统下的集成显卡和独立显卡切换策略。检查是否有旧版浏览器不支持当前 Cesium 版本要求的 WebGL2 特性。如果是远程桌面、虚拟机或云桌面环境虚拟显卡可能不支持完整 WebGL 特性此时建议使用标准 GPU 直通或改用软件渲染测试。从工程经验看90% 的“WebGL 显卡似乎不能正常工作”都出在环境配置而不是代码。如果你在本地跑得好好的换了一台电脑就黑屏优先查 GPU 列表而不是改 Shader。5. 特效卡顿、闪烁、锯齿的排查顺序写完了 Shader效果也出来了但不代表万事大吉。实际项目里更常见的是“东西能显示但总觉得不舒服”。这个时候不要凭感觉乱改参数按链路一点一点查。5.1 先看现象是帧率低还是加载慢还是渲染闪烁帧率低说明每帧绘制成本过高。加载慢说明几何体生成、纹理上传或资源加载卡顿。渲染闪烁说明混合模式、深度测试、排序或 uniform 更新有问题。这三种现象对应完全不同的排查方向不要混在一起。我见过有人因为页面卡顿花了一下午调 Shader 里某个smoothstep结果最后发现是加载了 20 张 4096 分辨率纹理上传一次要几秒钟。先把现象分类能节省大量时间。5.2 再看输入Geometry 顶点数、纹理大小、uniform 更新频率Shader 再高效也扛不住几何体本身庞大。一个雷达扫描效果如果圆面生成了几十万个顶点那它的绘制开销天然就高。一般来说简单扫描环几千到几万个顶点足矣。飞线动画每条线采样几十到几百个点就够了。粒子特效尽量用 GPU 粒子避免 CPU 每帧更新上千个粒子的位置。纹理大小也很关键。如果你的 Shader 要用到噪声图或遮罩图尽量把纹理控制在 512x512 或 1024x1024 以内。纹理覆盖大范围场景时可以用重复采样或分块加载而不是一次性塞进一张超大图。还有 uniform 更新频率。如果 uniform 里有一个大数组要每帧重建那么 CPU 端的拷贝开销也会拖慢帧率。尽量把数组改成小而简单的值或者用纹理传入复杂数据。5.3 再看环境硬件加速、WebGL 版本、Cesium 版本、依赖冲突Cesium 对 WebGL 的支持一直在演进。较新的版本对 WebGL2 和最新特性的依赖更强如果你的浏览器版本停在三年前打开最新 Cesium 项目可能会出现兼容性问题。遇到这种情况先去 Cesium 官方文档确认你使用的版本对 WebGL 的要求。还有一个高级话题Cesium 和 three.js 共享 GL 上下文。它的思路是两个渲染引擎操作同一个 WebGL 上下文省去在多个 canvas 之间拷贝数据。听起来很诱人但它也意味着两个引擎的 GL 状态会被互相污染。共享上下文时你需要在切换引擎时保存和恢复绑定状态否则会出现纹理丢失、RenderState 错乱等诡异现象。如果只是需要在 Cesium 场景里叠加 three.js 对象更稳妥的方案是使用 Cesium 的Scene.pickPosition或外部框架集成而不是强行共享上下文。5.4 再看代码RenderState、深度测试、stencil 设置很多闪烁问题都来自 RenderState 配置。半透明特效最常见的问题是深度写入开启导致透明物体内部互相遮挡。一般处理思路是关闭深度写入只保留深度测试然后通过混合模式叠加颜色。场景里如果有多个半透明特效还要关注绘制顺序。Cesium 内部会对半透明 Primitive 做排序但你的 Shader 里如果有“不透明和半透明混用”的逻辑就可能打破排序规则。遇到闪烁优先检查是不是半透明物体被不透明物体遮挡或者多个半透明物体互相穿插。stencil模板缓冲则常用于区域裁剪或挖洞。如果你在同一场景里用了另一种依赖 stencil 的库或后期特效就有可能冲突。排查时可以先禁用 stencil 相关逻辑看问题是否消失。6. 从“会写特效”到“能落地特效”工程化封装与选型建议最后想聊一个很多人容易忽略的问题特效的工程化。在 demo 里写一个 Shader 很酷但放到真实项目里还涉及封装、复用、资源释放、团队协作和版本兼容。一个特效如果不能被其他人轻松复用那它的价值会大打折扣。6.1 不要重造轮子先看官方示例和已有特效库Cesium 官方示例里其实有大量现成的材质和几何用法覆盖了雷达扫描、飞线、动态墙、粒子效果等常见方向。如果你只是需要“一个能看的雷达波纹”先搜一下官方文档和社区库通常半小时就能跑通。如果项目里有多个特效需求或者团队里图形基础薄弱也可以考虑采购成熟的特效库。热搜里出现“cesium特效库采购”不是没有道理。商业特效库通常把 Geometry、Shader、RenderState 都封装好了你只需要传参数。但要注意授权范围、版本兼容和技术支持不要只看演示视频。代码本身是不是有清晰的 API、有没有处理过 Resize、有没有释放资源的方法这些都要在采购清单里反问一遍。6.2 特效开发的四步法输入 → 几何 → Shader → 状态我给定了“先跑通、再优化、最后工程化”的思路之后总结出一个适合大多数 Cesium 自定义特效的四步法。第一步定义输入。明确这个特效需要哪些参数比如中心点、半径、颜色、速度、方向、起始结束位置。第二步创建 Geometry。根据参数生成顶点数据尽量让 Shader 需要的信息提前存在于 attribute 中例如 UV、距离比例、法线。第三步编写 Shader。把动画部分交给 uniform把数据依赖交给 attribute保持 Shader 逻辑简单清晰。第四步设置 RenderState。明确新的特效是否需要深度测试、是否半透明、是否关闭深度写入、是否需要关闭面剔除。然后封装成一个 Primitive 类对外只暴露 start、stop、update 和 destroy 方法。如果你在做多个特效尽量让每个特效遵循同一个生命周期。这样可以避免“这个特效用了 requestAnimationFrame那个特效没有最后页面直接卡死”的混乱。6.3 什么场景该用 Entity什么场景必须用 Primitive这不是一个非黑即白的问题。我的判断标准很简单如果动画频率低、顶点数少、只需偶尔变化Entity 完全够用如果动画需要每帧更新、顶点数多、且希望接近 60 帧运行Primitive 自定义 Shader 是更稳的路线。具体来说选点、打标签、加单个 billboard用 Entity。做简单颜色变化、闪烁用 Entity 内建 Material 也能顶住。做动态波纹、大规模飞线、粒子系统、地形扫描、可视域分析优先考虑 Primitive Shader。如果团队里没有熟悉 WebGL 的人先不要一上来就写自定义 Shader可以把 Entity 方案验证清楚再逐步过渡。6.4 如果你的需求是批量对接还要考虑资源释放和上下文管理真实项目里特效不是只跑一次的可能要在地图上建几十个雷达站、上百条飞线。这时你必须考虑资源释放。Cesium 的Primitive有destroy方法Geometry 有 GPU buffer 占用Shader 程序也有生命周期。如果你只增不删播放一晚上就可能把显卡内存吃满。另外如果特效库和业务代码混在一起建议统一做一个特效管理模块负责所有 Primitive 的创建、更新、移除和销毁。这样即使某个特效的 Shader 写崩了也不会影响其他业务功能。Cesium 特效做得好不好最后考的不是你会几个函数而是你愿不愿意把一次临时效果沉淀成一套可复用流程。这个流程可能不复杂但它决定了你的特效是只能出现在 demo 里还是能真正跑在客户设备上、扛得住真实数据量和长时间交互。做特效这事也和做其他技术一样先跑通一个再谈优化先优化一个再谈封装。别一上来就堆十几个效果把最简单的雷达扫描写明白你已经超过了大多数人。