VERC: Static Water Simulation Last edited 22 years ago2002-12-07 07:51:00 UTC

You are viewing an older revision of this wiki page. The current revision may be more detailed and up-to-date. Click here to see the current revision of this page.

This article was recovered from an archive and needs to be reviewed

  1. The formatting may be incorrect as it was automatically converted to WikiCode from HTML, it needs to be revised and reformatted
  2. Some information may be out of date as it was written before Half-Life was available on Steam
  3. After the article is re-formatted and updated for Steam HL, remove this notice
  4. Please do not remove the archive notice from the bottom of the article.
  5. Some archive articles are no longer useful, or they duplicate information from other tutorials and entity guides. In this case, delete the page after merging any relevant information into other pages. Contact an admin to delete a page.
Water; it's all around us. Out of a tap, out of the sky - we'd be dead without it. Some may argue that Brits get an unfair slice of the rain pie, and I'd agree there, but without water there would not be life.

But enough of my ramblings. Water is incredibly hard to represent accurately in games due to its liquid nature and complex physics (indeed, people still don't fully understand the physics of oceans, having to turn to quantum physics to solve a particular problem involving 'freak waves'), but all the same, it is an integral part of many games. I feel that their implementations of water are mostly horribly hacky (Half-Life with its sin(t) 'waves', UT2K3 with its bowls of jelly) and could do with a boost - so, I'm going to explain an algorithm for static water simulation that's been around for a fair amount of time, but hasn't been paid much attention.

This isn't the best algorithm in the book by far - it has a certain caveat which I'll explain later - but other, better ones involve Fourier transforms, and thus a heck of a lot of computational power which we simply can't afford to spend. At least, not until we're into 20 GHz computers, anyway.

For this algorithm to work, the water needs to be represented in a grid (size n x m ) with each element of the grid being a point on the surface of the water. It also computes the next time step using the last two time steps, and so at least two sets of the grid need to be stored. There are also various constants: So, how do we use all these values? Well, there's one large equation which gives the wave height at grid position i, j and time step k (so that the actual position of the vertex being modified is di, dj and the actual time value is kt ), which is this:
eq1.gifeq1.gif
(Actually, it gives the height at the next time step, not the current one, but it's the same thing.)

I know exactly what you're thinking. You're thinking "If I calculate that for every vertex in the grid, it'll slow me down to heck." And you'd be right - if it weren't for some tricks that can be performed. If you carefully examine the equation, you'll notice the first term contains a large amount of multiplication and division purely involving pre-defined constants - so all that has to be done is pre-compute it. The same applies for the second term and the third term, reducing a ton of multiplications, divisions and additions to one multiplication.

If you apply this function to the grid every frame, you'll find your water will sit there, perfectly still - as it should do. Now, try displacing one of the points by an amount - if you got your constants right the first time, you'll see some ripples form. If you got your constants wrong, you'll see hardly anything happen, or all the vertices in the grid will shoot off exponentially. You see, that's the problem with this algorithm; it has strict conditions as to when it will be stable, and when it will become unstable. These conditions can be expressed in some inequalities, and it's up to you to choose which one to try and satisfy. They are:
eq2.gifeq2.gif
or
eq3.gifeq3.gif
If one of these two conditions is not met, then as mentioned earlier, the vertices will shoot off at an exponential rate, which is definately not how we want our water to behave.

If, after all this, you're eager to write your own simulation, then good luck. If you want your ripples to 'bounce' off the edges of your grid rather than just dissipating, then always force the edge vertices to stay at a constant height - then it'll behave like a square puddle. Another thing you could do is try to have a variable grid - it'd still be a grid, but you could 'disable' some of the vertices to give it a different shape.

This concludes this whirlwind tour of a standard static water (and indeed, any fluid you care to mention) simulation. If you want more information on how the equations are derived, then head for chapter 12, fluid simulation, in 'Mathematics for 3D Game Programming & Computer Graphics'.
This article was originally published on the Valve Editing Resource Collective (VERC).
TWHL only archives articles from defunct websites. For more information on TWHL's archiving efforts, please visit the TWHL Archiving Project page.

Comments

You must log in to post a comment. You can login or register a new account.