Add real-time fluid simulation

[NHodgesVFX]

Describe the project you are working on

3rd person platformer thingy / realtime vfx for portfolio

Describe the problem or limitation you are having in your project

Currently it is possible to fake fluid using traditional techniques but other engines are rapidly advancing Realtime simulations as well. Would be great to have it available in Godot as well

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Realtime fluid simulation is not impractical for games on modern high-end hardware provided the scale of the effect is limited. It would not be possible to simulate a whole ocean or lake for example but its reasonable to simulate splashing, pouring effects, filling a small tub of water, or even using this simulation to advect particles.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

Liquid:
Compute shaders (GPU) are the way to go when doing this. You can also do it cpu side but this really restricts particle counts and visual fidelity. SPH or PBF seems to be the most popular fluid simulation method although I have seen FLIP once as well.

Although 3d is only available to high-end platforms 2d simulation can be done on low/medium end platforms. for 2d see pixeljunk shooter ultimate

I mentioned this to reduz about adding sph or pbf to the particle simulator in godot 4 but he preferred it being its own node. Im fine with it being its own node as well. Godot 4 particles and SDF collisions have gotten us halfway to a liquid simulator already now all that needs to be done is SPH/PBF and rendering it.

Smoke:
Smoke has a really cool advantage in that it can be used at a very low resolution to advect particles or can be done in 2d to save compute costs. When used at a low res or in 2d smoke can be used even on low-end platforms like mobile. Smoke can also be done in 3d at a low-res then upscaled with noise for better performance. Smoke simulators tend to be a grid or voxel based

Both can work in 2d but smoke can be simulated in 2d with extra passes to make it look 3D so that it can be used convincingly in a 3d world https://twitter.com/TheMirzaBeig/status/1341897921831305217 (This one was baked to a texture first, more to show the rendering concept)

Some examples
In the browser
Some of these run slow because they are cpu based in a browser native gpu is much faster.

https://experiments.withgoogle.com/search?q=fluid
https://paveldogreat.github.io/WebGL-Fluid-Simulation/
https://haxiomic.github.io/GPU-Fluid-Experiments/html5/
https://magnum.graphics/showcase/fluidsimulation2d/
https://magnum.graphics/showcase/fluidsimulation3d/

Liquid:
https://wickedengine.net/2018/05/21/scalabe-gpu-fluid-simulation/
https://www.youtube.com/watch?v=GoD2ZC8-Wqk
Nvidia FLEX (C++, UE4, Unity, and 3rd party godot support by @AndreaCatania but its not not maintained/ Cant find the repo anymore?)

https://assetstore.unity.com/packages/tools/physics/obi-fluid-63067
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.443.6926&rep=rep1&type=pdf
http://developer.download.nvidia.com/presentations/2010/gdc/Direct3D_Effects.pdf
https://www.gdcvault.com/play/1012447/Go-With-the-Flow-Fluid
https://www.gamasutra.com/blogs/RobWare/20151026/257309/Optimising_PixelJunk_Shooter_and_giving_it_the_Ultimate_look.php
Smoke:
https://www.unrealengine.com/marketplace/en-US/product/fluidninja-vfx-tools
https://play.google.com/store/apps/details?id=games.paveldogreat.fluidsimfree&hl=en_US&gl=US
http://graphics.cs.cmu.edu/nsp/course/15-464/Spring11/papers/StamFluidforGames.pdf
https://developer.nvidia.com/nvidia-flow

If this enhancement will not be used often, can it be worked around with a few lines of script?

No

Is there a reason why this should be core and not an add-on in the asset library?

Probably not this most likely will require modifying the engine is someway. There might be enough of the render pipeline exposed that it could be an addon though.

[Calinou]

I'm not convinced of the usefulness of real-time fluid simulation in a game, except in niche/experimental games (remember Hydrophobia?). This makes it third-party territory to me.

As for baked fluid simulation (e.g. Alembic), this makes more sense but it's really tailored to high-end hardware. It would be something for a Godot 4.x release, not 4.0.

Smoke has a really cool advantage in that it can be used at a very low resolution to advect particles or can be done in 2d to save compute costs. When used at a low res or in 2d smoke can be used even on low-end platforms like mobile. Smoke can also be done in 3d at a low-res then upscaled with noise for better performance. Smoke simulators tend to be a grid or voxel based

You can already use particle collision to achieve smoke that collides with surfaces. In fact, people have even managed to do this in Godot 3.x using RigidBodies/KinematicBodies. It can be made to look convincing enough for a game 🙂

[NHodgesVFX]

For baked fluid for games alembic is inefficient its better to use something like Houdini's VAT, I almost have it working but cant seem to solve an issue with normals.

Never seen hydrophobia before but now I want to play it. Its true that its niche just like raytracing is but more games are supporting raytracing more games will use realtime fluid sim in games as the ecosystem allows. UE4 previouly had flex but just recently it added the ability's to do real time fluid sim in Niagara and other similar effects.

I wouldn't be opposed to this being an addon its just the relevant features from the engine need to be exsposed.

Some games have used fluid sim for small effects.
Borderlands 2 using PhysX
Batman Games also using PhysX
Killing Floor 2 also uing physx

[alexfreyre]

Hopefully alambic will be compatible because for example creating an airborne flag or a pre-baked fluid simulation is currently impossible and a necessary feature in 3d.

I totally agree with this PR, while Godot 4.0 comes amazing and without brakes, it is missing a lot of features that other engines have. While time, money and consequently number of developers speed up or slow down development, sensible decisions are the most important about whether they are useful for the majority or not, it is the reality.

But, until "x" feature is not supported, that missing is a creative limitation, also people find the use of something that already exists.

I'm not convinced of the usefulness of real-time fluid simulation in a game, except in niche / experimental games

@Calinou I have two ideas to share with you about your previous one

1. Godot may have been founded with the idea of ​​making video games, but the community's use of it may extend to other fields. Currently there are many multidisciplinary approaches of many careers that make use of video game engines to create many products, Godot for me is not a video game engine, it is a very complete tool to generate interactive multimedia applications in real time in 2D and 3D (hopefully in hologram in the future or that the images / experiences are created in the brain directly;)). For example I use Godot to make art not games.

2. I make art for other people not for me, it makes sense that I do it for you for example. On the other hand, I believe that developers do not program for themselves, they program for others to use their software. Therefore if Godot users feel the need to incorporate something like this PR it is because they find Godot better than the other engines and they want to work on it, but they need something that exists in another.

I consider that the idea of ​​this PR is that somehow we get up to date in relation to the characteristics present in another.

Fluid simulations in real time is honestly not immediately necessary as for example antialiasing for SSR. But as much simulation of fluids in real time, as destruction of meshes in real time, as hair in real time with TressFX or something similar is necessary too (to mention some characteristics) it is true that they will not be used by everyone or every day, but The day they are missing for me is too annoying to close Godot and open Unreal (and also have Unreal stored on disk for this eventual reason).

There must be people who share the same feeling as me, who feel so much empathy and so happy in this community and working with Godot that they don't want to use another engine.

[Calinou]

Godot may have been founded with the idea of ​​making video games, but the community's use of it may extend to other fields. Currently there are many multidisciplinary approaches of many careers that make use of video game engines to create many products, Godot for me is not a video game engine, it is a very complete tool to generate interactive multimedia applications in real time in 2D and 3D (hopefully in hologram in the future or that the images / experiences are created in the brain directly;)). For example I use Godot to make art not games.

Yes, but games will always remain the primary target of Godot's development. We don't intend to bloat Godot for the sake of secondary fields. Again, this feature can likely be provided as a C++ module or GDNative add-on to those who need it.

[yosoyfreeman]

I think a real time fluid simulation is taking the concept to far. With the last improvements on the particles system, it should be possible archive some kind of decent simulation. Maybe a few values on the particles to controll a meta-ball system can make the trick.

In unreal, lots of this things are made with particles and meta-balls (or other more complex shaders that i not understand). Plus, this system is useful to other kinds of artistic results like smoke, not only water.

[Chaosus]

I do agree that it should be an addon, but I think the Engine should provide a way to make such effects for the experienced users from scratch (and without instancing RenderingDevice?). That's returning us to the idea of the usage of the compute shader or the subset of that part of the pipeline.

[augus1990]

I think that 2D sph should be available on Godot at least. It would save time for the developers who are trying to develop similar animations for games related to water like pirates, sandboxes, simulators and others, and some effects like the wheather, blood and monsters and powers based in liquids. I think that the players don't need a powerful hardware to run 2D sph animations.

PS: there are few 2D pysics engine for web games that support SPH.

[SIsilicon]

Stuff like that can be integrated with what Godot already offers (MultimeshInstance, C#, GDNative, modules).
Infact, I even made an SPH demo with pure GDScript.

Obviously it's not the most performant implementation as it was a long time ago, but it shows that Godot's capable of custom physics effects like these with a little bit of effort.

[NHodgesVFX]

A CPU based implementation wont be super fast, you really wont be able to get a good amount of particles. Compute shaders are the way to go for this. Godot 4 does include compute shaders so I assume it can be used for this but there's no documentation around them yet.

For reference look at obifluid which is cpu based, written in c/c++ and multithreaded you can only get around 6000 particles. Their unoptimized alpha compute version was able to handle 60,000 particles on a Radeon FirePro D300 2GB. So an rtx 3060 could probably handle 100,000 or more easily.

[SIsilicon]

That could still be implemented with GDNative or C#. Those two can be used as an interface to openCL or even computer shader api, even in 3.2.

[NHodgesVFX]

yeah but you would need to include your own opengl library pretty sure Godot opengl es version doesn't support compute shaders. Although I'm not entirely sure what version we use so it might. In 4.0 you can use compute from gdscript. As for including it natively yeah I can see it makes more sense as a addon.

edit: oh you also mention opencl although wouldnt that be a bottleneck dont you have to go opencl -> cpu -> opengl

[SIsilicon]

Opengl 4.3 I believe is the earliest version that supports compute shaders, so I doubt opengl in Godot 4.0 will do the job, which would mean that a CPU implementation would still be needed as a form of fallback.

[NHodgesVFX]

godot 4 uses vulkan which supports compute shaders, the opengl renderer in godot 4 is for low end so i dont think you would want fluid sim their anyway

[SIsilicon]

Believe it or not, I would. Where's my water for example uses fluid simulations, and I don't think they require you to have a mid-end graphics card to run.

[NHodgesVFX]

opengl es 3.1 does support compute https://developer.arm.com/solutions/graphics-and-gaming/resources/demos/compute-shaders-flag so theres hope on that front as well

[SIsilicon]

Yes, but Godot currently is using openGL ES 3.0 so I don't think so.

[NHodgesVFX]

Yes, but Godot currently is using openGL ES 3.0 so I don't think so.

theres still hope, maybe 3.0 has a extension that could be used

Believe it or not, I would. Where's my water for example uses fluid simulations, and I don't think they require you to have a mid-end graphics card to run.

I think they use ridgid bodys to fake it

[SIsilicon]

I read that they actually use SPH to simulate it. I'll read back again just in case.

[NHodgesVFX]

if you find it post it please, sounds like a interesting read

[SIsilicon]

Well I can't seem to find it right now. I think I saw it in a paper about SPH while researching it. Either way though, having a CPU implementation fallback would still be a good idea; like how we have CPU particles and GPU particles. 6000 water particles would be more than enough for most game applications. Take Algodoo for instance (technically not a game).

[NHodgesVFX]

I looked at a Algodoo interesting sandbox. I wonder if you could simulate sph in a shader in gd3 using a fragment shader by using multiple viewport textures.

[SIsilicon]

It could be, but the viewport textures must first be able to support 32-bit render targets. It's currently limited to 8-bit and 16-bit (HDR) at the moment.

[Calinou]

It could be, but the viewport textures must first be able to support 32-bit render targets. It's currently limited to 8-bit and 16-bit (HDR) at the moment.

See #2935. You could also use color packing as an alternative.

[Lauson1ex]

I wonder if you could simulate sph in a shader in gd3 using a fragment shader by using multiple viewport textures.

That's the way we've been doing realtime GPU simulations in the industry for the last two decades; compute support on console platforms is fairly recent. Viewports are buffers of data which shaders can output to/receive input from, even on compute. In fact, Godot's GPU particles are just a vertex feedback-loop shader.

That being said, vertex and fragment programs are suitable for realtime fluid and cloth simulation. If you perform sampling and calculations on the vertex program, and then use fragment for output, it's very efficient. It's not that hard.

In fact, people have been doing 3D realtime cloth and fluid simulations in Godot using shaders since forever:
Godot - Ocean Shader - Foam, Hue Tinting
Godot - Fluid Simulation Shader <- (this one uses PR #51708 for 32-bit render targets)
Godot Engine - GPU Assisted Cloth Progress Update
Dynamic Water Web Demo (GLES2)

[demolen]

See godotengine/godot#12680
Something similar has been requested before but closed. a Navier-Stokes Solution opens many doors.