Playing with #water in a #godot prototyping project.

[youen@mastodon.gamedev.place]

Playing with #water in a #godot prototyping project.

This is based on https://github.com/Zylann/fluid2d_demo which I have modified to simulate pressure and allow water to flow upward when pressure is high enough.

It's fun, but I'm not sure that would scale well in 3D on a 16000x8000x16000 voxels world 😅

[youen@mastodon.gamedev.place]

I think the key could be to
- efficiently ignore parts of the world where there is no water
- avoid simulating water voxels that are stable (constant level, constant in/out flow) so that, for example, rivers can flow continuously without any simulation cost

But there's still a lot of work to make that work.

[youen@mastodon.gamedev.place]

Still playing with #LiquidSimulation and #Godot here, but this time in 3D and at a much larger scale.

It's becoming interesting, but still not sure this could work for simulating #water for the whole world (rivers, lakes, and the player could change it all by building dams, digging tunnels, etc.)

There are still many issues to solve, and at this stage the ugly rendering is just a debug visualization of the simulation state.

The library I'm developing for this is #OpenSource (but not ready 😉)

[youen@mastodon.gamedev.place]

I've been working a bit more on #LiquidSimulation for my game, and I'm starting to be happy with the results.

My objective is to simulate rivers and lakes on a "large" world (20km x 20km), and allow the player to modify the terrain, build dams, locks, underwater buildings... This is a 3D simulation, which includes the possibility to make underground rivers (communicating vessels), etc.

As you can see, rendering is ugly for now (not my focus yet)

#Godot #GameDev #OpenSource

[youen@mastodon.gamedev.place]

Another example, with a much higher liquid flow (it comes from infinite water sources). In this example it creates a bigger river that fills a lake. The end of the video is accelerated (it takes almost an hour to fill the lake to that level but then there is not really an upper limit anyway).

The idea of course would be to pre-compute all this so that everything is in a steady state when starting the game. But a player that would break a dam during the game could create this kind of behavior.

[youen@mastodon.gamedev.place]

I've improved a few things and fixed bugs, and now dynamically modifying the terrain correctly impacts the liquid simulation.

Still a lot of things to improve. Rendering something that actually looks like water, adding the pressure system, allowing slices to shrink when liquid level is low, fixing bugs...

[youen@mastodon.gamedev.place]

Testing ideas for my #LiquidSimulation. The data structure to represent liquids in memory stores horizontal liquid slices, which are simply slices of 1m height that can have any shape seen from the top, encoded as an image with 1 bit per pixel.

As liquid quantity increases, a slice can grow lateraly (if not blocked by surrounding terrain), to simulate spreading of the liquid.

What wasn't implemented yet is, if the liquid quantity decreases, then the slice should shrink.

[youen@mastodon.gamedev.place]

Here is my attempt so far. It works quite well in this simple case. It still has the issue that the final shape is a bit random, and growing/shrinking cycles will potentially result in different shapes each time.

[youen@mastodon.gamedev.place]

Doesn't work that well when there is a loop somewhere though. And, again, the problem that the resulting shape doesn't necessarily make sense. This could probably be improved by using terrain height (removing pixels that are at a higher altitude first, so that in the end the path follows the lowest altitude).

But after playing a bit with this idea, I came to the conclusion it won't give good results. A bit sad because it was simple and could have a very efficient implementation.

[youen@mastodon.gamedev.place]

Here is the result in the #FluidSimulation. And it creates quite a mess. I'm really not satisfied.

My next idea is a "reshape" algorithm, that will find the shortest path from input to output (also favoring lower altitude), and then spread that path as much as required to get the desired thickness. However this could become costly for big slices. I'll see how it goes.