Fluvio - Fluid Dynamics for Unity

I'm happy to announce that Fluvio will support Shuriken particle collisions in Unity 4!

Currently, Fluvio operates by running the fluid solver on rigidbodies, which automatically resolve collisions. While this works, it's not very efficient and produces a lot of overhead. Every particle needs a gameobject with a ridigbody attached. Things such as complex friction and rotation get considered as well, when they don't need to be.

With Unity's support for full collision for Shuriken particles, we can skip all of this and have Fluvio affect particles directly. No hard numbers just yet, but expect a performance increase by orders of magnitude.

I hope to have some more news on this very soon!

 

Any update on the 2.2 demo version?

Could I use this to simulate a vacuum sucking up mud?

How big a performance boost is there by using Unity's 4.0 Shuriken particles?

 

Still working on the newest version of the fluid solver - this will be in the next version of Fluvio, along with a new evaluation.

This can be done, yes. You would simply apply a suction force to all of the particles.

In one word, massive. It completely bypasses the PhysX rigidbody pipeline (and collision detection system). This frees up PhysX and Unity in general to do other things. The tradeoff is that you don't get accurate collision data for every single particle, but honestly this is not needed.

I'll have more news on the new solver as it gets closer to release.

 

Alright, finally ready to post some more information about the next Fluvio update:

------------

Fluvio now uses Shuriken for particle rendering and requires Unity 3.5+. The legacy particle system is no longer supported. Shuriken world collision requires Unity 4.0+.

General

• Performance, performance, performance! Particles are no longer by default tied to game objects/rigidbodies, greatly reducing overhead.
• The old rigidbody-based system is now an optional fluid plugin.
• Rewrote the solver from the ground up!
• Introducing particle attractors! Attractors will pull nearby fluid particles to fill their volume.

API changes

• Simplified the public API
• FluidParticles are now structs, for performance reasons. This changes the API somewhat - GetParticles/SetParticles methods need to be called, similar to Unity particle systems
• Merged functionality from the particle manager component into the main fluid component
• Rewrote system for adding/removing emitters and plugins. It is now much more stable and works correctly at runtime
• Added an event system for various fluid events - EventListener component can be used for SendMessage functionality
• (Unity 4 only) All components are now in namespaces - wrapper components have been removed.

Broad phase changes

• Added a brand new broad phase structure
• Tree updates now only happen if particles have moved a certain distance, saving lots of CPU. This is configurable as "Particle Skin Width"
• (Pro only) IFluidBroadPhase interface for creating additional broad phases.

Solver changes

• Each fluid now only has one solver, instead of a solver per particle
• Fixed mathematical errors in the kernel functions, most notably the viscosity kernel
• Fluvio now uses a different pressure constant and gradient calculation (gas constant instead of speed of sound) - this helps prevent floating point rounding errors, and is more stable
• Added a minimum density property for stability reasons
• Fluid solver integrates positions and velocities directly (no more stacking fluids!)
• Removed the adaptive solver for now - it may be reintroduced at a later date

Other changes

• Exposed the underlying Shuriken particle system to the editor - now most normal Shuriken properties can be adjusted (color curves, mesh particles, sub emitters, etc.)
• All components now support multi-edit
• Default settings now have a more reasonable scale
• Added editor optimization - this will decrease the amount of fluid particles while in the editor to accommodate editor overhead
• Added common .fld file configurations for standard fluids.
• .fld files now save emitter settings, plugin settings, and Shuriken settings (if a particle renderer is present)

-----

No release date just yet, but the work has been mostly completed. I will likely send out a beta for this one to existing customers who have expressed interest in the update.

 

Hi there, i am indeed an owner of fluvio 2 standard, how would i be able to apply for a beta for this because i've just,basically, found a cool use for it, mobile based

Bouyancy of some kind like earlier mentioned would be great,i possess the bouyancy toolkit, unaware if you wish to integrate these things, but yes, very interested in this!

 

You can use the contact form at http://thinksquirrel.com/contact - make sure to include your invoice number from the Asset Store.

 

Made a video preview of version 2.2, check it out!

http://youtu.be/1LdKDRZAHoc

 

thats looking really exciting, well done!

 

Very interesting, but it looks as though some of the water particles are passing through the solid object colliders?

 

This is correct - the secondary particles are using low quality Shuriken collisions. At higher quality settings, the collision is more accurate, at a greater performance cost. I'll probably reshoot the demo at a higher quality later. Designing your scene around this helps a lot also (for example, it wouldn't be as noticeable on a rocky outcropping rather than a ledge).

Note that neither of these affect any of the simulated particles, which have full collision.

 

My results after tweaking the 3D example scene - adding secondary collision and splash effects (which are dynamic), some more art assets, scenery and some work in post to check for compatibility (color grading, DoF, etc). And yes, even some fish.







In all of these, Fluvio only takes about 1-4 ms per frame, even when interacted with.

 

Just saw this on youtube and it is looking great.
What of this will work on ios too? Do you wrote some ios shader for that (fake refraction, or dof)?

 

I have two questions before buying Fluvio.
Does Fluvio need a fixed sized space or a grid for the simulation or is it simulated locally, so that a fluid could theoretically travel through the whole scene?
Can the fluid also collide with non-convex mesh colliders?

Thanks in advance

 

I have a mobile variant of all of the unlit shaders that takes a refraction texture as input. It can either be a static texture, or you can feed it a render texture of any size if you need real-time refraction. The lit shaders aren't really a good idea for mobile, so I didn't port those, and particle shadows won't work.

The short answer - yes.

The long answer - Usually. Fluids themselves don't need a fixed grid, but the broad phase (optimizing the neighbor search) does require a grid. You can disable the broad phase. Any fluid over ~30-50 particles without any spatial partitioning will be very slow, though. The grids are local to the fluid, and you can adjust the size of the grid in the editor. Actual particle simulation/rendering can be either in local or world space, and will match your Shuriken settings.

Yep, 100% support for all colliders, including mesh and terrain colliders.

 

This is looking very interesting... do you have any other effects using this such as smoke and fire?

 

Currently I don't have a demo with smoke and fire - older versions of Fluvio had one, though. Of course, realistic smoke/fire simulation is possible.

I do have plans to release a project with more additional example scenes in the future, though.

 

That sounds good... I have a level in my game that will have a huge bonfire and I need the flames to feel realistic without eating up processing power... and the price point are not too bad... will I be able to do my effects with the standard version... will the particles work with Beast?

 

The standard edition contains all of the features found in the professional edition (the only difference is source code access), so both will be able to do fire and smoke just fine.

By using Beast I'm assuming you mean light probes. Particles are rendered using Shuriken with any material (refractive liquid shaders are included). I believe Shuriken's renderer supports light probes, so if your material supports them as well, you're set.

 

I am going to be working with global illumination... I would have to create particle materials that support light probes

 

Right - anything that uses surface shaders should support light probes out of the box, I believe.

----

Fluvio 2.2 has just been submitted to the Asset Store! It should be out soon.

Check out the full changelog here:
http://sqr.li/Z3q

 

Just a heads up that support will be delayed over the holidays while I'm out of town. Also, Fluvio 2.2 is out - go get it!

There's also a new free edition of Fluvio available:
http://u3d.as/2GH

This version has no watermark and can be used for commercial products. You can compare editions here:
http://sqr.li/Z3c

 

awsome work keep it up i love it

 

I am working on the Fluvio 2.2. I am unable to view different types of particle renderer in Fluvio Inspector. Since I want to change the fuild type to water or paint etc. Currently it was shows the bubbles. Additionally, How can I give a splash effect to the liquid? as demonstrated in the video (https://www.youtube.com/watch?v=MZHWjQKHwEY).

 

Hey Nabster,

All particle rendering is handled through Shuriken - you can change the material of the particle system in order to change the look of a fluid.
http://support.thinksquirrel.com/docs/fluvio/reference/fluidparticlerenderer.html

If you want to have the metaball effect from the paint video, you'll need to add a Fluid Effect component to your camera and use the Legacy shaders.

Please note - if you're using the Free Edition, these custom shaders are not included.

This is done through a simple script that instantiates a splash prefab when a fluid hits the ground. It listens for an OnCollisionEnter event, just like any other script. It was in the old example scene, but wasn't ported over to 2.2. I recommend reading about how collisions work in Fluvio 2.2:
http://support.thinksquirrel.com/docs/fluvio/reference/collisions.html

 

Hi!

Work absolutely good!

i have one ask: can i easy make ripple effect when player or other object enter to water with this? (with free version)

if yes how?
if no u can add script or sharders or any idea? its fine and rise realistic
i found this script
http://benbritten.com/2009/05/19/fun-with-unity/

but it use strange technique and not flexibility (with segments and plane MUST be square for realistic effect) so i keep looking for this effect....

 

Hi,

Does Fluvio 2 work / perform well on mobile (iOS + Android) ?

Also can you translate the particles in real time? I.e. if the fluid hits a point / collider, can the particle that's collider with said point, be instantly translated to another place in world space?

Cheers,

Alex

 

The "Latest News" on your website is over a year old. Is this project still under development?

Also the images on the site wouldn't load for me. It might be just me though.

 

Fluvio is optimized for mobile performance as well, and comes with mobile-specific shaders. You can edit particle positions using a GetParticles/SetParticles API, similar to Shuriken.

Fluvio wouldn't be ideal for this type of simulation (water heightmap simulation). It uses a different simulation technique, using particles.

Yep, Fluvio is still under active development. I should update the front page more often. The most recent release is version 2.2 (December).

Can you let me know what images are having problems, and I'll pass this on to my web admin? Thanks.

 

I'm currently using Unity 3.5

I want to have multiple volumes of water in a scene but it drops significantly in frame rate when I do this. Is there a way to spawn multiple volumes of fluid without sacrificing framerate? Is there a way to make already emitted fluids?

 

How many particles are you using per water volume? Also, are they all part of one fluid or multiple fluids? If you could let me know this information, as well as your target platform, that would be appreciated. Also keep in mind that you will want to test framerate in actual builds - Fluvio has an overhead in the editor.

Depending on how your scene is set up, one thing to keep in mind is that Fluvio will continue physical simulation even for particles that are off-screen. You can work around this in many different ways - if the different volumes don't need to interact with each other I usually have them as separate fluids, and enable/disable them based on my camera's location. I plan to add an option in the future to change this behavior and automatically and only simulate particles that are visible or affected by visible particles.

Currently, pre-warmed (already simulated) fluids can only be done by code, by emitting extra particles during the first frame and simulating them. This isn't ideal, so I'll add it to the to-do list. Would the following satisfy your use-case?

• A pre-warm option in the inspector (a float representing how much time a system should be simulated on awake, defaults to 0)
• A Simulate(t) method in the API that allows you to fast-forward a particle system through code more easily.

Let me know if you have any other questions or feedback.

 

I'm currently spawning 10 particles per volume and I am using multiple fluids. I'm trying to test this on the IPad 1 and still have the same framerate issues.

Basically, the volumes are randomly generated and in one scene. How many volumes may vary. The volumes of water will eventually interact with other volumes. So, I can't get rid of any particles because it follows the player.

I think the first option you mentioned might be satisfactory. Just because it would be easier for me to add as many particles as I need without having to worry about spawning them within the scene. I don't think it will fix my issue with framerate but I'll have to see. I'm currently working on a work-around to this issue. Thank you!

 

No problem =)

Another thing to look out for on mobile - make sure you're using the mobile refractive shaders (if you're using Fluvio shaders). The real-time refraction shaders are prohibitively expensive on mobile devices, especially the first generation iPad/iPhone 4. A good way to test out whether or not you're GPU bound would be to disable renderers for the fluids and see how much framerates improve.

If your volumes of water interact, you will likely want them as a single fluid - you'll get better simulation and much better memory usage that way. Alternatively, you can disable the broad phase if each fluid only has 10 particles - with so few particles, brute force neighbor search may be faster. YMMV with that one, though.

Finally, the reference manual includes a more general guide for improving Fluvio performance:
http://support.thinksquirrel.com/docs/fluvio/reference/performance.html

 

I think what's causing framerate issues is the collisions. I need to contain the liquid inside of a box so I need collision to keep it from falling out of the box. It seems to lag if I resize the particles to a larger portion. However, the scene is very large and has very large objects. Is there a safe way to scale the particles without sacrificing framerate.

 

You should be able to scale the smoothing distance of particles - make sure to increase your broad phase size (if you're using one) as well...

When you increase the smoothing distance (which increases particle size), you will need to adjust most of the physical properties like particle mass and density as well to match. Depending on how much scaling you need to do, you may be able to just scale the size of rendered particles. Note that the Fluid Rigidbody Particles component contains a parameter for collider size. This value is multiplied with the smoothing distance to determine the fluid-to-boundary collision radius.

There are many factors that affect collision performance - using rigidbody particles vs. using Shuriken for collisions, the shape of your other colliders and collider types, any FluidCollisionPlugin components or components that use collision messaging, etc. You may want to experiment with this - complex mesh colliders are more intensive than simple box/sphere/capsule colliders, for example.

Finally, you'll want to make sure the problem is actually due to collision, and not a result of having lots of particles close together. You can test this by placing a Fluid Attractor where your box would be and disabling the collider on the box. Depending on your gameplay, this might even be a viable alternative to collision.

Are you using Fluvio Pro? If so, a screenshot of the fluid profiler (Fluid Debug component) would be very useful in narrowing down any other potential issues.

Anyways, sorry for the wall of text. I hope this information helps!

 

Hi,

Do you know how many particles is the maximum for every mobile device?

 

Here are the numbers I use for a modified version of the 2D example scene for iOS, in Unity4. Note that your mileage may vary drastically depending on your timestep, what else is going on in the scene, your level geometry, and a host of other factors. But this should give you a good idea of performance levels. I don't have more exact Android numbers right now, sorry! Also remember that vsync is forced on.

Also, I plan on publishing this demo to the App Store/Google Play as soon as I get the time (and handle a few more Android resolutions).

Timestep used for examples

• dt - .033333
• max_dt - .033333

Particle counts

• Desktop (for reference): 300 particles
• Low Quality (iPhone 3GS, iPhone 4, iPad 1): 100 particles
• iPad HQ (iPhone 4S+, iPad 2+): 200 particles
• Most recent and definitely newer mobile devices should be able to handle the reference fluid at 60+ FPS

Framerates

• Desktop: 100-200+ FPS (desktop can realistically handle 600-800 particles at the high end depending on your system)
• iPhone 3GS: ~30 FPS (estimate, untested) - Slow CPU is the bottleneck
• iPhone 4: 30 FPS - Low fill-rate and fairly slow CPU
• iPad 1: 30 FPS - Same issues as iPhone 4
• iPad 2+: 60+ FPS (capped) - plenty of extra time left over in the frame as you go higher

 

Hi

What are some good fluid settings for mobile for the smoothing distance, particle mass and what not while still maintaining good performance but still maintaining a reasonable flow of water?

 

For all of the examples above, I used the default settings for physical properties.

EDIT: To elaborate a bit more... changing the physical properties can be pretty difficult if you don't have a solid understanding of how SPH works and the math behind it. Even for me, getting the 100% desired fluid can take some trial and error. The absolute best recommendation I have is to try changing one property at a time, observe how changing it in either direction affects a fluid, and go from there. Also note that every other property is affected by smoothing distance - think of it as the "size" of your particles or the "spacing" between them.

 

Hi,

nice tool. i'll need this type of effects. like liquid poring.
any possibility to make this type effects: http://www.youtube.com/watch?v=BHsqKvalpvU

thanks replay me

 

This type of effect can easily be done in Fluvio - it just requires changing the colors (and maybe the properties slightly) of a liquid as you pour it into another container.

 

Heya,

Awesome work you have. I have a question. Is there a way to completely destroy these Fluvio Shuriken particles once they enter some trigger area. I've tried the FluidDestructor component, but it seems that the particles only pass through them as I observed in the 2D example scene.

Thanks!

 

Hey MissCB,

Ah, good catch! There's a regression with particle destructors causing particles to not get destroyed when on a delay. For a workaround, just set "Destruction Time" on the destructor to 0. I've logged the bug and I'll get this fixed with the next update.

 

Hi, i have bought the pro. good job !!
Do you know how to use the FluidDestructor component correctly? I found that the sub particlesystem attached is still work after the fluid particles disappeared, until lots of new fluid particles generated. So i guess FluidDestructor is not a actually destructor

 

Hey Free Compass,

Thanks for your purchase of Fluvio! I can confirm that sub-particle systems currently don't disappear when particles enter a FluidDestructor - this is a known issue and I am working on a fix.

There is also another bug related to FluidDestructors when destruction time is not set to 0 (see above post).

 

Everytime I try to launch the documentation it crashes Unity 4. So with that said how would I create a 2.5D water (already know I can limit axis, which works great) that rigidy bodies can walk through (like water basically, maybe able to adjust buoyancy somehow?). My idea is to have physics driven 2.5D water/lava in my game so it can flow and be redirected at runtime as needed by adjusting the 2.5D terrain (already done and working using a tile system).

Also is it possible for the emitter to be a rigidbody as well so it moves with the rest of the particles? Idea is to have a pool of say lava and if I dig out the blocks below it (my level is 2.5D tile grid) it would flow into the now empty space (which is does as is, but the emitter doesn't move with it).

 

Hey Krileon,

A fix is incoming for this, it's a Windows issue - for now you can go http://support.thinksquirrel.com/docs/fluvio/reference directly and it should work.

Hm, could you elaborate on this one a bit more? Is there an issue with rigidbodies moving through the fluid?

This should work, emitters can move around at runtime. You'll want to put your emitter on the same physics layer as your fluid, so that it won't collide with it.

 

Wonderful, thank you!

I just had a brain fart and I just need to put the fluid on a separate layer then remove collisions between the fluid and my character so they don't collide. I was basically wanting the fluid to not collide with my characters so they sink, but still collide with everything else.

Awesome, thank you!

This is a very cool asset. Absolutely giving 5 stars.

 

URL doesn't seam to work. Any idea how I can get the fluid from "jumping" when it spawns in? I kind of want it to just fall from its spawn point directly without force. I tried setting the spawn force to 0 and it still jumps a bit when a new particle spawns.

Edit: fixed URL http://support.thinksquirrel.com/docs/fluvio/reference/

Also is it possible to change the size of the XY width of the box on the Z axis? It doesn't entirely fit the full width of my tile blocks. Not a major issue as I can just move it towards the camera some, but just curious.

 

Ah - glad I could help get you on the right track!

Thanks!

Whoops, fixed that in the link above.

Do you mean adding a "depth" to the 2D simulation? Unfortunately, that wouldn't be possible. 2D fluids don't have any concept of depth or Z in their calculations, and introducing this would negate the main purpose for having 2D particles - performance.

You could do a 3D simulation instead, and just clamp the Z axis to a minimum and maximum after the simulation (check out Fluid.OnPostSolve, Fluid.GetParticles and Fluid.SetParticles in the API reference). However, you lose out on performance by doing that. Camera tricks may be a better solution in your case.

 

Ah, nevermind; I understand what's going on better now, thank you!

Been playing with this for like the past 2 hours and it's absolutely awesome. I love the effect it gives to my game. In my game it's tile based so I can destroy blocks and cause the fluid to flow around and it's just absolutely awesome.

I hate to keep slamming you with questions, but I have another lol. Is there a way to make it more receptive to light? I've tried the vertex light and multiply, but they're way too dark. Even if light is placed directly behind it. I can't use the other shaders, because then in the dark it glows really bright; but I only want it visible in the light.

Also any idea how to prevent the particles from flying into the air and all over the place when they spawn? I set force multiplier to 0 and changed interactive force to 0 for all axis. Looks like I can change the max velocity and dampening to help with this, but it still "pops" pretty bad on initial spawn.

Edit: Got rid of the "pop" by making it spawn 1 particle per emission; works fine now!