Fluid Simulation For Computer Graphics: A Tutorial in Grid Based and Particle Based Methods
Fluid Simulation For Computer Graphics: A Tutorial in Grid Based and Particle Based Methods
Abstract
In this paper we present a tutorial on the implementation of both a grid based and a particle based uid simulator for computer graphics applications. Many research papers on uid simulation are readily available, but these papers often assume a very sophisticated mathematical background not held by many undergraduates. Furthermore, these papers tend to gloss over the implementation details, which are very important to people trying to implement a working system. Recently, Robert Bridson release the wonderful book, Fluid Simulation for Computer Graphics.[Bridson 2009] We base a large portion of our own grid-based simulator off of this text. However, this text is very dense and theory intensive, and this document serves as easy version for those who want to implement a simulator quickly. Furthermore, Bridsons text does not cover particle based methods, like SPH, which are quickly becoming commonplace within the graphics community. This work provides an introduction to SPH as well. Keywords: Fluids, Physically Based Animation, SPH, Grid Based
are typically highly accurate, although relatively slow compared to particle based solutions. Particle based simulations are usually much faster, but they typically do not look as good as grid based simulations. Some readers may not know the difference between grid based and particle based simulations. The best description of this can be found in page 6 of [Bridson 2009]. I will attempt to paraphrase this description here. Fluid can be simulated from 2 viewpoints, Lagrangian or Eulerian. In the Lagrangian viewpoint, we simulate the uid as discrete blobs of uid. Each particle has various properties, such as mass, velocity, etc. The benet of this approach is that conservation of mass comes easily. The Eulerian viewpoint, on the other hand tracks xed points inside of the uid. At each xed point, we store quantities such as the velocity of the uid as it ows by, or the density of the uid as it passes by. The Eulerian approach corresponds to grid based techniques. Grid based techniques have the advantage of having higher numerical accuracy, since it is easier to work with spatial derivatives on a xed grid, as opposed to an unstructured cloud of particles. However, grid based techniques often suffer from mass loss, and are often slower than particle based simulations. Finally, grid based simulations often do much better tracking smooth water surfaces, whereas particle based approaches often have issues with these smooth surfaces.
1 2
Introduction Introduction
3
In the context of physics, the word uid may mean something different than you might usually think. In physics, uids fall into two categories incompressible and compressible ow. Incompressible ow is a liquid, such as water or juice. Compressible ow, on the other hand, corresponds to gas such as air or steam. Compressible ow is called compressible, because you can easily change the volume of this uid. Note that there is no such thing as 100 percent incompressible uid. All uids, even water can change volume to some degree. If they could not, there would be no way to audibly yell under water. However, we simply choose to ignore compressibility in uids like water that are nearly incompressible, and instead we refer to them simply as incompressible. There are many, many ways to simulate uids. In graphics, the most common two techniques are grid based simulations, and particle based simulations. (Very recently, new techniques such as the Lattice-Boltzmann method have been introduced to graphics, but they are beyond the scope of this paper.) Grid based simulations
e-mail:
Governing Equations
Here we will describe the governing equations for uid motion, and also describe some of the special notation used in uid simulation literature. For someone only interested in a basic implementation, this section can be skimmed with the exception of the nal paragraph on notation. However, for a full understanding of the why in uid simulation, this section should be read in full. First, we will describe the general incompressible Navier Stokes equations. We will attempt to intuitively describe the vector calculus operators involved, and those without a knowledge of vector calculus may wish to consult the appendix of [Bridson 2009] for review. Here are the incompressible Navier Stokes equations: u 1 +u+ p=F + t
(1)
cbraley@vt.edu
e-mail:sandu@cs.vt.edu
u=0
(2)
In these equations, u is uid velocity. The time variable is t The kg density of the uid is represented by . For water, 1000 m3 . The pressure inside the uid (in force units per unit area) is represented by p. Note that p and are different things(the rst is the Greek letter rho while the second is p). Body forces (usually just gravity) are represented by F . Finally, is the uids coefcient of kinematic viscosity. In our simulator, we currently dont take uid viscosity into account. For inviscid uids like water, viscosity does usually not play a large role in the look of an animation. However, if you wish to include viscosity, see chapter 8 of [Bridson 2009]. The fundamental work on viscous uids in graphics is [Goktekin et al. 2004], and can be taken as a starting point for implementation. When the viscosity term is dropped from the incompressible Navier Stokes equations, we get the following set of equations: u 1 + p=F t u=0 Figure 2: Our 2D Eulerian Solver (3) (4)
4.2
Data Structures
These equations are simpler, and they are the equations we will consider for the rest of this paper. These are called the Euler Equations. Lastly, we will quickly discuss some unique notation used in uid simulation. In simulation, we take small discrete time steps in order simulate some phenomenon. Consider the velocity eld u being simulated. In a grid based simulation, we store u as a discreetly sampled vector eld. However, we need some type of notation to describe which grid element we are referring to. To do this, we use subscripts like the following ua,b,c to refer to the vector at a, b, c (Note that our indexing scheme is actually more complicated, but this is discussed in the beginning of the grid based simulation section.) However, we also need a way to indicate which timestep we are referring to. To do this, we use superscripts, such as uk . a,b,c The previous equation would indicate the velocity at index a, b, c at timestep k. While some would consider this an egregious abuse of notation, this syntax is extremely convenient in uid simulation. In order to maintain clarity, we will explicitly state when we are raising a quantity to a power (as opposed to indicating a timestep). Furthermore, timesteps are written in bold (ab ), whereas exponents are written in a regular script (ab ).
While we have discussed Lagrangian vs. Eulerian viewpoints, we have yet to dene what exactly we mean by grid in grid based simulation. Throughout the simulation, we must store many different quantities (velocity, pressure, uid concentration, etc.) at various points in space. Clearly, we will lay them out in some form of regular grid. However, not just any grid will do. It turns out that some grids work much better than others. Most peoples intuition is to go with the simplest approach: store every quantity on the same grid. However, for reasons which we will soon discuss, this is not a good approach. Back in the 1950s the seminal paper [Harlow and Welch 1965a] by Harlow and Welch developed the innovate MAC Grid technique. (Note that MAC stands for Marker-and-Cell.) Among many things, this paper developed a new way to track liquid movement through the grid, called marker particles, and a new type of grid, a staggered grid. Marker particles are still used in some simulators for their simplicity, but they are no longer state of the art. However, the staggered grid developed by Harlow and Welch is still used in many, many simulators. This grid is called staggered because it stores different quantities at different locations. In two dimensions, a single cell in a MAC Grid might look as follows:
4
4.1
Here we will present a high level version of the algorithm for grid based uid simulation, assuming one wants to simulate n frames of animation. 1. Initialize Grid with some Fluid 2. for( i from 1 to n ) Let t = 0.0 While t < tf rame Calculate t Advect Fluid Pressure Projection (Pressure Solve) Advect Free Surface t = t + t Write frame i to disk Figure 3: Two Dimensional MAC Cell In three dimensions, a MAC cell would look like this: Note that in these images p represents pressure, and u is velocity. We see in these images that pressure is stored in the center of every grid cell, while velocity is stored on the faces of the cells. Note that these velocity samples are the normal component of the velocity at
uz [i][j][k] = wi,j,k 1
2
(10)
Therefore, for a grid of nx , ny , nz cells, we store the pressure in a nx , ny , nz array, the x component of the velocity in a nx +1, ny , nz array, the y component of the velocity in a nx , ny + 1, nz array, and the z component of the velocity in a nx , ny , nz + 1 array.
4.3
4.3.1
Algorithm
Choosing a Timestep
each cell face. We will now describe why the grid is arranged in this manner. Consider a quantity w sampled at discrete locations w0 , w1 , . . . wi1 , wi , wi+1 , . . . wn1 , wn along the real line. Imagine we want to estimate the derivative at some sample point i. We must use central differences of some form. Immediately, one can see that: w wi+1 wi1 x i 2x (5)
When simulating uids, we want to simulate as fast as possible without losing numerical accuracy. Therefore, we want to chose a timestep that is as large as possible, but not large enough to destabilize our simulation. The CFL condition helps us do this. The CFL says to chose a value of t small enough so that when any quantity is moved from the center of some cell through the velocity eld, it will only move h distance. This makes sense intuitively, seeing as if a particle was allowed to move in any larger amounts than this you would effectively be ignoring some parts of the velocity eld. Therefore, our equation for t is as follows: h umax
t =
(11)
Recall from numerical analysis that this is O(x2 ) accurate. However, there is clearly a huge problem with this equation. It ignores the actual value of w at wi ! We clearly need a way to estimate this derivative without ignoring the actual value at the point which we are trying to estimate. We could forward or backward differences, but these are biased and only O(x) accurate. Instead, we choose to stagger our grid to make these accurate central differences work. Our staggered central difference looks like this: wi+ 1 wi 1 w 2 2 x i 2x This formula is still O(x2 ) accurate. It turns out that, later on in our Pressure Projection stage, this staggered grid is very useful, as it allows us to accurately estimate certain derivatives that we require. However, this staggered grid is not without drawbacks. In order to evaluate a pressure value at an arbitrary point which is not an exact grid point, trilinear interpolation (or bilinear in the 2D case) is required. If we want to evaluate velocity anywhere in the grid, a separate trilinear interpolation is required for each component of the velocity! Therefore, in 3D we need to to 3 trilinear interpolations, and in the 2D case we need to do 2 bilinear interpolations! Clearly, this is slightly unwieldy. However, the added accuracy makes up for the complications in interpolation. The above notation with half-indices is clearly useful since it greatly simplies our formulae. However, it is obvious that halfindices cant be used in an actual implementation. [Bridson 2009] recommends the following formulae for converting these halfindices to array indices for a real system: p[i][j][k] = pi,j,k ux [i][j][k] = ui 1 ,j,k
2
(6)
As you can see, this requires us to know the maximum velocity in the velocity eld at any given time. There are 2 ways to get this value, either by doing a linear search through all of the velocities, or by keeping track of the maximum velocity throughout the simulation. These details are discussed in the Implementation section. In computer graphics, we are often willing to sacrice strict numerical accuracy for the sake of increased computational speed. In many situations, a practitioner is not worried about if the uid being simulated is one-hundred percent accurate. Instead, we want plausible looking results. Therefore, in many applications you can get away with using a timestep larger than that prescribed by the CFL condition. For instance, in [Foster and Fedkiw 2001], the authors were able to use a timestep 5 times bigger than that dictated by the CFL condition. Either way, it is good practice to let the user be able to scale the CFL based timestep by a factor of their choice, kCF L . In this case, our equation becomes: h umax
t = kCF L
(12)
(13)
In [Bridson 2009], a slightly more robust treatment of the CFL condition is presented. In this text, Bridson suggests a modication where umax is calculated with:
h |F |
(14)
uy [i][j][k] = vi,j 1 ,k
2
where F is whatever body forces are to be applied (usually just gravity), and max u is simply the largest velocity value currently on the grid. This solution is slightly more robust in that it takes into account the effect that the body forces will have on the simulations current timestep.
4.3.2
Advection
Central to any grid based method is our ability to advect both scalar and vector quantities through our simulation grid. Advection can be informally described as follows: Given some quantity Q on our simulation grid, how will Q change t later? More formally, we can describe advection as: Qn+1 = advect(Qn , t, Q n ) t (15)
cell? This requires extrapolation for our MAC grid. In our experience, simply clamping grid indices is ne in the advection code, but more advanced techniques do exist. However, we have found that in practice these advanced extrapolation techniques do little to visually augment the simulation.
4.3.3 Pressure Solve
So far, we have done nothing to deal with the incompressbility of our uids. In this section, we will develop a numerical routine such that our uid satises both the incompressibility condition: un+1 = 0 as well as our boundary conditions: un+1 n = usolid n (21) (20)
In this section we will develop a computational function for n advect(Qn , t, Q ). t Consider a P on our simulation grid. Using our central differencing schemes described previously, we can trivially calculate Q . Using t this derivative, along with our grid information, we can develop a technique to advect quantities through the grid. This technique sometimes called a backwards particle trace. Since we are using a particle, this is also commonly referred to as Semi-Lagrangian Advection. It is important to note that no particle is ever created, and the particle is purely conceptual. This is what leads to the Semi in Semi-Lagrangian Advection. Note that our algorithm can not be done in place, and requires an extra copy of the pertinent data in our simulation grid. Our algorithm works as follows: 1. For each grid cell with index i, j, k Calculate Q t Calcluate the spatial position of Qi,j,k , store it in X Calculate Xprev = X to Qi,j,k 2. Set Q = Qn+1 This algorithm is very simple, and fairly accurate. However, if you are familiar with numerical analysis, you will recognize that this algorithm uses the simple time integrator Forward Euler. This integrator is not very accurate. We recommend at least using an integrator such as RK2 or better (Runge Kutta Order-2). In our simulator, we tested out 5 different integrators, and found the following O(h3 ) accurate scheme to work the best: 1 = f (Q ) 1 2 = f (Qn + t1 ) 2 3 = f (Qn + 3 t2 ) 4
n Q t
Additionally, this section nally allows us to show the reason for our staggered MAC grid discussed in our previous section. First, we will work out the individual equations to make a single grid cell satisfy our two conditions above. Then, we will show how this information can be used to make the entire grid incompressible. Consider a 2D MAC cell at location i, j. Per the Euler equations, on every step we must update our cells velocity by the following equations. First, we present them in 2D where our velocity is represented by u =< u, v >. un+1,j = un 1 ,j t i+ i+ 1
2 2
(22)
t
n+1 n vi,j+ 1 = vi,j+ 1 t
2 2
(23)
Here are the equivalent equations in 3D for u =< u, v, w >. un+1,j,k = un 1 ,j,k t i+ i+ 1
2 2
(24)
(25)
(16)
(26)
(17)
(18)
Just in case these dont seem complicated enough already, there is another issue that must be attended to. These equations are only applied to components of the velocity that border a grid cell that contain uid. Getting these conditions correct was one of the hardest things in the actual programming of our simulation, and we recommend that an implementor try to rst program this in 2D for easier debugging. A careful reader will also notice that these equations may require the pressures of grid cells that lie either outside of the grid, or outside of the uid. Therefore, we must specify our boundary conditions. There are two primary types of boundary conditions in grid based simulation, Dirichlet and Neumann. We will use Dirichlet conditions for free surface boundaries, indicating that we will specify the value of the quantity at and boundary case. Therefore, we simply assume that pressure is 0 in any region of air outside of the uid.
n+1
2 3 4 = Q + t1 + t2 + t3 9 9 9
n
(19)
We will use this advection scheme throughout our simulator. One common use is advecting uid velocity itself. Another use is advecting temperatures or material properties in advanced simulators. A careful reader might have noticed one issue with the advection psuedocode. How would we perform an advection for a boundary
The more complicated boundary is with solid walls. Here we will use a Neumann boundary condition. Using the above pressure update equations, we substitute in the solids velocity (0 for simulations without moving solids), and then we arrive at a single linear equation for our pressure. Rearranging our terms allows us to solve for the pressure. Now we will work out how to make our uid incompressible. This means that, for every velocity component on the grid, we want to satisfy: u=0 Note that this divergence operator can be expanded to: u= u v w + + x y z (28) (27)
we should store is as a sparse matrix. Each row has at most 4 nonzero entries in the 2D case, and 6 non-zero entries in the 3D case. Furthermore, is is clear that A is symmetric. Every entry at index i, j that is not on the main diagonal is dened by i,j . Through our denition of , it is clear that i,j = j,i . Therefore, we only need to store half of the entries in A. We use the following scheme for storing our matrix. We store a main linked list, sorted rst by column, then by row. We store in each linked list node the following < i, j, pij >. The column index is stored as i, the row index is stored by j, and the corresponding pressure value is stored as p. This storage scheme has many pros and cons. We are storing the minimum amount of data, as we are storing only half of the matrixs non-zero entries. However, this memory saving comes at the cost of speed. Accessing an arbitrary matrix entry is O( 1 n) = O(n), 2 which can be slow. For small simulations where memory usage is not a concern, we recommend including the option to store entries in a dense matrix.
Finally, a reader highly experienced in numerical analysis will realize that A has a form that is common to many other matrices. In 2D, A is often called the 5 point Laplacian Matrix, whereas in 3D it is called the 7 Point Laplacian Matrix. Bridson recommends the Modied Incomplete Cholesky Conjugate Gradient Level 0 algorithm [Bridson 2009]. Essentially, this is simply the conjugate gradient algorithm with a special preconditioner designed for this particular matrix. ui+ 1 ,j,k ui 1 ,j,k vi,j+ 1 ,k vi,j 1 ,k wi,j,k+ 1 wi,j,k 1 If the reader is interested in implementing their own con2 2 2 2 2 2 jugate gradient solver, we recommend the paper [Shewchuk 2007] ( u)i,j,k + + h h h as a good starting point. However, in our implementation we are (29) not planning on dealing with enormous bodies of water so we implemented both the regular Conjugate Gradient algorithm, as well Finally, we have all the quantities necessary for our pressure update. as Parallel Successive Over-Relaxation (Parallel SOR), and the JaWe have developed equations for how the pressure affects the veloccobi Method. We found the parallel SOR to be faster than the conity, and we also have numerical equations to estimate the pressure jugate gradient implementation, but this is probably because we gradient. Using this information, we can create a linear equation are not using a preconditioner. However, conjugate gradient was for the new pressure in every grid cell. We can then combine these slightly faster than the Jacobi method in our tests. Note that we equations together into a system of simultaneous linear equations used OpenMP for parallelizing our SOR implementation. We hope which we can solve for the whole grid, and nally complete our to add a preconditioner to our conjugate gradient implementation in pressure update. the near future. Eventually, we hope to end up with a system of equations of the While we have described the characteristics of the linear system to form: solve, and what kind of solvers to use, we realize that most readers Ax = b (30) will not want to spend their time writing a highly optimized implementation of a specialized conjugate gradient solver. Therefore, Every row of A corresponds to one equation for one uid cell. In we will quickly direct the reader towards a few good linear algebra this formulation, we will setup our matrix such that b is simply our packages that have routines that suit our purposes: negative divergences for every uid cell. When written out, our Therefore, it is clear that we simply want to nd a way so that each component of our spatial derivatives equals zero. Recalling our central differences used earlier, we can approximate these divergences using the following numerical routines, which use our nite differences developer earlier: linear system takes the following form: p1 D1 1,n p2 D2 . . . . . . . = . . n1,n pn1 Dn1 n pn Dn (31) Boost BLAS SparseKit 1 1,2 2 ... . .. n,n1 ... 2,1 . . . n,1 http://people.cs.ubc.ca/ rbridson/mpcg/ Open Source Matlab Implementation of Specialized Form of Conjugate Gradient
4.3.4 Grid Update
4.4
In this equation, Di is the divergence through cell i, i is the number of non-solid neighbors of cell i, and ij takes values based on the below equation: 1 if cell i is a neighbor of cell j 0 otherwise.
ij =
(32)
While we have discussed the basic mechanisms for a grid based simulation, we have not discussed how to unify all these ideas into a full working simulator that can output data that encapsulates the position of a moving water surface. There are many ways to approach the problem of tracking the movement of water through a simulation grid. The simplest way, introduced all the way back in Harlow and Welchs seminal paper [Harlow and Welch 1965b]. This approach is relatively simple, and still quite useful. Here we store a collection of many discrete
Our matrix A has many unique properties we can exploit both in our choice of linear solver and in our storage of A itself. It is immediately clear that A is sparse(most of its entires are zero), indicating
marker particles in our simulation, each representing a water particle. Every timestep, we advect them through the velocity eld by t. Also, we store an enumeration value inside of each cell indicating whether the cell contains liquid, air, or solid. Once a uid marker particle moves into a cell, we mark it as liquid. This is necessary for our pressure solve. After each timestep, we can output these particles to disk. However, the question remains as to how to render these particles. One approach is to use a implicit surface function to generate a water surface from these particles. We discuss this approach later, in section the section on surfacing SPH simulations. Unfortunately, this approach can lead to blobby, ugly surfaces. Therefore, we turn to a level-set based approach, rst introduced in [?]. Level set methods are currently the best way to achieve smooth high quality free surfaces in liquid simulation. However, they are far more computationally expensive than the above implicit surface approach. Here we will present a brief introduction to these techniques. We recommend that an interested reader refer to [Fedkiw and Sethian 2002] for more detailed information. For the level set method, we dene a new value, i,j,k , at the center of all of our simulation cells. We dene our liquid free surface to exist at locations where the following equation is satised: (X) = 0 (33)
2. for each grid point P directly at the free-surface, set the signed distance to 0 3. Loop over each grid-point Gi,j,k at which signed distance is unknown Loop over each grid-point P that neighbors Gi,j,k as long as the signed distance at P is known Find the distance from Gi,j,k to the surface points. If this distance is closer than P s signed distance, mark P as unknown once again Take the minimum value of the distances of the neighbors, and determine if Gi,j,k is inside or outside, and set the sign of the distance based on this There are two main techniques for implementing such an algorithm. These techniques are the fast marching method, and the fast sweeping method. The fast marching method loops over the closest grid points rst, and then those that are farther away. This technique works rapidly by storing the unknown grid points in a priority queue data structure. This algorithm runs in O(nlog(n)) when the priority queue is implemented with a heap. A detailed description can be found in [Sethian 1999]. The other technique is the fast sweeping method. The fast sweeping method takes the opposite approach from the fast marching method. Here, we allow the signed distance function to rst be calculated at our farthest away points. We then have this information propagate back towards the surface. Fast marching is great because it is O(n), and is very simple. Furthermore, it works well with narrow band methods, discussed in [Bridson 2009] and [Fedkiw et al. 2001a]. While we have discussed how to compute a signed distance function, we have not discussed how to update the signed distance as the uids free surface moves. While this may seem complicated, this step is quite trivial. Since our values are stored in the center of our grid cells, we can simply advect these values according to the uids velocity. However, it turns out that advection does not perfectly preserve signed distance. Therefore, we periodically recalculate our signed distance every few timesteps. Bridson reccomends that we recalculate our signed distance once per frame (note that typically many timesteps of t are required per frame) [Bridson 2009]. TODO: Finish this section. I am still working on it since my level set implementation is not complete.
Where X is a position vector. Note that we can dene (X) at nongrid cell locations through any type of interpolation, either trilinear or Catmull-Romm is a ne choice. Furthermore, we say that locations that satisfy (X) < 0 to be inside of the water, and (X) < 0 to be outside of the water. To represent , we use a function called the signed distance function. Given an arbitrary set S of S points, we dene our signed distance function D(X) as: DS (X) = minpS X p (34)
Clearly, for some arbitrary point X, the magnitude of the signed distance is the distance to the nearest point in the set S. Signed distance is also useful because of another property. If we want to check whether a grid cell is inside or outside of the uid, all we must do is examine the sign of the signed distance. Thus far we have ignored an important problem with signed distance: how to compute it. At the beginning of a simulation, we can assume our signed distance function is already computed on the grid. There are many ways to calculate signed distance, and new problem-specic techniques are developed frequently. Typically, people classify these methods into two groups: PDE based approaches and Geometric Approaches. PDE Based techniques approximate something called the Eikonal Equation, = 1. These techniques are mathematically and computationally involved, and are often overkill for graphics work. Instead, we will discuss briey the geometric approaches. Our discussion will not go into much depth; for a more in depth treatment of geometric algorithms for computing signed distance see [?]. Our algorithms for computing signed distance take the following general form: 1. Set the signed distance of each grid-point to unknown
5
5.1
In this section we describe an alternative approach to uid simulation. Here we discuss Lagrangian techniques. In this approach, we have a set of discrete particles that move through space to represent our uid. We no longer simulate our uid on a grid structure. This approach has many pros and cons compared to grid based techniques. In general, particle based approaches are less accurate than their grid based counterparts. This is primarily due to the difculties in dealing with spatial derivatives on an unstructured particle cloud. However, particle based simulations are typically much easier to program and understand. Furthermore, particle based techniques are much faster, and can be used in real time applications such as video games.
We will describe Smoothed Particle Hydrodynamics. This technique was originally introduced for astrophysical simulations[?], but has also found a lot of uses in computer graphics [?]. This description is especially valuable, since SPH is not discussed in Bridsons text[Bridson 2009], and crucial implementation details are scattered through both astophyics, computational uid dynamics, and computer graphics literature.
Note that in this equation, Asomething refers to the acceleration i on particle i due to something. Also, recall from basic physics F (F = M ) that Ai = Mii . A In order for our simulation to progress, we need a way to calculate uid density at some arbitrary point. Certain particle properties, such as mass, are given initial values at the beginning of the simulation and are not expected to change. However, other properties must be recalculated every step. Consider the pressure property. Here is how to determine the new pressure every time step: However, we have a discrete cloud off particles, so we must use a discrete summation to approximate this integral. This leads us to the equation:
n
Mj WRij
j=i
(36)
Here, Rij is equal to the Euclidean distance between particle i and particle j. Figure 5: Our Simple 2D SPH Implementation This function W (d) is known as a kernel function. This function takes a single scalar parameter, which is a distance between two particles, and returns a scalar [0, 1]. Typically, a kernel function maps particles that are farther away to values closer to 0. This makes sense, since particles far away will not have a large inuence on a particle. Once particles are far enough away from the source, the kernel function drops to 0, and therefore these particles no longer have to be considered. We will exploit this fact in a later section when developing acceleration structures for SPH simulations. The question of what kernel function is best is still a very open research question. However, since our simulations are targeted at begin visually pleasing, rather than scientically accurate, we do not care much about this. The following kernel function has been used extensively in research and practical applications. This is the Gaussian Kernel. 1 h3
3 2
5.2
Data Structures
First, we must outline what information we need to store for our simulation. Clearly, we need a data structure to list all of our particles. Since particles must frequently be added to the simulation, we will choose a linked list. However, the question remains as to what information is stored in each particle. Clearly, we need to store position, velocity, mass, density, and pressure. It turns out to be useful to store color and a force vector as well, so we will store these. We will refer to these quantities with the following variables throughout our discussion: X Position V Velocity M Mass d Density Pressure C =< Cred , Cgreen , Cblue > Color F Force Note that for our color, each component of the color is [0, 1]. Each particle can be trivially implemented as a C structure. Notationally, we will refer to particles with the variable P , and individual particles using subscript notation. For instance, the i-th particle would be Pi . Finally, we will refer to particle quantities in a similar manner. For example, the mass of the 12th particle would be M12 .
W (d) =
exp(
r2 ) h2
(37)
Here r is a the distance between two particles, h is our smoothing width. Once particles are greater than distance 2h away, they will no longer affect the particles in question. Clearly, larger values of h will make for a more realistic simulation, albeit at the expense of computational speed. Finally, we present full psueo-code for an SPH simulation: Initialize all particles Set t = 0 Choose a t for i from 0 to n for j from 1 to numparticles Get list Lj of neighbors for Pj
5.3
Algorithm
Our nal goal is to satisfy the following condition: For all particles Pi : V = Apressure + Aviscosity + Agravity + Aexternal i i i i t i (35)
Calculate Densityj for Pj using Lj Calculate P ressurej for Pj using Lj Calculate acceleration Aj for Pj using Densityj and P ressurej
Move Pj using Aj and t using Euler step t = t + t Cleanup all data structures Exit
5.4
Acceleration Structures
Figure 7: Raytraced GPU Based 3D SPH from University of Tokyo
As described above, there is a clear computational bottleneck in our application. We must calculate interaction forces between each and every particle. This is an O(n2 ) process, which is not computationally viable. By using spatial data structures, we can reduce our computation time to O(n) in the typical case. In the worst case, where all of the particles are in one cell, our algorithm still runs O(n2 ) Advanced techniques using quadtrees in 2D, or octrees in 3D, can eliminate this possibility. In addition to storing all of our particles in a linked list, we also store them in a spatial grid data structure. Our grid cells extend by a distance of R in each dimension. Therefore, in order to calculate the forces on a particular particle, one must only examine 9 grid cells in the 2D case, or 27 grid cells in the 3D case. This is because, for any grid cells far enough away, our kernel function will evaluate to 0 and their contributions will not be included on the current particle. In our experience, including this spatial grid can decrease simulation time by over an order of magnitude for large enough simulations. However, the addition of this grid data structure requires additional book-keeping during the simulation process. Whenever a particle is moved, one must remove it from its current grid cell, and add it to the grid cell it belongs in. Unfortunately, there is no way to do this simulation in place, and one must maintain two copies of the simulation grid. Additionally, this xed grid requires us to change our kernel function. Oftentimes, implementors in graphics dene their kernel functions using a piecewise function. If the particles are less than some distance h apart, they evaluate some type of spline. If the particles are farther away, the kernel instead evalutes to 0. However, more advanced kernels exist for these types of simulations, and they have recently been used with success in graphics. One of the most common advanced kernels is the cubic spline kernel.
5.5
Surface Tracking
At our current stage, all SPH results in is an unorganized point cloud of uid particles. This is unacceptable for most applications. Usually the compuiter graphics practitioner desires a way to render these uids using a off-the-shelf 3D renderer. In this section, we will outline a few techniques for transforming the result of our SPH simulations into a renderable form. T and probably the easiest technique, is to sample our SPH results onto a uniform grid. Here we can step through the uniform grid points, and sample the uid density on these points. Then, we can use this uniform grid as input to an application that performs isosurface volume rendering. Here we have a choice between direct volume rendering, such as that presented in [Colin Braley 2009], and marching cubes[Lorenson and Cline 1982]. Direct volume rendering, typically done through volume raycasting, has the advantage of speed. However, there is no easy way to integrate this resulting image with other generated images, and therefore this technique is only suitable for creating previews. Marching cubes, on the other hand, produces triangle meshes. These meshes are suitable for use in a 3D animation program, and this is therefore a viable option for nal production. While there are benets to sampling our SPH onto a grid, there are other techniques that often produce better results. Usually, these techniques use a special function for each particle that, whe combined with the other particles, produces a uid surface. The function usually used for this purpose was introduced by [Blinn 1982]. This technique is often referred to as meta-balls or blobbies in the graphics community. X xi ) h
F (X) = n k( i
(38)
Where h is a user specied parameter representing the smoothness of the surface, and k is a kernel function like the one represented above. Incremenetal improvements have been made to the the above function throughout the years, the most imporortant of which is presetned in [Williams 2008].
Figure 6: Our 2D SPH Implementation with Lookup Grid Finally, SPH can be further optimized in another way. SPH is clearly very data parallel. Therefore, each particle can be simulated in a separate thread with relative ease. Because of this, many high performance SPH implementations are done on the GPU.
5.6
Extensions
AND J ENSEN ,
This document has only scratched the surface in discussing the current state of the art uid simulation techniques. For a thorough explanation of grid based methods, see [Bridson 2009]. No comparable resource for SPH and particle based technique exists, but the author recommends reading the papers of Nils Theurey, and the SIGGRAPH 2006 Fluid Simulation Course Notes as a starting point. Other active areas of uid simulation research in the graphics community include, smoke simulation, re simulation, simulation of highly viscous uids, and coupled simulations. Coupled simulations combine two or more simulations and get them to interact plausibly. Recently, Ron Fedkiws group achieved 2-way coupled SPH and grid based simulations in [?]. Furthermore, examples of couplings with thin shells, rigid body simulations, soft body simulations, and cloth simulations exist as well.
F OSTER , N., AND F EDKIW, R. 2001. Practical animation of liquids. In SIGGRAPH 01: Proceedings of the 28th annual conference on Computer graphics and interactive techniques, ACM Press, New York, NY, USA, 2330. G OKTEKIN , T. G., BARGTEIL , A. W., AND OB RIEN , J. F. 2004. A method for animating viscoelastic uids. ACM Transactions on Graphics (Proc. of ACM SIGGRAPH 2004) 23, 3, 463468. G UENDELMAN , E., S ELLE , A., L OSASSO , F., AND F EDKIW, R. 2005. Coupling water and smoke to thin deformable and rigid shells. In SIGGRAPH 05: ACM SIGGRAPH 2005 Papers, ACM, New York, NY, USA, 973981. H ARLOW, F., AND W ELCH , J., 1965. Numerical calculation of time-dependent viscous incompressible ow of uid with a free surface. the physics of uids 8. H ARLOW, F., AND W ELCH , J., 1965. Numerical calculation of time-dependent viscous incompressible ow of uid with a free surface. the physics of uids 8. H ARLOW, F., AND W ELCH , J., 1965. Numerical calculation of time-dependent viscous incompressible ow of uid with a free surface. the physics of uids 8. L ORENSON , AND C LINE. 1982. Marching cubes. ACM Trans. Graph. 1, 3, 235256. P ETER , M. C., M UCHA , P. J., B ROOKS , R., I II , V. H., T URK , G., 2002. Melting and owing.
AND
Figure 9: Two Way Coupled SPH and Grid Based Simulation by Ron Fedkiws Group
P ETER , M. C., M UCHA , P. J., AND T URK , G. 2004. Rigid uid: Animating the interplay between rigid bodies and uid. In ACM Trans. Graph, 377384. S ETHIAN , J. A. 1999. Level Set Methods and Fast Marching Methods: Evolving Interfaces in Computational Geometry, Fluid Mechanics, Computer Vision, and Materials Science (Cambridge ... on Applied and Computational Mathematics), 2 ed. Cambridge University Press, June. S HEWCHUK , J. R. 2007. Conjugate gradient without the agonizing pain. Tech. rep., Carnegie Mellon. S TAM , J. 1999. Stable uids. 121128. W ILLIAMS , B. W. 2008. Fluid Surface Reconstruction from Particles. Masters thesis, University of British Columbia.
Acknowledgments
Thanks to Robert Hagan for editing this work.
References
BATTY, C., AND B RIDSON , R. 2008. Accurate viscous free surfaces for buckling, coiling, and rotating liquids. In Proceedings of the 2008 ACM/Eurographics Symposium on Computer Animation, 219228. BATTY, C., B ERTAILS , F., AND B RIDSON , R. 2007. A fast variational framework for accurate solid-uid coupling. ACM Trans. Graph. 26, 3, 100. B LINN , J. F. 1982. A generalization of algebraic surface drawing. ACM Trans. Graph. 1, 3, 235256. B RIDSON , R. 2009. Fluid Simulation For Computer Graphics. A.K Peters. C OLIN B RALEY, ROBERT H AGAN , Y. C. D. G. 2009. Gpu based isosurface volume rendering using depth based coherence. Siggraph Asia Technical Sketches. F EDKIW, R., AND S ETHIAN , J. 2002. Level Set Methods for Dynamic and Implicit Surfaces. F EDKIW, R., S TAM , J., AND J ENSEN , H. W. 2001. Visual simulation of smoke. In Proceedings of SIGGRAPH 2001, ACM Press / ACM SIGGRAPH, E. Fiume, Ed., Computer Graphics Proceedings, Annual Conference Series, ACM, 1522.