Unity流体模拟实战：Obi Fluid插件源码分析与调参指南

简介：针对Unity3D流体特效开发的Obi Fluid插件可运行源码包，面向初、中级开发者，基于粒子技术模拟液体流动、碰撞、粘稠度等物理特性，并支持通过可视化编辑器与脚本API进行参数调节和交互控制，可应用于水、烟雾、火焰等动态场景。压缩包共6个文件，以html、js、json、md等类型为主，其中js文件承载核心流体模拟逻辑，json用于配置项目参数，md为教程说明，整体体积仅11KB，轻量易部署，便于直接运行与改造学习。目前已有88人学习，适合刚接触粒子系统或希望在Unity3D中快速搭建流体效果的开发者。配套内容涵盖了从粒子基础、物理属性设置到性能优化与项目调试的完整路径，同时提供拓展学习方向与社区交流指引，能够帮助使用者理解实现原理并获得可落地的源码参考。 第一次在 Unity 里做水体表现时，我花了将近两周手动调顶点波动算法，结果播放起来还是一块抖动的果冻。后来换用 Obi Fluid 插件，当天晚上就把可运行源码里的熔岩示例改成了"液体倒入水池"，效率高、效果好，而且上手难度比想象中低不少。这篇教程从源码可运行的角度，聊清楚三件事：这个插件的工程结构怎么读、参数怎么调出好看的效果、以及搬进自己项目时最容易踩的坑。适合正打算用流体做水、岩浆、黏液、血液等玩法规格的开发者，也适合想读懂 Obi 源码、之后做二次开发的人。

1. 选型回顾：为什么流体方案最后还是选了 Obi Fluid

1.1 先搞清楚流体模拟在游戏里到底贵在哪里

游戏里的流体模拟，最核心的成本不在于"看起来像水"，而在于每一帧都要计算粒子与粒子之间的相互作用。如果只是美术层面想表现水面波光，用顶点动画和法线贴图完全够用；但真要达到"液体能倒出来、能装进杯子、能跟物体碰撞、能溅开"这种玩法规格时，就必须引入粒子级的物理模拟。Unity 自带的粒子系统只能做视觉点阵，做不出不可压缩流体那种相互推挤的真实感。

Obi Fluid 的核心是一套 SPH（Smoothed 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 从空场景重建一套最小流体

不想直接用示例场景的话，从一个空场景重建最小流程也非常快，步骤如下：

1. 新建空物体，挂上 ObiSolver，把重力方向设为 -Y。
2. 新建一个发射器形状物体，挂上 ObiEmitter，将 Solver 字段拖到空物体的 ObiSolver 上。
3. 在发射器周围放几面墙或水槽模型，给它们挂上 ObiCollider。
4. 新建空物体，挂上 ObiFluidRenderer，绑定相机和 Solver。
5. 按下 Play，粒子会从发射器落下来，落到水槽里堆积成流体。

// 代码创建发射器的常见写法，以你下载的源码版本 API 为准 var emitter = go.AddComponent<ObiEmitter>(); 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 参数速查表：先跑通再谈效果

流体的观赏性来自粒子数量、发射速度、粒子尺寸、渲染后的表面融合效果。下面这张是我测试时反复使用的参数对照表，可以直接照抄。

3.2 一组我实测稳妥的"水"参数实验

直接分享一套我在可运行源码上跑过且观感不错的组合：emissionRate=200，speed=4，size=0.08，lifetime=3，densityRest=1000，viscosity=0.6，surfaceTension=0.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 典型报错与快速修复表

过容器时最容易忽略的是碰撞体厚度。Obi 粒子的碰撞判定基于碰撞体表面，如果容器壁太薄，高速粒子容易一帧内穿过。给碰撞体加一层厚度，或者提高 Substeps，都比反复调粒子速度省心。

5. 从源码改出自己的玩法：个人经验与扩展建议

5.1 让粒子真正参与玩法逻辑

一次射击游戏关卡里，我需要做"血液注入容器后逐渐变色"的机制。Obi 源码里最好用的地方是粒子的颜色字段支持运行时动态写入。我在 Emitter 的 Update 里按"容器内粒子存活数量除以容量上限"计算出血液占比，再动态修改容器内流体的颜色光照强度。这一步让流体真正成了玩法系统的反馈工具，而不只是背景特效。

实现思路并不复杂：拿到 Solver 当前的粒子组，遍历活性粒子数量，映射到 0 到 1 的进度值，再把它转成颜色插值和 UI 进度条。源码里粒子数据是打包在内存连续缓冲区里的，直接改粒子颜色数组比逐物体操作高效得多。

5.2 二次开发时先从粒子数据下手

如果你也想改源码做出自己的效果，我建议从这三处入手：

1. Emitter 的发射方向和速度曲线，用来做喷泉、瀑布、摆动水柱。
2. Solver 的重力向量改成自定义值，配合力场节点做吸引或排斥。
3. 重写 RenderMaterial 的混合方式，做荧光流体或岩浆自发光。

个人经验是：不要一上来就改核心 Constraints 代码。先改粒子数据，比如位置、颜色、速度，这类改动就能实现大部分玩法需求。改约束求解器意味着你完全理解了底层物理，这更适合在熟悉整套代码之后再尝试。动 Constraints 之前记得把 Solver 的更新流程完整读一遍，否则一个参数的改变可能会让整个流体系统崩溃。

5.3 一个帮我节省大量时间的模板技巧

多项目共用一个流体场景模板。我通常会在可运行源码的示例场景里保存一份调好参的 BaseScene，里面放好相机设置、灯光、后处理和默认的 Solver 配置。新项目要接流体时，把 BaseScene 里的物体整体复制过去，只需要重新拖拽 Solver 和 Renderer 的引用。别在新工程里从零搭一遍流体场景，省下来的时间足够你把粒子效果再打磨两轮。

比如最近这个液体倒进杯子的项目，我就是在 BaseScene 模板上改的颜色和发射速度，从复制到跑通不到半小时。源码里的默认参数对大多数场景来说已经是合理底子，关键是在这个底子上找到自己的参数组合，然后把它固化成模板，后续项目直接复用。

Obi Fluid 这套插件给我最大的启示是：工具的上限取决于你对源码下层的理解程度。跑通 Demo 只是第一步，真正有价值的是搞懂 Solver 怎么管理粒子、Emitter 怎么决定粒子行为、Renderer 怎么把数据变成画面。拿着这套东西去做玩法原型的效率，远比自己从零写一套求解器高得多。

本文还有配套的精品资源，点击获取