Live data from Hacker News

Simulating water over terrain

lisyarus.github.io

31–40 of 60 posts

Re: Simulating water over terrain

#31

This is super, super cool! I was experimenting with a similar idea recently with the help of o3-mini-high. I talked it through my idea for an algorithm, and it implemented and rendered it in 3D with no manual intervention (although I did prompt it a number of times): https://3d-water-sim.netlify.app/ It's not perfect yet because I stopped playing with it, but it was improving significantly with each iteration. Fun fa…

Curious, when you do these exercises, is for entertainment or learning? If the latter, do you find it still worthwhile to read the blog post of this thread, since you didn’t implement anything yourself?

It’s a journey versus destination question.

Re: Simulating water over terrain

#33
post #29

I always find it a bit of a disappointment when the focus is only on how a simulation looks rather than if it is physically accurate.

Given my interest in games and demos, I feel the opposite. I'm always in search of the real-time method that looks plausible and can cover huge areas in 3d space.

Computational accuracy is not important to me at all.

Re: Simulating water over terrain

#37
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 exploration of this topic.

One of my favourite people on the internet working on this stuff is https://nickmcd.me — he’s got some of the best procedurally generated terrain I’ve seen.

But his work is also domain-constrained due to the simulation design.

I’ve thought about potential solutions and I think the best way would be to procedurally generate water shed boundaries that can’t be broken. Then you can parallelize and simulate an entire water shed at once.

It’s such an interesting problem, but it’s also way out of my knowledge domain so I’m mostly just an observer.

Re: Simulating water over terrain

#38

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…

Amazing resource, thank you!

Re: Simulating water over terrain

#39

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…

What shocked me is that Nick is only 25 years old. Wow.

Re: Simulating water over terrain

#40
> 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 equal).

I guess that can be solved averaging he value of a flow arrow with the 6 neighbor arrows in the same direction. With a big weight with the arrows that are in the front and back, and a small weight for the arrows that are on the sides. For example with these arrows

     -a->  -b->

  -c-> -d->  -e->

     -f->  -g->
then

  New_d = d * (1 - 2*.1 - 4*.01) + (c+e)*.1 + (a+b+f+b)*.01
Where .1 and .01 are weight that I just invented but must be tweaked, perhaps with a power like the one they use to kill osculations. That coefficient can also be included:

  New_d = d * (1 - 2*.1 - 4*.01 - .001) + (c+e)*.1 + (a+b+f+b)*.01
Post reply on HN