Here is the first mechanical part I’m modelling to use as a building block to make machines in the game. Not a simple example, it’s a vehicle wheel, with double A-arm suspension, and direction. I used FreeCAD for modelling, because it’s made exactly for the purpose of modelling mechanical parts, and also, let’s admit it, because I’m not experienced at all with Blender. My goal is to not lose too much time in 3D modelling, but even for prototyping I need something that players can understand when they look at it.

My constraint was mostly to make a modular system, with a single point of attachment (that’s the rectangular hollow plate visible at the foreground in the video), and also as compact as possible, since players will be placing wheels on their own designs, more compact means more freedom. But still have enough vertical suspension amplitude, to accommodate rough terrain.

Next step is to integrate this in the game. For this I need a skeleton, skin the parts on the skeleton, and add textures. None of this can be made with FreeCAD, so this is where I switch to Blender. I’ve exported the FreeCAD model as a mesh, and imported it in Blender. This step is really not ideal, up until now the process was non-linear (if I wanted to modify any dimension for example, I could change it in FreeCAD and it would update the final result). But from this point if I have to change something in FreeCAD, I’ll have to restart all the work in Blender from scratch with the new model.

Here is the result after adding the skeleton in Blender:

Next I’ve added constraints so that the two piston parts remain aligned with each other, the top A-arm follows the bottom A-arm movement, and the spindle vertical axis remains vertical. This allowed to easily create two animations: one for the up/down suspension movement, and one for the direction wheel rotation.

The idea is that, in the game, the physics (Jolt engine) will simulate a vertical spring, so that the wheel can move up and down along a vertical axis. This is a simplified movement compared to the actual suspension mechanism. But it won’t be directly visible. Instead, it will drive the animation, which will rotate the suspension arms so that the wheel ends up at the correct relative height.

Here is the final result: the suspension system, modelled in FreeCAD, rigged, animated and textured in Blender, is now an interactive thing with the physics simulation in Godot:

However, I’m surprised how small it looks in the game 🫣 I should have known better, it’s not the first time I get surprised after spending time working on modelling in very close view.

Anyway, next step will be to make the wheels actually roll. More on that in the next post!

Using Godot, how does one draw an outline around a mesh, for example to show which object is selected? Sounds a simple enough question?

Exploring the new Godot stencil buffer

Well, starting with Godot 4.5, there is a new functionality, which allows to use the stencil buffer. This is an offscreen texture that you can write into when rendering a mesh, and that can then be used to mask out something else later (either when rendering other meshes, or for fullscreen post-process effects).

It’s really simple to use! You want an outline? In your material, select the “ouline” stencil mode in the drop down…

And here you go, you have a nice outline of your mesh (here we see the green outline around the sphere).

Excepted… it’s not what I want. And also, it doesn’t work for a lot of cases.

What I want is the player to see the selected object in all situations, even if it’s hidden behind something else, so I want an X-ray outline. There is a built-in X-ray stencil mode, but it doesn’t do what I want either. It will fill the hidden part of the object with a solid color (instead of just an outline). So I’ll have to use the “custom” mode, much more versatile, but you have to create your own material for drawing the outline in a second pass. Fair enough, let’s do that!

X-ray outline

The idea for this second pass is to draw again the same mesh, with your desired outline color, but “grow” that mesh so that it extends around the original object, effectively drawing an outline. The inner part of this pass is masked by the stencil buffer, leaving only the outline visible. This is almost the same as just using the depth test, excepted for example a character having an arm in front of his body would get an outline around the arm if you use a depth test ; and also the depth test wouldn’t work at all for an X-ray outline. So here I use the stencil buffer to mask the inner part of the mesh when drawing the outline.

It’s still reasonably simple to configure, and you get a nice X-ray outline! It may not be completely obvious here, but the part of the outline we can see through the box is alpha blended, to make it a bit more clear it’s “behind”. Still have to tweak this.

As far as I know, this is not fully documented yet, but to enable the stencil test in your shader, here is the syntax:

stencil_mode read, compare_not_equal, 1

Growing a mesh

But we’re not done yet. You may remember I said it doesn’t work in a lot of cases (and maybe you already know the limitations of this technique!). To grow the mesh, the idea is to move each vertex in the direction of its normal. This works great for “smooth normals”, like for our sphere. But if you do this for a mesh with “hard edges”, each face will move in a different direction, leaving a gap in the middle.

And, sure enough, this makes visible glitches on the outline. When looking at a grazing angle, you’ll even have whole edges missing their outlines.

In addition to this problem, using the built-in “grow” feature of Godot, while it allows to select the outline width, will make the outline look thinner as you move farther away, because of perspective. I’d prefer to specify the outline width in pixels. This is possible by using a custom vertex shader. But it still doesn’t solve the hard edge issues (and the similar issues that can happen with an mesh that is not closed).

There are several ways to fix this. One possibility would be to add two triangles for each hard edge. These triangles would have zero area and be invisible when drawing the mesh normally, but would expand to fill the gap when the mesh is grown. That wouldn’t fix the issue that the outline would look irregularly thinner depending on the view angle though. Also, this would add a significant amount of triangles, and this overhead would apply all the time, even when you don’t display an outline (the cost remains small since degenenerate triangles are not rasterized, but the mesh takes a more memory).

Another approach would be to add a channel on the vertex array to store the smooth normals, only used in the outline vertex shader, to grow the mesh. Probably less overhead, but still a cost on mesh size (I think it could be packed in 16 bits per vertex).

Another way is to generate a different mesh to draw the outline, which will have smooth normals (this could be made automatic, either in editor or at runtime). And I think that will be my preferred option. This mesh is only used for the outline, so when the object is rendered without outline there is no overhead.

An alternative: screen-space edge detection

I haven’t explored a completely alternative route, which is to use a mask, and process it as an image in screen space, with an edge detection algorithm, to render the outline. This allows more subtle effects, such as a blurred outline, and could avoid to render the mesh twice (though not really due to Godot limitations), and would avoid all the issues with hard edges. But a full-screen post-process also comes with a cost. And an additional limitation is that you couldn’t display a different color when the outline is behind another object.

Beside, it is actually quite difficult to implement this in Godot in an efficitent way. The reasons are that there is no MRT support (multi render target), and, more importantly, you can’t specify a custom format for your render targets (as far as I know, they are all 32bits, and I’m not even sure you can avoid allocating another depth buffer). The only way, as far as I know, is to add a secondary viewport, and render your base objects here (so, yes, you still need to render the mesh twice), and then use the resulting texture in the post-process shader in the main viewport. Still, it would certainly work!

Conclusion

What I learned while researching this outline subject, is that there is no perfect solution, you’ll have to choose your tradeoffs. And also, things that might look like long-solved problems are not always so simple to integrate.

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

Here I’m stress testing a bit the system, and already found emergent gameplay out of a single non-resizable dumb rectangular part 😉 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.

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. Of course I also have some code to cast a ray from the camera through the mouse cursor to find the point where the part should be placed.

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. I still have to write some more code to correctly merge multiple inertia tensors. Godot usually makes these computations for you, but it works only in the case where the matter density is the same for all colliders. Here if I was to attach a lightweight wood part to a heavy steel part, it wouldn’t compute the correct mass distribution.

Another note is that it’s not meant to work that way in the final game, such a structure should not be a dynamic rigid body. 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 use a common set of parts, to make an articulated vehicle or a hangar door, water lock, or anything you can imagine (hopefully).

Here is a small technical demo showing what can be done with the Transvoxel terrain and the fluid simulation.

Nothing related to actual gameplay, I’m just using a debug tool to dig spherical holes (it’s actually possible to dig/add matter in other shapes, making planar walls, etc.)

In the game I’m imagining, digging with manual tools would be very slow (only useful to recover small quantities of materials), and the player would need to design and use machines for larger earthworks.

I searched for some time a tool to author a game world heightmap. There are different possible approaches.

• You could draw a heightmap in an image editor, but good luck with that
• You can use tools made to interactively shape a terrain, such as World Creator
• You can use node-based generators which combine mathematical functions to generate a heightmap, such as World Machine or Houdini
• There are also voxel editors such as Avoyd but I didn’t find one with practical edition tools for a big terrain

Now if you don’t have a budget to pay for a commercial tool, it limits the options. I’ve quickly evaluated the following free and open-source tools: HeightMap Editor, World Painter, World Synth, and Hesiod.

And I stopped my search here, when I discovered Hesiod. It’s a node-based heightmap generator, and the only free tool I’ve found that I think can really work for the kind of world I want to create.

Hesiod is surprisingly complete and usable, given it’s mostly developed by a single person. It has its quirks, some things are not finished, some things are missing, but overall it’s a great tool.

Here is a demo of the kind of thing that can be done with a graph of nodes. It’s not really intuitive to begin with, you may wonder “how can you even make a terrain out of a node graph?” and “where do I start?”, but once you get the principles, it’s really powerful. Here I draw some lines that represent the ridge of a moutain chain, and the configured nodes will “extrude” them to create the mountains, and then generate random noise to add details. Finally, an erosion simulation makes it look more realistic (but this last part is still a weak point of Hesiod: it’s there, it kind of works, but I couldn’t get results anything close to what World Machine can do for example).

Here is an early attempt to create my game world, showing how each group of nodes impacts the result:

To give an idea of scales, the map is 16x16km, which means the cliffs on the coast are about 300m high, and I don’t know exactly but the highest mount probably 2km high.

In-game we are really much closer than this preview. So the heightmap needs to be exported at high resolution (my target is 8192x8192, which means one point every 2m of terrain).

I couldn’t achieve such details with real Earth elevation maps, and of course I can’t draw that kind of data by hand.

A difficulty with node-based tool is to find ways to mix your authoring (I need a moutain there, a river here) with “automatic” details generation. A lot of examples begin with a completely random landscape ; you can still choose the density of mountains and things like that, but for example you can not choose where each mountain goes. Instead, the process I’ve come up with is to draw, simple images to define what I want, such as an island shape, ridge line of mountains, path of rivers. These are drawn by hand in Gimp.

Here are all the layers I’ve used: the island in white, mountain ridges in black, and rivers in dark blue.

Then I use nodes to work on this base and turn the images into terrain features, add details, remove depressions created by the random noise, and dig the river beds. Since it’s a non-linear process, I can update the base images and re-generate everything.

To make the rivers layer I’ve used a node of Hesiod “Select valleys” that automatically detects the valleys. The generated image was not clean enough however, and I needed to extend the rivers until the sea, so I edited the image in Gimp and re-imported it in Hesiod. This is not really a good process since I’d need to do it again by hand if I change anything that could move the valley bottom (even the random noise), but it works for now.

Here is the last version so far. The most difficult part is to get coherent river beds (always going downhill, even though the terrain is partly made of random noise).

It’s not finished, but I think it looks cool for a starting point, to define scales and place the main elements.

And here is how it looks in the game, and also with the fluid simulation to have actual rivers infinitely flowing from the sources I’ve placed, until it gets to the sea.

It’s still very empty, but there should be some potential for interesting perspectives.

I’m not completely satisfied with the results though, and I think I have an issue somewhere that makes things smoother than it should, but it still gives a good base terrain to work with. It will necessarily be an iterative process, for example so far I didn’t add trees or rocks, so I can’t really grasp yet what works, what is good enough, and what will need to be improved.

I’m working on the generation of the mesh to render the simulated water. 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 is the water material. I do not plan to achieve anything photo-realistic, but at least something translucent, with animated ripples, following the flow speed.

I’ve implemented a system that generates a flow map, storing the water velocity in each vertex of the mesh. Then I took this shader, and 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!

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. The result gives a map of velocities, and as long as the shape of the slice does not change, this is not re-computed. So while the shader gives an illusion of movement, the flow map is static and only upated when needed.

The simulation is split in chunks, and a mesh is generated for each chunk only when its shape is modified. So this doesn’t use much computation power, since in most cases only a few chunks are modified each frame, most of the simulation is in a stable state. Still, there are cases where more chunks are impacted, so to avoid degrading performances when it happens, I have implemented the liquid mesher in a separate thread.

I’ve also made some improvements and fixed bugs. And I’m spending way too much time looking at the results, especially when I’m tired 😅 I guess it’s a bit mesmerizing.

You may have encountered the issue where your program captures the mouse, and when you hit a breakpoint you don’t get back the control of your pointer to use the debugger? Not very handy, especially if you don’t master the keyboard shortcuts of your debugger (seriously, I need a mouse, can’t do anything without one 😅)

Well, I suppose in a perfect world this should be handled at the OS level, but I’ve found a workaround (tested on Debian, with an IDE that uses GDB as debugger):

first, apt install xdotool

then, edit or create file ~/.gdbinit, and add the following in that file:

python
def ungrab (event):
    gdb.execute("shell xdotool key XF86Ungrab")

gdb.execute("shell setxkbmap -option grab:break_actions")
gdb.events.stop.connect(ungrab)
end

Restart your IDE, and you should be all set.

What this does, is that when GDB stops the execution of a program, it sends the keycode XF86Ungrab which asks the OS to release the mouse grab. Works flawlessly for me!

Testing ideas for my fluid simulation system. 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.

This idea 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 game. 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.

After implementing this idea, the simulation works much better ☺️

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 realize I’ve never presented any overview of the game I’d like to create. So, let’s try to introduce it here.

The core idea is a construction game, where the player can build various machines and buildings (hence the game codename “Engineer”). Similar to what can be done in Kerbal Space Program. Except not in space. This would range from vehicles (trucks, trains, planes, boats) to automated factories, hydraulic power plants, navigation locks, etc. With an emphasis on emergent gameplay, using very generic parts that players can shape and combine to create functionality.

Here is an old prototype I made with Unreal Engine showing some ideas. I’ve now switched to Godot, which means I’m basically starting over. But Godot is really more aligned with my values, objectives and constraints (free-software game, compatible with old hardware, slow development).

Now that I have a basic landscape and water system, my next focus will be to implement the construction mechanics in the Godot game.

The code is here if anyone is interested https://git.engineer-game.org/Engineer

There would be a resource gathering and refinement system too, based on kind-of-realistic mechanics. The idea is to reproduce real life technology advancement, starting from almost nothing, but with modern knowledge.

Which brings us to the game plot. I always feel that pure sandbox games are kind of boring. Even a simple plot can add a lot to drive the player towards various goals, motivate exploration, create challenges. I already have an overview in mind, whose main themes are ecology, natural resource depletion, and technological domination. But I still need to structure and develop it, and find ways to integrate it in the game without introducing too much work load.

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)

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

After a few improvements and fixed bugs, dynamically modifying the terrain now 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…