Hello,
I just found out about PolyVox and Thermite in my search for a solution for terrain deformation in games. I'm in the early stages of prototyping a game in which terrain deformation and dynamically flowing water make up the core game mechanic and am looking for a game engine in which to start working.

It appears that Thermite is a very good fit for the terrain deformation part of the game and I'm wondering if the volume-based representation of the world could be adapted to also represent water flowing over that deformable terrain.
I'm not looking to have the water flowing incredibly realistically; I have no intention to use a fluid/particle simulation (overkill for my intention, I believe). My initial demo of the water concept has simply entailed sharing water volumes between neighboring grid spaces; this seems sufficient in terms of "realism" and computation time for a game.

So, my main question is this: Would I be (reasonably) able to use Thermite to simulate water flowing into and out of a map and be able to alter the terrain in-game to successfully change the water's behavior?

I'm sure David can give you a more detailed answer later but as far as my understanding of fluid simulation goes, it should be perfectly possible. I believe that fluid simulation works under a similar principle to traditional game physics (such as falling crates or ragdolls) but where one would use metaballs or similar. These will interact with some sort of mesh in the physics engine. All that needs to be done is to update the physics mesh to match the state of the terrain at any one time. In our physics tech demo posted a while ago, we simplified the terrain before passing it to the physics engine but depending on processing power, that may not be necessary.

If, as you say, you're going for a simpler model of water flow then Thermite/PolyVox should still be able to provide what you need. All that is required is that the water simulation 'engine' that you write can handle discrete changes in the underlying terrain.

_________________
Matt Williams
Linux/CMake guy

I believe that what you want to do is possible in principle, but I would have concerns that you would be updating too many voxels per frame and that you wouldn't be able to regenerate the mesh fast enough.

There is a game in development called 'Minecraft' which also uses a volumetric representation of the world, and they do have this concept of water as a voxel type. They apply basic physics so that the water will flow into open spaces. However, it's very slow and not realistic. You can see it in action here:

http://www.youtube.com/watch?v=6mxeKZzt5MU

Here's one on a larger scale:

http://www.youtube.com/watch?v=JXmSUKrFemc (starts at 40 seconds in)

Is this basically the kind of effect you want to achieve?

From their various videos I get the impression that their engine is a lot slower that PolyVox/Thermite3D (though maybe this is just the artstic effect they aim for), so I think that we could do a lot better. However, I still doubt if it is possible to perform simulation on a large volume in real time.

The problem is that Thermite3D works best when local modifications (such as explosions) are performed because only a small part of the surface has to be rebuilt. With flowing water I can imagine that the whole volume (or most of it) is changing every frame. If you want to regenerate the whole surface every frame then I would estimate that 64x64x64 voxels is the largest volume size you could use.

That said, if you only have a finite amount of water in a level then it can't be everywhere at once, and maybe this keeps the surface regeneration to a minimum.

Thermite3D is not in a mature enough state to prototype this, but PolyVox is. You'd essentially have to write a simple viewer app (based on the OpenGL example perhaps) and then write the code to set the voxels to rock/air/water based on your own rules.

However, overall I believe the best approach for what you are trying to do would instead be to represent the water as particles rather than voxels. I would use an existing physics engines which supports fluid dynamics, pass the terrain geometry from PolyVox into the physics engine, and then render the resulting partcles using metaballs or some other approach. I think your water would look better and move more realistically this way.

The idea is similar to this but with a few key differences:
Minecraft doesn't move water, it only adds it to new spaces (I think the terminology they use is that water "multiplies"). My idea is currently for water to flow; if the side of a lake is removed, the contents of the lake would spread out, lowering the level of water in the lake as it flows out.
The maps I intend to use will be much smaller. In my previous simulations, I can get a reasonable effect on a 64x64 square grid on a fairly low-end laptop.


It sounds like this is my next logical step to see if it will work. I'll grab PolyVox and start looking at the API and experimenting.

I appreciate the feedback and will certainly let you know if this helps lead me to a successful prototype. Thanks!

Yep, you can start by looking at the OpenGL example, but actually you can make your application simpler than that. The OpenGL application breaks the volume into regions and generates a mesh for each, but with a 64x64x64 volume you can just generate a single mesh for the whole volume. Be aware that there might be a potential crash with the edge voxels so it might be best to generate the mesh for slightly less than the full volume.

I just wanted to bump this thread to highlight a new project which I was recently made aware of. It's called 'Liquid Cubed', and is basically an attempt to create more realisitic water in a Minecraft type world. Have a look at the project page here:

http://www.indiedb.com/games/liquid-cubed

While I don't currently have short term plans for anything similar in PolyVox/Thermite3D, hopefully it will be useful to anyone who finds this thread or wants to implement such a system themself.

I also want to implement this in my game. I haven't really sat down to think about this problem except that initially I want to use some sort of cellular automata like simulation. Maybe something like initially when a block is destroyed, it would check it's neighbors for a water source, if found, it would initiate / queue up a water block (a part of the water block simulation), and subsequently the queued up water block would advect it'self (say by check neighbors and queue up more water blocks). And with this advection, carry information and expand the water blocks. The actual water simulation would be based on simple rules based on neighboring blocks and the information advected in the water block. To render this you do not have to render all blocks, one would only have to know the interfaces of the water touching air (fluid interface?) and can be done quickly for cube games. Edit: By simple rules I mean like a reaction-diffusion process. So you information can move around.

Recently I read a series of articles (http://software.intel.com/en-us/articles/fluid-simulation-for-video-games-part-3/ ) on the Vorton Method, a "mesh-free" fluid simulation. (I have some experience previously with Eulerian based fluid simulation using stable fluid family of simulations.) There are several advantages to the Vorton Method: 1) It does not suffer from numerical dissipation 2) It is boundless where even though it interpolates using a grid, this grid is ephemeral and grid resolution is known a prior and remains constant, i.e. simulation domain is independent of grid resolution.

I'm not sure if it would work for block based game but I thought it would be cool because it's like a N body simulation (I guess), so no matter where you are in your domain, your water particle is being affected by reset of the particles. Maybe I can adapt this and combine with celluar automata rules since I probably do need stuff like vorticity, etc, for a block game. (Just a general N body like simulation with efficient update methods).

Thanks for that link - that's an interesting series of articles

This, too, sounds interesting I think this would fit into my game really well (obviously) although I'm not sure about the technical side. Maybe I'll contact the group and try to get some more technical infos to see if I can implement it into my game.

that looks like ceullar automata, such as in those falling sand games. You should read the gamasutra Dwarf Fortress interview, where the DF guy talks about fluid simulation in DF.

http://www.gamasutra.com/view/feature/3 ... hp?print=1