简介针对Unity3D流体特效开发的Obi Fluid插件可运行源码包面向初、中级开发者基于粒子技术模拟液体流动、碰撞、粘稠度等物理特性并支持通过可视化编辑器与脚本API进行参数调节和交互控制可应用于水、烟雾、火焰等动态场景。压缩包共6个文件以html、js、json、md等类型为主其中js文件承载核心流体模拟逻辑json用于配置项目参数md为教程说明整体体积仅11KB轻量易部署便于直接运行与改造学习。目前已有88人学习适合刚接触粒子系统或希望在Unity3D中快速搭建流体效果的开发者。配套内容涵盖了从粒子基础、物理属性设置到性能优化与项目调试的完整路径同时提供拓展学习方向与社区交流指引能够帮助使用者理解实现原理并获得可落地的源码参考。 第一次在 Unity 里做水体表现时我花了将近两周手动调顶点波动算法结果播放起来还是一块抖动的果冻。后来换用 Obi Fluid 插件当天晚上就把可运行源码里的熔岩示例改成了液体倒入水池效率高、效果好而且上手难度比想象中低不少。这篇教程从源码可运行的角度聊清楚三件事这个插件的工程结构怎么读、参数怎么调出好看的效果、以及搬进自己项目时最容易踩的坑。适合正打算用流体做水、岩浆、黏液、血液等玩法规格的开发者也适合想读懂 Obi 源码、之后做二次开发的人。1. 选型回顾为什么流体方案最后还是选了 Obi Fluid1.1 先搞清楚流体模拟在游戏里到底贵在哪里游戏里的流体模拟最核心的成本不在于看起来像水而在于每一帧都要计算粒子与粒子之间的相互作用。如果只是美术层面想表现水面波光用顶点动画和法线贴图完全够用但真要达到液体能倒出来、能装进杯子、能跟物体碰撞、能溅开这种玩法规格时就必须引入粒子级的物理模拟。Unity 自带的粒子系统只能做视觉点阵做不出不可压缩流体那种相互推挤的真实感。Obi Fluid 的核心是一套 SPHSmoothed Particle Hydrodynamics光滑粒子流体动力学求解器。它把最重的底层计算封装在 Compute Shader 和 Jobs 系统里开放给使用者的主要是 Emitter、Solver、Renderer 这几类组件上的参数。我当时对比过自写 SPH 和另外几款流体插件最终选定它的理由很朴素源码可控、场景即改即跑、换一个新环境出效果快。对做玩法的团队来说这套东西能直接从技术预研跨到可玩原型省掉大量底层开发时间。1.2 SPH 的核心机制用大白话讲一次SPH 的基本思路是流体被离散成大量圆形粒子或球形粒子每个粒子携带密度、压力、速度等属性。每帧遍历相邻粒子根据它们的相对位置和速度计算三种力——压力让粒子在被压缩时互相推开粘度让粒子之间有拉扯感表面张力让液滴边缘收缩成圆形。可以把它理解成一群人挤在地铁里太挤的时候会被推出去大家朝同一方向走时会互相拽住最外围的人会被拉住不至于散得到处都是。这个模型做出来的流体对交互输入特别敏感。你用鼠标搅动或者让物体掉进液体里粒子都会按真实物理解算给出反馈所以它天然适合做玩法向的液体效果而不是只当一个背景特效。1.3 适合与不适合的边界Obi Fluid 也有明显的能力边界。它适合小范围流体场景、卡通风格液体、玩法原型验证但不适合用来做电影级大规模海面也不适合在低端移动设备上跑几万粒子。如果你需要的是整个屏幕都是水的关卡或者必须支持五年前的老手机那么就得在粒子总量和渲染开销上做很大让步。我自己的判断标准是单场景稳定粒子数需求在 5 万以内时Obi Fluid 是可用的超过这个量就要考虑是否对玩法设计做减法。2. 可运行源码的工程结构跑起来之后该怎么读代码2.1 拿到源码后先打开哪个场景最见效拿到可运行源码后我建议先别急着看代码先把演示场景打开跑一遍。通常场景名类似 BasicFluid 或 FluidSample进入后你会看到三个核心物体Solver、Emitter、FluidRenderer。理解这三个物体的关系是读懂源码的关键。ObiSolver挂在空物体上相当于整个流体世界的物理引擎容器。所有粒子都存储在它的缓冲区中所有约束都在这里被统一计算。ObiEmitter挂在发射器物体上定义粒子从哪里生成、以什么大小、速度和速率生成。ObiFluidRenderer渲染器对象把 Solver 缓冲区里的粒子数据渲染成流体表面同时负责相机和渲染队列的衔接。代码层面推荐按这个顺序阅读先看 ObiSolver 的初始化和更新逻辑理解一次解算的完整流程再看 ObiEmitter 的发射和粒子初始化然后用 ObiFluidRenderer 理解流体怎么从粒子变成画面最后回头研究 Constraints 相关代码看压力和粘度约束是如何挂到粒子上的。2.2 从空场景重建一套最小流体不想直接用示例场景的话从一个空场景重建最小流程也非常快步骤如下新建空物体挂上 ObiSolver把重力方向设为 -Y。新建一个发射器形状物体挂上 ObiEmitter将 Solver 字段拖到空物体的 ObiSolver 上。在发射器周围放几面墙或水槽模型给它们挂上 ObiCollider。新建空物体挂上 ObiFluidRenderer绑定相机和 Solver。按下 Play粒子会从发射器落下来落到水槽里堆积成流体。// 代码创建发射器的常见写法以你下载的源码版本 API 为准 var emitter go.AddComponentObiEmitter(); emitter.solver solver; // 绑定解算器 emitter.emissionRate 150f; // 每秒发射粒子数 emitter.speed 4f; // 初始发射速度 emitter.lifetime 3f; // 粒子存活时间 emitter.size 0.08f; // 粒子半径 emitter.densityRest 1000f; // 静止密度水通常接近 1000 emitter.viscosity 0.8f; // 粘度 emitter.surfaceTension 0.15f; // 表面张力这段代码看起来琐碎但揭示了 Obi 的设计思想物理参数被平铺在组件上没有藏在难找的子模块里。对初学者是极大的友好对后期调优则是所见即所得。2.3 读源码前需要接受的版本现实Obi Fluid 不同版本之间的 API 变动不小。有些版本用emitter.speed有些版本改用 Velocity 相关字段渲染器的挂载方式也有差异。本文示例代码以可运行源码的实际版本为准遇到编译报错先看更新日志和 Scripting Define不要急着改业务代码。读源码时尤其要注意版本号因为网上很多教程基于老版本照搬会踩不少坑。3. 调参实战如何把能跑变成好看3.1 参数速查表先跑通再谈效果流体的观赏性来自粒子数量、发射速度、粒子尺寸、渲染后的表面融合效果。下面这张是我测试时反复使用的参数对照表可以直接照抄。参数作用常用起步值emissionRate每秒发射粒子数决定水流粗细100-300speed发射速度决定流体喷出远近2-8size粒子半径决定视觉颗粒感和性能0.05-0.15lifetime存活时间决定液体能堆积多久1-5densityRest静止密度决定粒子团抱紧程度500-1500pressureStiffness压力刚度决定流体不可压缩感0.5-1viscosity粘度决定流动阻力0.2-2 水surfaceTension表面张力决定液滴收缩强度0-0.23.2 一组我实测稳妥的水参数实验直接分享一套我在可运行源码上跑过且观感不错的组合emissionRate200speed4size0.08lifetime3densityRest1000viscosity0.6surfaceTension0.05。这套参数下粒子落到容器后能明显看到溅起—回落—平缓三个阶段视觉密度足够不会有明显颗粒感。如果你想做岩浆或胶质把 viscosity 拉到 3 以上、surfaceTension 提到 0.2 左右再把 speed 调低流体立刻从水变成粘稠液体。岩浆如果想有发光效果还需要配合渲染材质做自发光和后期 Bloom后面会讲到。3.3 调参最容易忽略的坑粒子尺寸与发射速率的比例关系很多人以为粒子数量越多越密越好但实际上一味加大 emissionRate 而不同步缩小 size你会得到一片泡沫板而不是液体。原因是 SPH 流体的不可压缩性依赖粒子间重叠密度粒子半径过大时粒子之间的空隙被渲染阶段强行补全视觉上就会发胀、发浮。正确做法是固定粒子尺寸后用发射速率乘以存活时间估算稳定状态的粒子总数再判断渲染密度是否达标。估算公式稳定粒子总数约等于 emissionRate × lifetime。比如上面那组参数200 乘 3 是 600 个粒子配合 0.08 的粒子半径在小容器场景里已经足够。想要更细腻的水柱把 size 降到 0.04、emissionRate 提到 500视觉确实细腻很多但性能压力也会翻倍这个账要自己算清楚。3.4 观察调参结果的小技巧调参时不要只盯着 Game 视图建议把 Scene 视图切到 Shaded 模式看粒子的线框或网格形态这样能更清楚看到粒子之间的堆叠情况。我习惯在 Solver 的调试信息面板里打开粒子数显示随时查看实时粒子总量。粒子数突然归零往往不是渲染问题而是 lifetime 太短导致粒子提前全部死亡。4. 从 Demo 到正式项目管线兼容、碰撞与故障排查4.1 URP 项目里的兼容性处理可运行源码大多是按内置渲染管线配置的。把场景搬到 URP 项目后最典型的表现是流体变成一团黑块或者完全不可见。我的排查路径通常是先确认渲染材质有没有通过 URP 升级器自动修复如果没有打开 Universal Render Pipeline Asset把 Depth Texture 设为 On再关闭相机的 MSAA。Obi 的流体渲染本质是先把粒子渲染到一张临时图再作为后期叠加到主相机上所以深度读取和后处理顺序都会影响最终显示。另一个容易踩的坑是相机没有开启 HDR。流体 Shader 里如果使用了 HDR 颜色范围或依赖 Bloom 后处理颜色会显得灰暗。解决办法是开启相机 HDR或者把 RenderMaterial 的基础亮度调高否则不管怎么调粒子参数画面都是灰蒙蒙的。4.2 粒子数量上来后怎么保住帧率Obi Fluid 已经使用了 Compute Shader 和 Burst 编译但性能仍然需要开发者自己把控。结合我的经验有几点很关键单场景粒子总量控制在 3 万以内超过后优先降低 emissionRate 和 lifetime不要在粒子尺寸上偷工减料。Solver 的 Substeps 越高物理越稳但性能开销近似线性增长。我一般固定为 2除非遇到严重穿透才升到 3。ObiCollider 每帧参与碰撞尽量只给流体可能接触的物体挂不要给整个场景所有模型批量添加。用 Profiler 观察 CPU 主线程和 GPU Compute 的占用。如果出现粒子缓冲区频繁读写优先确认源码工程是否开启了 Jobs 和 Burst 相关宏。4.3 典型报错与快速修复表报错现象常见原因修复建议Compute shader not supported当前设备或平台不支持 Compute Shader换到支持 Compute 的测试环境或放弃移动端低端机型Solver not initialized 警告其他组件在 Awake 阶段读取了未初始化的 Solver调整脚本执行顺序或手动调用 solver.Initialize()流体突然消失粒子全部死亡或 lifetime 设置过短检查 emitter.lifetime降低后重新测试流体穿透容器碰撞体厚度不足或 Substeps 太低给容器挂 ObiCollider并保证 mesh 有一定的碰撞厚度过容器时最容易忽略的是碰撞体厚度。Obi 粒子的碰撞判定基于碰撞体表面如果容器壁太薄高速粒子容易一帧内穿过。给碰撞体加一层厚度或者提高 Substeps都比反复调粒子速度省心。5. 从源码改出自己的玩法个人经验与扩展建议5.1 让粒子真正参与玩法逻辑一次射击游戏关卡里我需要做血液注入容器后逐渐变色的机制。Obi 源码里最好用的地方是粒子的颜色字段支持运行时动态写入。我在 Emitter 的 Update 里按容器内粒子存活数量除以容量上限计算出血液占比再动态修改容器内流体的颜色光照强度。这一步让流体真正成了玩法系统的反馈工具而不只是背景特效。实现思路并不复杂拿到 Solver 当前的粒子组遍历活性粒子数量映射到 0 到 1 的进度值再把它转成颜色插值和 UI 进度条。源码里粒子数据是打包在内存连续缓冲区里的直接改粒子颜色数组比逐物体操作高效得多。5.2 二次开发时先从粒子数据下手如果你也想改源码做出自己的效果我建议从这三处入手Emitter 的发射方向和速度曲线用来做喷泉、瀑布、摆动水柱。Solver 的重力向量改成自定义值配合力场节点做吸引或排斥。重写 RenderMaterial 的混合方式做荧光流体或岩浆自发光。个人经验是不要一上来就改核心 Constraints 代码。先改粒子数据比如位置、颜色、速度这类改动就能实现大部分玩法需求。改约束求解器意味着你完全理解了底层物理这更适合在熟悉整套代码之后再尝试。动 Constraints 之前记得把 Solver 的更新流程完整读一遍否则一个参数的改变可能会让整个流体系统崩溃。5.3 一个帮我节省大量时间的模板技巧多项目共用一个流体场景模板。我通常会在可运行源码的示例场景里保存一份调好参的 BaseScene里面放好相机设置、灯光、后处理和默认的 Solver 配置。新项目要接流体时把 BaseScene 里的物体整体复制过去只需要重新拖拽 Solver 和 Renderer 的引用。别在新工程里从零搭一遍流体场景省下来的时间足够你把粒子效果再打磨两轮。比如最近这个液体倒进杯子的项目我就是在 BaseScene 模板上改的颜色和发射速度从复制到跑通不到半小时。源码里的默认参数对大多数场景来说已经是合理底子关键是在这个底子上找到自己的参数组合然后把它固化成模板后续项目直接复用。Obi Fluid 这套插件给我最大的启示是工具的上限取决于你对源码下层的理解程度。跑通 Demo 只是第一步真正有价值的是搞懂 Solver 怎么管理粒子、Emitter 怎么决定粒子行为、Renderer 怎么把数据变成画面。拿着这套东西去做玩法原型的效率远比自己从零写一套求解器高得多。本文还有配套的精品资源点击获取
