Piero Bosio Social Web Site Personale

@Leviamicky @eniko I completely second this! The sky is the limit 😉

But it's not meant to work that way, such a structure should not be a dynamic rigid body. In the final game you'll be able to choose if you want your design to be dynamic (like a vehicle) or static (for a building, a bridge, etc.) Either way you'll be able to add the same parts, be it to make an articulated vehicle or a hangar door, water lock, or anything you can imagine (hopefully).

On the technical side, the system is quite simple. The beam part is a small #Godot scene consisting of a rigid body with a box collider and box mesh (placeholder graphics). You can then instantiate this small scene at will.

To attach two parts together, I don't use joints (would be bad for performances and physics engine stability). Instead, I merge the rigid bodies, and add all the colliders as child nodes (and also update the total mass). So, the final bridge is a single rigid body.

A bit of stress testing the system, and already found #EmergentGameplay out of a single non-resizable dumb rectangular part 😉

Here is how you can build a bridge, even though you don't have the right parts, and also that you can't (yet) lift or otherwise move your contraption, and deleting parts is not implemented either.

Which means you have to find creative ways to tilt the orientation of the thing during construction and be careful about the weight balance.

#Godot #GameDev #FluidSimulation

I've started working on the system to build machines, which will be a central aspect of the game.

Nothing fancy so far, but I'm making progress. Still need to make wheels that actually roll, add the possibility to lock the direction, and this should already allow building a vehicle.

All in all, I feel this is easier to do with Godot than my first prototype with Unreal Engine.

#Godot #GameDev

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)

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!

#gamedev #Godot

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)

#gamedev

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.

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.

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 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.

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.

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...

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 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

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 😉)

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.

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 😅