# How can I define areas filled with water?

I would like to enhance my little game engine with nice looking water simulation. To start working on that I need to find a proper way to represent water in the game. Unfortunately I don't know much different representations, so I'll ask you. There is a similar question I asked some time ago. But since I hadn't formulated the issue clearly, the answer is correct but not what I was looking for.

In some games, water is just defined by a height level. For example everything under the height of zero is underwater. I saw this representation in (mostly older) games. The problem is that I'd like caves in the outdoor world which aren't flooded and different water levels for each lake and sea.

Another, more precise, representation of the occurrence of water are particles. Every water drop is stored as a point in world space. To render them, I could use techniques like metaballs so that they build a single mesh. This representation would be great for realism since I could easily calculate dynamics among them. Sadly no machine could calculate a ocean of metaballs in real time.

Are there other ways of representing water in an engine? I would like to have dynamic lakes, so defining water area by a static geometry is no option. For example if the player modifies the terrain to widen a lake, the water should fill that bay and the overall water level of that lake should slightly decrease.

• How is your terrain organized in the engine? There's different techniques for voxel vs. heightmap vs. polysoup (mesh) terrain. – Exilyth May 13 '13 at 12:53
• It is given as a mesh and water shouldn't trade that terrain mesh differently than other static meshes. – danijar May 13 '13 at 12:59
• trade or treat? – Tom 'Blue' Piddock May 13 '13 at 13:00
• There are some very nice demos of such a metaball aproach, but I don´t see it useable in any real game that is not entirely focused on the fact that the water simulation is to some point physically believable. I don´t see a reason against just a mesh, it also shouldn´t be a problem to have it adjust to the sourroundings or even generate it based on some physical simulation. But that is something you only want to do if really needed. As reference for semi realistic water simulation you might want to check "From Dust". – Slin May 13 '13 at 19:00
• The variable size solution was to the "ocean of metaballs" problem. Also, there would of course be limits to the size variance depending on volume, as it's a means of optimizing performance, not altering the volume of water. Just add a special consideration, like nearness to player and surface, for areas needing detail like waterfalls, tributaries, shores, or streams. – Attackfarm May 14 '13 at 9:48

I cannot say what is commonly used, but my first thought would be to use a particle system with particles of varying sizes representing water of various volumes. The top of the water would use smaller particles to form the undulations of the surface and waves, the water nearest the player would use the smallest particles to simulate splashes and small undulations, while the further or deeper the water would be, the larger the particles. This would allow for a dynamic number of particles simulating water of any size, dynamics of the water as it changes, and some reasonable and controlled performance level.

I can see problems with this implementation, but it certainly seems like a relatively simple and "good enough" solution that a viewer/player would be doubtful to ever notice deviations in the simulation.

If you were using a voxel-based terrain, you could, in addition to storing the density of ground per voxel, you could also store a water value that is clamped between 0 and 1 - groundDensity. Drawing the water would be as simple as running a marching cubes pass over the water values. Simulating the water would be a little more difficult, but the basic premise is that you want to solve the system such that:

1. Below-surface water should fill up the remainder of the voxel
2. Surface-level water should have the same total density, groundDensity + waterDensity, as its neighbours
3. Water may be displaced to any voxel immediately adjacent and below it, provided that the neighbour's total density is less than its total density

The ideal algorithm would run in a compute shader, one execution path per voxel. If you wanted to get fancy, you could also store the water's velocity within that voxel for additional simulation effects: for example, attempting to distribute an amount of water proportional to the velocity to the cells "pointed to" by the velocity vector. This velocity data could also be used to move the waves, draw rapids, etc.

• Unfortunately I have no voxel terrain, as pointed out in the comments under the question. Thanks anyway. – danijar May 14 '13 at 8:10