Live data from Hacker News

Simulating water over terrain

lisyarus.github.io

51–60 of 60 posts

Re: Simulating water over terrain

#51

One of the challenges with simulated hydrology, especially in procedurally generated games that I’ve found, is that water accumulates and can affect nearby cells, which affects other nearby cells, and so on. So although procedural generation is often a great case for parallelizing, one of the cases you’d most want parallelization for can’t really be parallelized on unbounded domains. I haven’t seen a lot of explorati…

If you get curious, in the space of solving partial differential equations they sometimes speak about "regions of influence" and "regions of dependence" – this refers to exactly what you are talking about – given a specific point, there is some area that can influence its value, and there is some area that can be influenced by its value. Sometimes it's possible to know ahead of time which those areas are.

Re: Simulating water over terrain

#52

> Of course, this model isn't perfect. One of the most obvious problems is that it doesn't have inertia and velocity diffusion. A fast water stream entering a lake won't propagate further inside the lake, but will instead spread out in all directions, ignoring all accumulated inertia. Two parallel water streams going in opposite directions can exist and not interact with each other (provided the water levels are equa…

I would say the proper solution is to add another grid for the second derivative, this time matching the original grid. That is

grid 0: water height in each cell

grid 1: water flow at each edge (first derivative)

grid 2: water acceleration in each cell (second derivative)

So each grid is the dual of the previous one and stores its derivative. In fact I don't think you even need to store edge data as a special case, just corner data and work purely with dual grids. You can derive the edge flow by taking the sum of the flow at the two corners of the edge. So you update the fluid height based on flow, then you update acceleration based on how much fluid mass flowed into the cell with what velocity, then you update the flow based on acceleration and current fluid height. I don't really know fluid dynamics, but looking at it purely from a numerical simulation standpoint, it sounds about right. It would also let you have diagonal flow.

Re: Simulating water over terrain

#53

One of the challenges with simulated hydrology, especially in procedurally generated games that I’ve found, is that water accumulates and can affect nearby cells, which affects other nearby cells, and so on. So although procedural generation is often a great case for parallelizing, one of the cases you’d most want parallelization for can’t really be parallelized on unbounded domains. I haven’t seen a lot of explorati…

Yeah interesting question. Presumably you can do it by having a border around each region, and a max speed of effect propagation (i.e. causality). Then if you want to simulate e.g. 10 time steps, you have a border of 10 grid cells. So do 10 time steps on each region, then synchronise border state with other parallel border sims. Then rinse and repeat.

Re: Simulating water over terrain

#54

One of the challenges with simulated hydrology, especially in procedurally generated games that I’ve found, is that water accumulates and can affect nearby cells, which affects other nearby cells, and so on. So although procedural generation is often a great case for parallelizing, one of the cases you’d most want parallelization for can’t really be parallelized on unbounded domains. I haven’t seen a lot of explorati…

No, seriously, do check https://nickmcd.me Incredible!

Re: Simulating water over terrain

#55
post #49

> Of course, this model isn't perfect. One of the most obvious problems is that it doesn't have inertia and velocity diffusion. A fast water stream entering a lake won't propagate further inside the lake, but will instead spread out in all directions, ignoring all accumulated inertia. Two parallel water streams going in opposite directions can exist and not interact with each other (provided the water levels are equa…

That violates conservation of momentum. To get realistic flow, you need to use continuity equation to preserve the energy of the flow and let the shear dissipate and diffuse into whorls. Which is a lot of extra calculation, as pointed out in the article, so you need to ask yourself if that level of realism is really necessary for your use case.

The first evacuation (without the dumping coefficient)

  New_d = d * (1 - 2*.1 - 4*.01) + (c+e)*.1 + (a+b+f+b)*.01
is as good as conserving momentum as the original model. (Assuming you calculate all the new values using a new matrix instead of overwriting the old ones.) It breaks energy conservation, but that simulates the friction between oposite direction currents, without going to the whorls level.

I agree that this is not 100% realistic, but I think it's a good and simple addition to the model in the article, and tweaking the coefficients it may give a good enough visual result.

Re: Simulating water over terrain

#57

One of the challenges with simulated hydrology, especially in procedurally generated games that I’ve found, is that water accumulates and can affect nearby cells, which affects other nearby cells, and so on. So although procedural generation is often a great case for parallelizing, one of the cases you’d most want parallelization for can’t really be parallelized on unbounded domains. I haven’t seen a lot of explorati…

Came here to do a worse job of writing this comment. Terrain generation via water simulations are cool, except they don't work for the primary use cases for terrain generation. Water simulations are inherently slow you have to choose to either

1) Have a small domain

2) Have a large resolution

3) Have a very long initial load time

Any of these suck for game development.

Re: Simulating water over terrain

#58
post #25

Nice explanation. I like the viscosity part, I implemented something similar a couple of years ago in an open source RTS game engine (test video at: https://www.youtube.com/watch?v=cQW8WXNpYXk ), and without viscosity water was spreading thin and due to floating point, at some point it was spreading on flat surfaces and "evaporating". Also, the grid resolution required to obtain nice waves was a bit too much for the…

Very cool! Based on the video you're also doing some hierarchical subdivisions?

The hierarchical subdivision is done only at the rendering steps to reduce the number of polygons. A better rendering would be anyhow required, but I was more curious if the rest of the game would be fine with different and dynamic levels of water. The units seem to behave fine, but due to performance being rather poor I did not polish the code...

Re: Simulating water over terrain

#59
post #13

Off topic, but the post mentions needing terrain manipulation for resource gathering. I always thought animal crossing had a clever and efficient approach to this without any terrain manipulation. You can chop a tree, and it'll dispense logs, but only so many before it essentially has a cooldown. You get the feedback and the finite resources, without expensive terrain manipulation. Of course that doesn't work for eve…

The blog mentioned that strategy, in the form of gold ore in a gold ore boulder found lying around It a standard strategy for resource dispensation (though cooldown doesn’t alleviate the infinite resource problem; it just slows it down), it’s just… boring and unimpactful

> it’s just… boring and unimpactful

It's also cheap and easy. You have limited resources to work with in game dev, even more if you care about performance on anything but the most powerful machines. I'm of the opinion that those resources should be spared for what makes your game unique and fun.

Re: Simulating water over terrain

#60
post #13

Earlier quoted context omitted.

The blog mentioned that strategy, in the form of gold ore in a gold ore boulder found lying around It a standard strategy for resource dispensation (though cooldown doesn’t alleviate the infinite resource problem; it just slows it down), it’s just… boring and unimpactful

> it’s just… boring and unimpactful It's also cheap and easy. You have limited resources to work with in game dev, even more if you care about performance on anything but the most powerful machines. I'm of the opinion that those resources should be spared for what makes your game unique and fun.

If the actual act of resource acquisition isn’t actually meaningful to gameplay, it should probably be eliminated outright. The correct thing to do is simply consider it a resource node with ownership, and grant resource stacks automatically at a given time interval. This is probably the cheapest, easiest strategy while allowing for gatekeeping.

In animal crossing of course, half the point of the game is to kill time peacefully, so it wouldn’t apply. With the game in question, the meaningfulness is unknown

Post reply on HN