Playing with #water in a #godot prototyping project.
Uncategorized
14
Posts
1
Posters
0
Views
-
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)
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.
-
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.
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...
-
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...
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.
-
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.
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.
-
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.
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.
-
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.
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.
-
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.
I've implemented the new ideas, and the #FluidSimulation works much better now ☺️
Arguably, it looked interesting before too, but the result was unpredictable, and completely different before/after a flood.
The new version produces a much more reasonable river bed after the flood. It does leave a few puddles here and there, but that's not a problem, I can add an evaporation system to make them go away after some time.
-
I've implemented the new ideas, and the #FluidSimulation works much better now ☺️
Arguably, it looked interesting before too, but the result was unpredictable, and completely different before/after a flood.
The new version produces a much more reasonable river bed after the flood. It does leave a few puddles here and there, but that's not a problem, I can add an evaporation system to make them go away after some time.
I'm working on the generation of the mesh to render the #FluidSimulation. It's a bit weird with this debug material, but very useful during development. Also, I can now run the simulation in the #Godot editor which is very handy.
Each square is a voxel of liquid (1 meter per 1 meter).
Next step will be the water material (I do not plan to achieve anything photo-realistic, but at least something translucent, with animated ripples, following the flow speed, and maybe some foam)
-
I'm working on the generation of the mesh to render the #FluidSimulation. It's a bit weird with this debug material, but very useful during development. Also, I can now run the simulation in the #Godot editor which is very handy.
Each square is a voxel of liquid (1 meter per 1 meter).
Next step will be the water material (I do not plan to achieve anything photo-realistic, but at least something translucent, with animated ripples, following the flow speed, and maybe some foam)
I now have a system that generates a flow map, and added an actual water #shader to the #FluidSimulation. I used this shader as base https://github.com/marcelb/GodotSSRWater, made some modifications to add the flowing movement and support non-horizontal surfaces. It's not final yet, lot of things to improve, and I'd like to add foam, but it's already really improving the result!
-
I now have a system that generates a flow map, and added an actual water #shader to the #FluidSimulation. I used this shader as base https://github.com/marcelb/GodotSSRWater, made some modifications to add the flowing movement and support non-horizontal surfaces. It's not final yet, lot of things to improve, and I'd like to add foam, but it's already really improving the result!
I have finished implementation of the liquid mesher in a separate thread for the #FluidSimulation, which fixes the remaining performance issues.
And I'm spending way too much time looking at the results, especially when I'm tired 😅 I guess it's a bit mesmerizing.
Each horizontal slice of water runs a micro-fluid-simulation to compute the local flow map, using the "virtual pipes" method, which is nicely explained here: https://lisyarus.github.io/blog/posts/simulating-water-over-terrain.html (thanks to @lisyarus)
-
undefined oblomov@sociale.network shared this topic on
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@magostinelli bello!
-
Anarres del 9 gennaio. Le squadracce di Trump. Palestina. Geografie del dominio. Iran. Crepe nel regime…Anarres del 9 gennaio. Le squadracce di Trump. Palestina. Geografie del dominio. Iran. Crepe nel regime…
@anarchia
ll podcast del nostro viaggio del venerdì
-
@GrapheneOS
OK. But do you see how you're alienating many passionate members of your own community?As far as I can see, you've sent over a hundred posts in the last 24 hours. Nearly all of them arguing with people.
I get that you feel the need to defend yourselves - but, is that the impression you want people to have of the project?
-
Ho incluso un easter egg nel sito, vediamo chi l trova! Con questo indizio è facilissimo: quanto fa 202x2=?
-
@aeva proposal to rename them to Andy (C) and Brian (Eno), respectively
-
@Edent Tuta made a problematic post with many inaccuracies which has now been heavily edited to address many of those. Our replies were made in a different context but are being presented as if they were replies to the current post on their website.
We think encrypted email services including but not limited to Tuta have serious privacy and security issues. Tuta addresses some of these issues not addressed elsewhere but also has issues of their own. That was not the focus of our responses.
-
Wobedraggled (@wobedraggled.bsky.social)
https://bsky.app/profile/wobedraggled.bsky.social/post/3mc3qx5pxnc27
> What are we doing as a species?
-
@EveOfTheFuture correct
