在UE5里做风大家第一反应就是拖一个WindDirectionalSource进去。方向、强度、速度一调场景里的草和树马上会动确实方便。但真到了做风力可视化、局部气流模拟这种需求那个全局风向源就不太够看了——它只能给场景一个统一的吹拂方向没法表达建筑绕流、山谷回旋、台风眼这种空间上不均匀的风。我这次的项目代号叫“UE5 Wind - 01 Niagara Grid”核心思路是用Niagara粒子系统的Grid布局方式把风场变成一个规则点阵每个点位上带风向和风速再用粒子把它画出来。这篇就从头到尾拆一遍这套方案包含粒子发射器怎么配、网格坐标怎么写、风矢量怎么生成、怎么用Sprite和Ribbon把风“画”给人看以及几个我踩过的坑。适合正在研究Niagara的技术美术、想给项目加风场可视化的开发者以及做气象、建筑风环境展示的朋友参考。1. 为什么要用Niagara Grid做风场1.1 全局风向源和粒子风场的差距在哪UE5自带的WindDirectionalSource是个纯“全局性”的风。它对场景里所有挂了风响应材质的物体一视同仁就像在房间里开了一台大风扇扇叶一转整个房间的纸片都往一个方向飞。这套逻辑做天气系统、做开阔地带的植被摆动完全够用性能开销也低。但遇到需要展示“风绕过一栋楼之后在背后形成涡旋”这种细节全局风就只能摊手了。粒子系统则完全不同。粒子的优势是“每一个粒子都是独立个体”可以各自持有位置、速度、颜色等属性。如果我们把粒子撒到空间里让每个粒子根据当前位置计算一个风矢量再把这个矢量用各种方式画出来就能得到一张空间流场图。问题也随之而来粒子随机撒的话点在空间里疏密不均形成的流场图像噪点一样看不出清晰走向。这时候就需要Grid——规则网格点阵——来保证采样点的均匀性。1.2 Grid的本质把空间拆成规则采样点Grid说白了就是把一块空间切成等间距的格子每个格子中心放一个粒子作为采样点。64x64的Grid就是4096个点每个点之间有固定间距比如10厘米、1米、10米规则得像坐标纸一样。这样做有三个明显好处。第一视觉上稳定。粒子之间间距一致渲染出来的风场就是一张干净的矢量云图不会像随机撒粒子那样出现一堆空白区域和一团密集粒子。第二便于计算。规则点阵里每个粒子的坐标可以由它的序号直接推导出来不需要额外存储复杂的位置数据结构。第三方便对接后续的数据管线。风场本质是一个空间离散场这个场完全可以用2D或3D纹理来表达。规则网格和纹理像素天然一一对应后面想把风数据存进Grid Data Interface、让场景里的材质和其他系统来采样会顺滑很多。我常拿天气预报的风场图来理解这件事气象台展示风向就是在等间距的经纬网格上画箭头箭头方向代表风往哪吹。Niagara Grid做的事和这个几乎一样只是把网格放进了3D场景里。1.3 这套思路能用在哪些地方Niagara Grid风场并不只是个炫技的粒子Demo。我实际接触到的场景至少有这么几类气象可视化把历史气象数据写成风场在场景里呈现台风路径、洋流走向Grid的规则排列让画面像极了专业气象图。建筑/城市风环境分析模拟风绕过楼宇的路径给建筑设计提供直观的气流展示甲方一眼就能看懂。游戏关卡设计提前预览某个区域的常规风向用于布设落叶、旗帜、烟雾等环境特效让特效顺着风场走比瞎调方向自然得多。流动场调试做车辆尾流、飞机涡流、水下暗流特效前先用Grid点阵验证流场形状再决定粒子发射策略。这套方案和WindDirectionalSource不是互斥的反而是互补关系。下面这张表可以快速对照维度WindDirectionalSourceNiagara Grid 风场空间粒度全局统一每个点独立可表达局部差异风场形状单一方向、单一强度任意形状可叠加噪声和扰动可视化能力基本不可见可通过粒子颜色、箭头、流线展示数据复用材质直接读取可写入Grid Data Interface供多方采样性能成本极低粒子数量和更新频率决定可控适用场景宏观天气、植被摆动局部可视化、精细气流、数据呈现一句话总结如果你的风只是一个“方向”用WindDirectionalSource如果你的风是一张“场”那就得上Niagara Grid。2. 搭建Grid风场粒子系统的基础配置2.1 新建Niagara系统和发射器的关键选项在内容浏览器里右键创建Niagara系统选空模板即可。关键在添加发射器这一步我建议选择“Empty”类型发射器然后手动把Simulation Target改成GPU Simulation。为什么用GPU因为Grid风场动辄几千个粒子每个粒子都要实时计算噪声和风矢量CPU还得分线程、同步数据在编辑器和独立进程里都容易卡。GPU模拟把这些计算放到显卡上粒子数量到了几千上万也能保持流畅。发射器的两个细节我要多说一句。一个是Local Space默认关掉就好风场是世界空间的东西开了Local Space会导致粒子跟随组件变换角度不对的时候整个风场都会歪。另一个是固定边界Fixed Bounds把边界尺寸稍微调大一些比如长宽各500高度200避免粒子超出边界后被裁剪导致风场画面突然缺一块。2.2 核心步骤用Custom HLSL生成64x64规则点阵生成Grid的方式有两种一种是直接拖节点用Niagara自带的位置分布模块另一个是用Custom HLSL自己算坐标。我推荐后者因为自己算坐标可以完全掌控行列顺序、间距和原点位置后面要调3D网格也方便。这里有一个每个Niagara开发者都该理解的属性ExecIndex执行索引。每次Spawn事件产生一批粒子时Niagara会给当前脚本里正在初始化的粒子分配一个序号从0开始往上递增。这个序号和粒子后来的ID不完全一样但在初始化阶段它就是我们需要的“第几个粒子”的编号。有了ExecIndex坐标计算就变成一个纯粹的数学映射。假设我要生成64x64的网格间距为10那么第n个粒子的行列位置可以这样推导列号 n % 64行号 floor(n / 64)坐标x 列号 * 10坐标y 行号 * 10。在Niagara模块里新建一个Custom HLSL模块输入类型选择Spawn然后在更新位置部分写上void Main() { float idx ExecIndex; float gridW GridWidth; float gridH GridHeight; float spacing Spacing; float gx fmod(idx, gridW); float gy floor(idx / gridW); Position float3(gx * spacing, gy * spacing, 0.0); }其中GridWidth、GridHeight、Spacing三个值建议提升为用户参数User Parameter这样在Niagara系统的细节面板里可以直接调节不用每次改代码。发射器Spawn模块里把Spawn Burst Instantaneous的Spawn Count设为GridWidth * GridHeight也就是4096。这一步最容易出问题粒子数小于网格数会出现空点粒子数大于网格数后面的粒子会和前面的粒子坐标重叠看起来像某些格点上堆了两三个粒子。所以一定要让粒子总数等于宽乘高。如果你的风场要做成3D体网格比如展示山谷中不同高度的风向差异只需要把坐标扩展到三维void Main() { float idx ExecIndex; float gridW GridWidth; float gridH GridHeight; float gridD GridDepth; float spacing Spacing; float gx fmod(idx, gridW); float gy fmod(floor(idx / gridW), gridH); float gz floor(idx / (gridW * gridH)); Position float3(gx * spacing, gy * spacing, gz * spacing); }这个方法在做一个高度方向上不同风向的流体可视化时特别好用只是粒子数会随深度线性增长建议64x64x16这种规模起步不要一上来就64x64x64那个是26万个粒子性能压力会立刻显现。2.3 粒子属性与初始化的正确姿势网格位置算完先别急着渲染。风场需要每个粒子携带“风”的数据默认粒子属性里没有现成的风速风向需要手动添加。在Niagara粒子属性面板里点击加号添加一个Vector类型的属性叫它WindVelocity再添加一个Float类型属性WindSpeed。这两个属性就像每个粒子的“随身背包”初始化的时候可以先给一个默认值比如WindVelocity (1, 0, 0)WindSpeed 1后续在Update阶段再根据噪声重新计算。属性的添加位置也有讲究。不要让初值直接在Custom HLSL里写死而是在Initialize Particle模块里通过“Set”节点设置。这样后面调试参数时不需要碰代码直接从面板调初值即可。初值本身不重要因为Update阶段会把它覆盖掉但它决定了粒子第一帧渲染时会不会出现“还没算风就已经画出来”的闪烁。记得把粒子的寿命调长一点比如100秒甚至Infinite。Grid风场是一个持续存在的静态采样点阵粒子活着就行不需要正常粒子那样出生死亡循环。寿命太短会导致网格点阵周期性消失和重建视觉上就是风场整体闪烁。3. 风数据生成与运动逻辑3.1 主风向加卷曲噪声模拟气流的最短路径风场要看着“像真的”光给所有粒子一个统一方向是没用的那又回到了WindDirectionalSource的老路。要让粒子之间产生差异但同时保持空间连续性我的做法是主风向 卷曲噪声Curl Noise叠加。主风向很好理解就是一个基准向量比如从西南吹向东北那么主风向就是(1, 1, 0)的归一化向量乘上一个基础风速。这个参数控制整个风场的大方向。问题出在细节上。如果只用Perlin噪声直接叠加在风向上会产生“散度不为零”的问题——通俗说噪声会让粒子在某些区域堆积在另一些区域被掏空风场看起来像在呼吸而不是在流动。因为这个原因我强烈建议用Curl Noise。它是从向量场构造出来的无散噪声不会产生粒子的汇聚与发散模拟出来的风有旋涡、有流动感但整体保持着流体的体积守恒。Niagara里做这件事有两条路线。一条是直接找Noise家族的Curl Noise模块节点把位置和速度送进去简单直观。另一条是用自定义HLSL里的噪声函数。如果用的是后者可以把“Noise”理解成一个示意函数实际替换成自己项目里实现了的Perlin噪声实例都行只要保证输入是空间坐标时间输出是平滑变化的标量。3.2 Update阶段的风矢量计算与参数设计Grid粒子在Update阶段要做的事情很单纯根据当前粒子的位置和全局时间算出新的WindVelocity然后存进粒子属性里。关键是Update模块的执行频率默认是每帧一次也就是每秒60次。对一个64x64的网格来说4096个粒子每帧都被调用一次GPU SIMD宽度很宽压力不大CPU模拟就吃力了这也是我坚持用GPU模拟的原因。风矢量的计算逻辑可以这样概括void Main() { float t Age * WindTimeScale; float2 uv Position.xy * NoiseFrequency; float nx SmartNoise(uv float2(t * 0.5, -t * 0.3), Seed); float ny SmartNoise(uv float2(-t * 0.2, t * 0.7), Seed * 13.7); float3 noiseVec float3(nx, ny, 0.0); WindVelocity MainWind noiseVec * NoiseStrength; WindSpeed length(WindVelocity); }这一段是风场的灵魂。NoiseFrequency控制噪声在空间上的变化频率频率越高风在空间上变化越快看起来越“碎”。实践下来风场可视化里这个值不要开太大0.02到0.1之间的低频效果最接近真实大气的流动。WindTimeScale控制风场随时间演化的速度太大就容易乱太小又显得死板我一般从0.5开始调。Seed的作用是打破每个方向噪声的对称性。如果nx和ny用的是同一个Seed很容易在空间某些区域出现对称条纹人眼看到会明显觉得“假”。加一个奇怪的Seed倍数比如13.7只是一点小技巧目的是让x和y方向的相关性降到最低。3.3 粒子留在网格上还是沿着风飘有了WindVelocity之后Grid粒子的位置策略有两种可选两种我都用过适用场景完全不同。第一种是“静态采样点模式”。粒子位置永远不动只更新WindVelocity和WindSpeed然后用材质或渲染器把方向画出来。这种方案的优点是网格永远规整画面像一个标准的科学可视化图非常适合项目汇报和展示。缺点是视觉上缺少“风在流动”的动感只能靠颜色和箭头方向间接感知。第二种是“动态追踪模式”。粒子不是静止的而是每帧沿WindVelocity方向轻微移动比如Position WindVelocity * 0.1 * DeltaTime。粒子移动后原来的规则网格会逐渐变形形成流线看起来像一束烟在风场里飘。这种模式直观但问题也很明显粒子一旦移动就不再是Grid了时间一长点阵会全部挤到某个角落。我解决这个问题的办法是不止一个发射器。一个发射器负责静态网格点专门用于计算和展示矢量另一个发射器负责“流线粒子”每隔几帧从网格点上出生顺着WindVelocity飘一两秒然后死亡这样一来Grid点阵稳定流线粒子又提供了运动感。两个发射器共享同一套风场计算逻辑数据不冲突视觉效果也丰富。这是做风场可视化时最实用的架构之一。4. 风场的可视化与渲染技巧4.1 方案一Sprite箭头风标快速看清风的方向最直观的展示方式是把每个Grid粒子渲染成一个箭头箭头的方向就是风的方向。做法并不复杂Sprite Renderer是Niagara里最常用的渲染器但默认的Sprite是四边形不会自己变成箭头。我的做法是让箭头形状在材质里完成。给材质传几个参数粒子的位置、风的方向、风速。材质里用World Position Offset把Sprite的四个顶点沿风向拉伸再通过一张箭头遮罩纹理来只显示箭头的区域。这样每个Sprite实际上是在世界空间中被拉成一个风向指示箭头的形状方向跟WindVelocity对齐。在Niagara侧只需把WindVelocity通过Particle属性传到材质。材质节点里用VectorToRadians或者直接通过计算点乘来旋转UV把拉伸后的矩形朝向跟风向匹配。实际操作中有一个容易踩的坑Sprite渲染朝向相机但拉伸方向是世界空间方向两者组合时如果不做转换箭头会在某些视角下“躺倒”。我的经验是在材质里用CameraVector和WorldPosition做一个粗略的billboard矩阵修正。如果追求简单可以先拍平到2D平面默认风场围绕X-Y平面展开箭头只在该平面方向拉伸CameraVector只负责让整个Sprite看向相机。风速要体现在箭头长度上。长度 基础长度 * (WindSpeed / MaxWindSpeed)。先设一个MaxWindSpeed作为归一化基准比如5米/秒所有风速都这个值缩放这样箭头长短就有比较意义。如果不归一化风速一旦大幅变化箭头会长到跨出好几个格点画面立刻混乱。4.2 方案二Ribbon流线追踪展示风的走势如果说Sprite箭头是“一帧快照”那Ribbon流线就是“一段视频”。它把粒子运动的轨迹用丝带画出来观众能直观看到一团气流从A点流到B点的过程。视觉效果比箭头丰富得多适合做展示和演出。我用的典型配置是这样在Grid风场系统里再挂一个发射器专门负责流线。这个发射器的Spawn Rate设置为每秒20到30次Spawn时粒子的初始位置取自对应Grid点的坐标初始速度设为该点的WindVelocity。粒子存活时间设成1.5到2秒在这段时间里粒子沿风场自然移动死亡之后留出一条弯曲的轨迹。渲染器方面把该发射器的Renderer换成Ribbon Renderer。Ribbon会把发射器里存活粒子按照生成顺序串联成条带。为了让线条颜色有意义把WindSpeed映射到粒子Color上这样风速大的地方丝带偏红偏白风速小的地方偏蓝偏暗整个风场的强弱分布一目了然。Ribbon调试中最常遇到的问题就是断线。因为Ribbon要求粒子的连接顺序稳定一旦发射中途出现粒子数突然归零或者某个粒子生命周期不一致线条就会崩开。解决办法把Ribbon发射器的粒子数控制成稳定周期别用一次性Burst也别在Update里做随机复活。如果一定要断不如直接用“拖尾粒子”方案——每个主轴粒子带一圈QuickSpawn的子粒子做成拖尾。但那是另一套玩法了本篇就不展开。4.3 颜色映射与视觉优化的参数清单风场可视化如果没有颜色只剩一堆线条和箭头信息量会大打折扣。颜色是最直观的“第三维”。我的颜色映射逻辑是把WindSpeed归一化后通过一个从蓝到青到白的三段渐变来显示。速度低时是深蓝色中速是青色高速接近白色。这个配色参考了气象可视化软件的默认色带观感干净也符合“冷色慢暖色快”的直觉。材质里用Lerp和Saturate实现即可不需要写复杂的Shader。透明度方面Sprite箭头的透明度建议设在0.5到0.8让多个层级的箭头能够叠加。Ribbon丝带可以低一点0.3到0.5就行否则多条丝带交叉时会产生明显的叠加发白。关闭Sprite的深度写入这个很重要只要粒子之间、粒子与场景物体之间一旦深度写入半透明叠加的顺序就会乱画面会出现闪烁的脏色。参数推荐值说明Sprite透明度0.5-0.8太高会遮挡场景太低看不清Ribbon透明度0.3-0.5流线交叉时减少发白深度写入关闭避免半透明排序闪烁网格间距5-20取决于场景规模和效果密度NoiseFrequency0.02-0.1越低越平滑越高越碎MaxWindSpeed5-10用于长度和颜色的归一化基准Ribbon存活时间1.5-2秒太长画面太乱太短轨迹不成形这套参数我在几个项目里实测下来效果稳定。当然具体值还得根据你的场景尺寸和视角距离微调但方向是对的。5. 进阶把Grid风场转成可查询的数据场5.1 粒子里的数据别的系统为什么读不到Grid风场做到这一步视觉上已经很像样了。但如果只是粒子在自嗨风场的数据就只能在Niagara系统内部流通。场景里的静态网格、UI材质、已经存在的布料系统都没法直接读取“这个位置的风是哪来的、往哪吹”。Niagara粒子本身的数据是“碎片化”的——每个粒子带几个属性数据跟粒子绑定其他渲染系统和游戏逻辑要拿到这些数据得通过各种接口做数据通道。对于风场这种空间数据最好的载体是纹理准确说是Grid Data Interface在Niagara里表现为Grid2D或Grid3D的Data Interface。5.2 用Grid Data Interface写一份可复用的风场Grid Data Interface可以把粒子的计算结果写入一个渲染纹理RenderTarget或结构化缓冲区然后场景里的材质、Niagara模块、蓝图都可以按位置采样。流程上分三步。第一步在Niagara系统里添加Data Interface类型选Grid3D或者Grid2D分辨率要和你的粒子网格对应。比如你的Grid是64x64那Grid的分辨率就设成64x64x1或者64x64x1深度为1就是平面。第二步在Update阶段通过Grid Data Interface的写入节点把每个粒子的GridCell索引和WindVelocity值写进去。实际写的时候要注意坐标换算粒子位置的X、Y要除以网格间距再取整才能映射到正确的格子。否则数据会整体偏移几个格子采样出来的风场会跟粒子位置错位视觉上一看就知道对不上。第三步在其他地方消费这份数据。比如给草叶材质写一个CustomNode采样Grid3D读写纹理的当前位置把采样结果作为草的摆动方向或者让另一个Niagara粒子系统通过Grid Data Interface的读取节点把风矢量作为粒子受力。这个步骤一旦打通你的风场就不再只是一个粒子特效而是一个可以被全场景复用的“风环境数据源”。我把这一步看作Grid风场从“玩具”到“工具”的转折点。前面几步做的只是好看能够写进Grid、被外部采样才算真的有工程价值。5.3 一个风场多处消费的工程收益一个场景里往往很多系统都要“感受到风”。草要摆动、树要摇晃、落叶要飞、旗帜要飘、沙尘要起。如果用传统做法每个系统都是独立调一套风力参数做着做着就会发现某个树的摇晃方向和旗帜飘的方向对不上只能手工改。有了统一的Grid风场数据源所有系统都从同一个Grid采样天然不可能出现方向不一致。而且因为Grid数据是空间连续的过渡自然不需要在材质之间同步参数。代价是数据写入和采样会增加一点GPU开销。读取Grid本身不贵贵的是每个采样点都要换算到纹理坐标。工程实践中我会把Grid的分辨率控制在64x64到128x128之间太高意义不大太低风场细节又丢失。这部分细节足够再写一整篇文章这篇先讲清思路具体节点排列和材质采样代码我后面单开一篇拆。6. 常见问题与排查实录6.1 “粒子全被拉成一条对角线”这个问题新手必遇。Grid尺寸设置和Spawn Count对不上粒子总数大于GridWidth * GridHeight多余粒子就会覆盖到已有坐标上看起来像从左上角到右下角拉出一条斜线堆积。排查时先确定Spawn Count等于GridWidth * GridHeight再把Custom HLSL里的fmod和floor逻辑在脑子里演算一遍。我调试时有个土办法在Spawn模块里临时把Position换成float3(gx, gy, 0)先不乘Spacing直接在面板里看粒子是不是铺成一个规整的方格。是方格说明索引计算没问题问题在间距或偏移不是方格说明宽高参数接反了。6.2 “风看起来特别碎像雪花掉在屏幕上”这个基本上是NoiseFrequency设得太大造成的。粒子间距比如10米但噪声频率是1那相邻两个粒子采样的噪声值几乎完全独立风矢量的方向就剧烈跳变视觉上就是乱糟糟的碎风。把NoiseFrequency降到0.05左右再试网格间距越小频率要更低。风场想要平滑噪声在空间上的波长应该大于网格间距的五倍。这个经验法则很好用。如果加了低频之后风太“整”了再叠加一个频率稍高的细节层幅度控制在主风的20%到30%即可既保留细节又不会碎。6.3 “Ribbon一直断线连不成完整的丝带”Ribbon的断线几乎都是粒子生命周期不连续导致的。Ribbon只把这些粒子当成一条连续曲线来渲染中断一次整个条带就断。常见的诱因是Ribbon发射器用了Burst发射或者粒子的存活时间波动过大比如某帧粒子多了、某帧粒子少了条带的连接顺序就会被破坏。我的建议是Ribbon发射器务必使用固定Spawn Rate不要用Burst。如果Spawn Rate控制在每帧固定值粒子数量和顺序会稳定很多。另外确认Ribbon发射器里的粒子是同一批连续生成的不是由Event Handler从其他发射器转过来的——事件生成的粒子顺序受GPU调度影响基本无法保证连续性。6.4 “粒子一多编辑器直接卡成PPT”Grid风场的粒子数量通常是4096起步配合Ribbon发射器后实际粒子数翻倍如果编辑器还开着实时预览确实会卡。先确认Simulation Target是GPU SimulationCPU模拟跑4096个每帧更新的粒子会在主线程产生明显开销。另外注意编辑器视口的预览分辨率Niagara系统的细节面板里可以调Preview Resolution调试时降到0.25或者0.5流畅度会立刻提升。还有一种情况是材质里用了过多的动态计算每个粒子渲染成半透明Sprite后要跑一遍复杂的WPO和噪声这个开销容易被忽略。把材质里的噪声贴图预烘焙成纹理比实时计算噪声便宜得多尤其是在粒子数量大的情况下。6.5 问题速查表症状可能原因处理方式粒子堆成对角斜线Spawn Count与GridWidth*Height不匹配检查数量对应关系风方向翻转Grid坐标方向与视图方向不一致检查HLSL里x和y的正负号风场整体偏移没有做网格原点偏移Position减去(GridWidth*Spacing)/2画面闪烁半透明排序问题关闭Sprite深度写入调整Sort Order风太碎NoiseFrequency过大降到0.05或更低增加空间连续性GPU负载高Grid分辨率过大先降到32x32测试再逐级提升风场静止不动忘了乘以Time或Age检查噪声输入是否包含时间维度排查这类风场问题我的总原则是先把网格本身调“静”——粒子不移动、风不更新看Grid排列是否正确再让风动起来但调“慢”——把时间系数设成0.1或更低看风的流动是否连续最后才恢复全速。分步定位比一次性看全特效靠谱得多。这套Niagara Grid风场方案我已经在几个不同的场景里反复用过从最开始纯粹做出来的“会动的箭头墙”到现在能接数据接口、能被材质采样每次扩展都用得上“规则点阵描述空间”这个底层思路。我个人体会是做这种技术方向先别急着堆节点把Grid坐标、粒子属性、数据流向这三件事想清楚后面的工作其实都是在往这个骨架上挂肉。下一篇我打算单独把Grid Data Interface的写入和采样节点展开写包括材质CustomNode怎么读、场景物体怎么用这份风场数据。如果你也在折腾Niagara风场欢迎照着这篇把第一个Grid跑起来卡住的地方基本都是那几个参数调一调就通了。