I'm going to write a few shorts threads for those who are starting in the wonderful world of simulation stages in #ue5#niagara. The ultimate goal is code a (simple) fluid solver in 2D/3D that allow us, for example, driving particles by fluid simulation in a similar way as games
(2/15) like Returnal or God of War does.
(3/15) As (I hope) you know, Niagara is a highly customizable particle system framework. You can put logic on every step: when the emitter spawn, when it updates, when a particle spawn and when it updates. Furthermore, you can add new attributes to particles to play with.
(4/15) You can find examples of this (attribute creation, complex logic, etc...) in the Content Examples that Epic provides us, but for the sake of completeness I'm going to make a simple one.
(5/15) Here we have a "spiked ball". The yellow part has been built using one sprite renderer, "two" points, a custom alignment and a particle size vector. The red points show the position of the endpoints used.
(6/15) The custom alignment vector allows us to orient the sprite in the direction given by "base position" and "position". We change the pivot to scale the sprite from base position. Note that we are rendering the sprite using "base position" attribute.
(7/15) So, Niagara is a wonderful particle system editor. But what (maybe) not everybody knows is that Niagara allows us to "talk" directly to GPU. When you setup "Sim Target" in Properties as "GPUCompute Sim" you're programming (almost) literally compute shaders.
(8/15) That means a lot of parallelism and thinking in a similar way you do when you are making materials. Having said that, we are going to create our first simulation stage.
(9/15) When we run a simulation stage we need to decide "where" we want to write the data. This is called "Iteration Source". Using the material analogy: the "Iteration Source" would be the pixels of a mesh seen by a camera.
(10/15) The Iteration Source can be either the particles of the system or a "Data Interface". We are going to focus on Data Interface which, normally, is going to be a Grid2D/3D.
(11/15) A Grid2D (or 3D) is, essentially, a Render Target in which you can store any number of attributes (of different kind) in each cell (pixel). Create a Grid2D is easy: set a new parameter at Emitter Spawn and set the dimensions (with a little scratch pad).
(12/15) After that, pick your Grid2D as Data Interface in your Simulation Stage. Now you have a compute shader running through all cells of your Grid2D. Doing nothing.
(13/15) The simplest Simulation Stage is the one that assigns a single constant value for every cell in the grid. This can be done setting a new parameter in "My Stage" (a float, for example) and changing the namespace of the parameter to "Stackcontext".
(14/15) The use of "Stackcontext" namespace is optional or "transitional". Once you defined the first time, you can see that Niagara has defined a new namespace (in our case) called "Emitter | My Grid". You can reference it anytime you are working with this grid in a SG.
(15/15) This is the end of our first thread :)
• • •
Missing some Tweet in this thread? You can try to
force a refresh
In this thread we are going, finally, to implement Navier-Stokes simulation in Niagara. We should obtain something like in the gif below. #ue5#niagara#vfx#gamedev#math
Following the steps in Stam's Stable Fluids paper, let's split our original problem into smaller ones. Basically, we solve the momentum equation (apply forces, advect velocity and diffuse it) and after that we force that computed velocity to be divergence-free using the pressure.
We know how to solve (from the previous thread...more or less) all the elements of last picture, except maybe the "advection" step. Luckily, it can easily solve using a method called "Semi-Lagrangian scheme". Again, I recommend you take a look to @nvidia GPU Gems blog.
It's time to solve some fluid dynamics equations! These are the well-known Navier-Stokes Equations which describe the motion of a viscous fluid. #ue5#niagara#gamedev#techart#houdini#math
There are three or four unknows in this system of equations, depending on whether we are in 2D or 3D case. The main unknows are: the velocity (two or three components) and the pressure.
The first equations, one for each component of the velocity, are called "momentum equations" and are basically Newton's F=ma applied to a little fluid element. The last equation is the "continuity equation" and it means that the flow is incompressible, i.e., density constant.
Let's suppose we have a scratch pad like the one in the first picture. As we know, this scratch pad runs for every cell in the Grid2D. But, what is it exactly "running"?
Every scratch pad, when we are in "GPU mode", is translated to HLSL code. Fortunately, Niagara can show us this translation. If you select your emitter (and you are in the "Generated Code tab") you should be able to choose "Particle GPUCompute Script".
To do this, we're going to create a new Niagara system in world space that renders a single sprite, parallel to the ground, with a material that reads a texture (with the trace) created in Niagara. It's the perfect effect to learn a few things.
Formerly, this kind of effect was created using some render targets, a material and a blueprint. Now, is the same, but all inside Niagara and, in my opinion, in a more "natural" way.
(2/13) Let's create a scratch pad in the Simulation Stage. In this one, we are going to use the node "Execution Index", that assigns an integer for each cell, and set as the value of the cell. Previously, we normalize it using the dimensions of our Grid2D.
(3/13) For debugging tasks, it is useful ticking the "Preview Attributes" flag in the Grid2D definition. When you enable it, you should see something like the second image. In this case, I've chosen a low number cells so that we can see clearly the differences between cells.