# How effects found in "Autodesk Fluid FX" are implemented using OpenGL ES?

How this kind of effects are technically implemented using OpenGL ES? Are they performing simulation on GPU (using Shaders) or CPU while using some smart vertex positioning and texturing? Why it appears so fast (in terms of performance)?

You might check the video of that app here: http://www.youtube.com/watch?v=F4KOk6QP6kQ

edit

Here is the presentation for the app: http://www.futuregameon.com/FGO2010_JosStam.pdf

For fluids you don't need big resolution as the screen is. 2D (or 3D fluids) can be done in 1/2 without quality loss and 1/4 without significant quality loss. That is if linear interpolation is used(linear texture sampling). If cubic interpolation is implemented, you can go for even lower resolutions.

Stable fluids can be computed on the CPU in interactive rates. It is todays' fashion to put everything on the gpu (and i love it), but 2D fluids can be very nicely handled on CPU. Autodesk maya fluid solver is single threaded (as whole maya (!)) and can handle aprox. 15*15*15 (3375) 3D fluids at realtime on todays CPU. So i'm not afraid about performance on any mobile platform if the simulation is only 2D.

How is this done?
First smoke:
Density and speed is simulated. As you can see in slides you posted. Navier-Strokes equations can do the job. They can be quite simple or very complex (like Maya, where you can simulate density,temperature,pressure and fuel, with tons of setups). If you simulate only density and speed - you will get two 2D arrays. Speed (array of 2D vectors) and density (array of scalar). By rendering density as fullscreen texture you can get nice smoke (remember thay you can have 1/2 screen resolution without quality loss). I also suggest to use some simple "Transfer function". It mean that value from density doesn't just move with opacity, but it can lookup in the color.

And for the floating pictures: You will do what Jari Komppa said. Every frame has input picture texture and for every pixel you read value from (pixelPosition - SpeedVector). Speed vectors can be loaded as textures (red, green = x,y). Density still has to be simulated (even if it is not displayed) to have correct speed vectors.

For fluid simulation on the gpu check this link

• btw. I work on fluid rendering in Autodesk Maya :) Mar 17, 2011 at 16:46

You can do that with either fragment shaders or a grid of textures. With fragment shaders you get more precision.

The basic idea is that you have some kind of transformation and then you recursively apply it to the same data - meaning you store the results of the last frame and then apply the same transformation to it again.

As an example you might divide the screen to 24x24 quads, and then jitter the vertices a few pixels. Applying this transformation to the data will cause the pixels to flow a bit.

Add a smoothing pass and voilá - fluid fx.

edit

Here's a quick simulation of this done in photoshop; few frames with the "waves" filter applied and re-applied:

note that it's the exact same filter applied to the previous result, not new parameters applied to the first frame.

edit why it appears so fast is due to this simplicity - it's just rendering the whole screen once, using the last frame as the source texture.

edit Browsing through the presentation, yes, it does seem it's based on "real" fluid simulation, but the result is pretty much the same - rendering the whole screen, using the previous frame as source texture, offsetting using an offset texture which contains the motion vectors. Calculating said motion vectors is another matter, but can even be done offline.

• Jari, i don't think that your image is correct, photoshop doesn't change direction vectors and this is not fluid simulation. It is similar, but irelevant to the answer. And some kind of transformation function? That is really wrong without mentioning Navier-Strokes or LBM ... Mar 17, 2011 at 12:41
• I don't think the linked video is "fluid simulation" either, but exactly this. Mar 17, 2011 at 12:53