A little game I’m working on

Another screenshot of the fluid simulator game.

Gabriel gave me the option to display those little green arrows you see over there.

What the arrows indicate is the velocity field of the fluid.

The colored area corresponds to the density of the fluid. You can think it as the driving force of the fluid. The density and the direction in which the player moves it using the mouse define the velocity and the direction of it in each pixel the fluid is been drawn.

So, in each pixel the fluid has a velocity and direction as a result of the fluid simulation given the density, the direction of it, taking in account that data in the neighbor pixels as well (the way the solver works).

In physics, Fluids are defined as a substance that deforms (or flows) when a stress is applied on them. The discipline that studies this flow is known as Fluid Dynamics. Liquids, gases and plasmas are all different examples of fluids. [1]

In order to simulate the flow of a fluid a mathematical representation of its current state is needed. At its most basic form a fluid can be thought of as a combination of two properties, velocity that defines how the fluid will move over time and density which defines its composition [3]. For example, when simulating smoke in a room the density will represent the smoke particles that flow through the air and the velocities will determine how these particles will move around the room. Mathematically the velocities can be represented as a vector field that spans over the simulation area while the densities can be represented by individual particles that update their position by following the velocities. However, simulating each single particle can be an extremely expensive operation so the particles are often replaced with “a continuous function which for every point in space tells us the amount of … particles present” [3].

— The first 195 words of my dissertation!

Done! I’ve got Multiresolution Fluids! The top-right area of the simulation has a higher resolution than the bottom-left area, and everything is nicely connected!.

Now, off to write the dissertation!

The first video of my fluids! … Colourful indeed :)

I have “connected” the four quads that form the quadtree. The next step will be to have quads at different resolutions.

"Habemus Quadtree!" I cried at the top of my voice, for I had, after a few days of work, managed to separate the area covered by the fluid into a quadtree.

Right now it behaves as four separate simulations but soon enough each of those sub-simulations will happily communicate with each other effectively breaking down the whole simulation into four.

Isn’t this beautiful?.

After many nights of work and getting angry at the code, physics and life, I have fluids!!. Right now the fluid is being calculated on the CPU. I was having some problems with the algorithm and decided to go back to something more manageable and debuggable. In the next weeks I will move the algorithm to the GPU.

While doing this I had an idea. Could it be possible to change the number of Jacobi iterations used to calculate the Poisson-pressure equation throughout the fluid?. That way I can have areas of interest (with higher number of iterations) and uninteresting areas (with lower number of iterations). I’ll give it a try and see what happens.

This is an screenshot of the real time fluid simulation software @caracasesendundee is creating for his major thesis in videogames.

I said a few days ago that I’m helping him with it and the whole idea is to publish te results for the multiresolution improvements. We are working to make that possible.

Yes, it looks odd but it’s an early stage of the program.

If you are curious, we are using Jos Stam Stable Fluids solver: the original paper here (intermediate calculus and PDE skills needed) and GDC tutorial here ( divulgative and more explanatory), and Harris GPU implementation.

Time for an update. This is the second image from dissertation.

YOU: But wait Gabriel, isn’t that the same image you posted before?.

ME: Well yes! But it now has a fully working feedback cycle using the GPU.

YOU: …

ME: I am rendering those colourful squares using a shader, but I am not rendering them to the screen (yet). I first render them to texture on memory (with an old technique known as Render-to-Texture) and then, with another shader pass, I render that texture on the screen.

YOU: What’s the point?.

ME: When doing the fluids I need to calculate how the “fluid particles” move about and I want to do this computation on the GPU. The problem is that I need to keep the results of this calculation so that I can use them on the next frame/iteration. So, to solve this, I will create a shader pass that will compute this movement and store (render) the results in a texture, this way I can keep a copy of this results in memory. After I generate this “results texture” I can then use it to render it on screen. Nice, right?.

Yes! And here we go again!. This is the first image of my master’s Dissertation/Thesis. Right now it is just a dynamic texture that I can modify through code, and that small white square in the blue quadrant is the mouse position which is modifying the final rendered image in the pixel shader!.

Nothing too fancy, but it is the first building block for some really nice fluids!.

My undergrad Thesis: A multiresolution volume rendering system with seamless transitions between resolutions. We published this work last year at ISVC09.