Devlog 21 - Ship Prep!!!

Colours

I added colours to the terrain depending on how high the vertex is. This does create a very harsh border between the two colours, but I didn’t want to learn lerping, ik how to larp enough.

Cleaned up my commits

My commits were, and probably are still messy, and when I went ahead to revert some changes it said there were errors, but now thankfully that’s all fixed. :)

I also updated quite small normals and some technical stuff.

Devlog 20: GPU noise

I found a way to make noise using a Godot addon called FastNoiseLite Runtime Shader. It was apparently identical to the FastNoiseLite in GDScript. So I gave it a try. I knew it was a gamble, given how much time I got left to ship an decent project, but I gave it a try since it seemed interesting. It wasn’t that hard to get the noise working, but to get it to sync with the collisions was a nightmare. In the end, I decided that even though the README stated it was 99.9% the same, the output seed by seed was different. So I decided to scrap it and now I’m going back to the old version with heightmaps.

Why did I really want to switch?

Because of the limited colour depth in images (has to be 8-bit for GDShader to read), theres not enough heights for each vertex to be at, so every so often, there’s this massive wall. It looks fine from afar, but thats probably because my terrain is 20km x 20km, so of course an 8m tall wall would look fine.

(the image is from the addon readme)

Devlog 19 - Main Menu Added (and other things)!

I spent quite a lot of time making the background for the main menu in Blender. After just copy and pasting the player model used in the game, I went ahead and made the main attraction: ✨ the planet in the background ✨ .

My knowledge of noise that I gained from my previous attempts at the terrain generation helped me create the stars in the background, and the texture for the actual planet in the shader editor. I also added a slight atmosphere, which is (somewhat?) noticeable.

I also went ahead and updated the shader code. Before, I used to use the visual shaders, since it was quite similar to the shader editor in Blender, which I was familiar with. But then I realised there’s just more flexibility with using GLSL. I can group uniforms in the inspector, making it clearer and less cluttered if I want to add textures in the future, including different images for the same texture (like Ambient Occlusion, Normals, Colours, and Roughness). Thus being able to group those different types images for the same texture was very important for future usability.

Thankfully, Godot allows you to see the shader code that is generated from the visual shaders. Unfortunately, it was not readable at all. The generated code used a random(ish) collection of numbers and letters, and it was too long. Look below for the comparision for just the vertex shader, but it was something like 84 lines that was shruken down to 10 for the vertex shader. Even if you account for spaces in the generated code (which then it might be like 50-60 lines) thats a huge difference. So it took quite some time to get it to a readable state.

edit: idk why the actual background looks so bumcheeks compared to the banner, hopefully itll be fixed by then 🤞

Devlog 18 - I am happy once again!!

I FINALLY got the collisions to work!!

Basically, it looks at the terrain model that is imported into Godot, and aligns the vertices of the CollisionShape3D with it. It also updates its position every time the player moves 1 unit (whatever the size of a quad of the mesh is). Then it looks at the heightmap, looks up the height of its coresponding pixel, multiplies that by the height shader param (2000, like in the vertex shaders), and thats the collision shape done.

I noticed while walking around the world, that there were these massive ridges on the terrain. This is due to the lack of precision in the heightmap. The heightmap only has 256 shades of grey, and I need 2000 values. It is quite impossible to make a image file with that much precision, so instead, I’ll make it so that the CPU will just send an array to the vertex shader.

Also, I’ve rebranded my project to Worlds Unbound, and this specific Stardance project will just be handling the terrain stuff for the game.

p.s, it never goes above 16ms, i think thats probably because i was recording

Devlog 17 - I am incredibly frustrated.

No matter what I do it feels like I just can’t get the collisions to work. Basically, I’m trying to fetch the heights from the height map to input into the CollisionShape3D, but the coordinates are always offset in some way or the other. I even used AI my friend to basically rewrite the entire script over and over again, but that didn’t work either.

Maybe it’s cos school has started now, and I haven’t been able to spend that much time on this project than I would like to

As you can see in the photo, the collision mesh (in blue) is offset from the normal terrain (in white)

Devlog 16 - AMAZING PROGRESS!!

I’ve managed to get a massive 20km render distance with huge mountains and ridges using FastNoiseLite and vertex shaders. I used devmar’s terrain technique, which he named the “Wandering Clipmap Terrain Technique”.

The reason why the technique is called the “Wandering Clipmap Terrain Technique” is because a flat plane that is subdivided a bunch (to make varrying levels of detail (LODs)) that follows the player. The vertex shaders then offset the heightmap so it gives off the illusions that your moving about in a massive world.

All the displacement is done by the vertex shaders, which looks at a heightmap. In the future, I might make this heightmap be generated in gdscript instead of in the inspector, to deal with texture resolutions. Currently, from afar, the terrain looks amazing (except from the fact its not textured) but upclose, you can see rings in the terrain, which is caused by the heightmap’s resolution being too low. In fact each ring is about 8m tall so I really need to fix that 😭

The normals are calculated by just copying the heightmap and setting it ‘as normals’ in the inspector. They also are multiplied by a normal basis matrix, which allows me to configure the specific normal settings. I’ll need to calculate the normals in the fragment shader as well in the future for more convincing shadows, but for the mean time, the vertex shaders should do just fine.

I’m planning on adding collisions, then maybe textures, biomes and vegetation soon!!

Devlog 15 - I’m an Idiot

For the past 95ish hours, I’ve been working on a way to make procedural terrain for my game. I tried 2 main methods, one centred round the CPU, and one I was building centred around the GPU. The endless chunk seam bugs caused me to burnout/get tired of the entire project, and there was so many stuff (that I won’t really be explaining for the sake of my poor reader’s sanity) leading to me ✨ youtube ✨
I saw this AMAZINGLY smart video by devmar, showing an alternate way of generating terrain.
I urge you to watch the video as well, the whole technique is very very clever, and he even goes on to make further videos on making collisions, recalculating normals and adding vegetation, especially if your interested in procedural generation.
After watching this video however, I became incredibly frustrated. I spent nearly 100hrs of my summer making this procedural terrain which I know hadn’t gotten anywhere and theres this incredibly smart video from 4yrs ago that pops up on my feed.
Welp, now ig i gotta try out this way, and quick cos my parents are on my tail talking about me finishing this project before school starts 🙏 (its my gcse year so ig its valid but still )

Now what I actually did that counted to my time

Experimented with vertex shaders, and sending heightmaps to vertex shaders to displace. This however caused immense lag and caused VERY ANNOYING chunk seams. #epicfails

Devlog 14 - LOD chunks ——— OPTIMISATION IS SOO HARDD

10hrs to do practically do something I’ve already done? (i had already made a chunk system in previous devlogs)

Well, whilst some of that time was transferring code from my old commits to the current one and making sure it works, most of the time I spent on this devlog was spent on ✨ “optimisation” ✨

Optimisation

First of all, I added LODs into the chunk mesh. What this means is that since further away chunks take up less of your screen, the level of detail (LOD) is reduced the further away it is. I had already made the script that handled the creation of those different meshes with different LODs, so in this devlog, I added it to the main terrain generation script, and assigned each LOD to a certain distance, so that any chunk with a certain distance has a certain LOD.

In my last version of the terrain generation, I relied on the name of the MeshInstance3d nodes created to identify what chunk they were. I realised when making this updated version that it was prone to failure, since if the node did not exist or a node with the same name were some how added to the scene tree, errors would be raised or at the very least, a logic error would occur. To recetify this, I switched to using dictionaries to house all the information of all the chunks:

chunks: Dictionary[Vector2i, int] = {
	Vector2i(0, 0): 0,
	Vector2i(0, 1): 0,
	#etc
}

The key is chunk coordinate, and the value is the LOD (0 being the highest, 4 being the lowest)

Every time I wanted to update the terrain, I would search the scene tree if a particular node was unwanted (again, by looking at the name) and then generating the rest of the ones wanted.

This way would not work with LODs, since some chunks may still exist, but may have to change LOD depending on where the player is. So I made use of the dictionary and also created a new one that would store the chunks that I want created. It would loop through the dictionarys, checking certain conditions, and the terrain would be updated. All this looping is somewhat inefficient, and did cause some lag spikes, so I will try to fix that next devlog by only checking the chunks that would be affected based on which way the player moved.

To help with the looping, I created chunk and lod lookup tables, that can be offset based on the players_position. These lookup tables are only changed when the render distance is changed, so the same calculation doesn’t have to run hundreds of times in 16ms (60 fps).

Devlog 13 - LOD template

I basically deleted all the old code, and started over, by making a function where the noise will be given to the vertex shader, and one that will generate the actual flat mesh for it (which is going to be changed by the vertex shader).

I made the template for making flat planes with different levels of detail (LOD), which will be changed by the vertex shaders, applying the noise to the mesh.

I created a new script called lod.gd and gave it a class name, so that I can call multiple instances of it in the main terrain generation program. Every time the program wants to make another chunk, I have to pass the arguements:

• resolution - what ive defined as a synoymn of LOD
• chunk_pos - where the chunk is

The function then loads an ArrayMesh from a pre-generated list of possible meshes and creates a new MeshInstance3D node to display it.

Extra stuff

I also added player coords and chunk position in the debug_screen :)

Devlog 12 - General updates 3.0

I PROMISE THIS IS THE LAST ONE GUYS 🙏

Performance Stats

I added a little HUD showing the FPS, the time it takes to make one frame (has to be below 16.67ms (60fps) or there will be noticeable lag), and the memory usage.

Lighting, Shadows, and World Environment

I slightly changed the shadow bias and normal bias so that shadow artifacts are to a minimum. On top of that, I set it so that shadows aren’t cast for the terrain, which unintentionally handles with some of the artifacts, whilst keeping the “shadows” by illuminating the terrain depending on where the DirectionalLight3d is, making the “shadows” reponsive to a future day-night cycle. Also the volumetric fog and lighting looks better

Camera Issues 2.0

So previously I had the player hide() when you go into first person, but that also effects the shadows. So instead I made the visor disappear when you go into first person. But then there was another problem. The head would move during the idle and walking animations, which is quite distracting and could be problematic for some players. So I stopped the animtions whilst in first person. It is a very rudimentary fix, since players can look at their shadows and see the lack of animation. Furthermore if I want to add multiplayer in the future, it’ll look very weird.

Performance checks

In preparation of the biome generation, I wanted to make sure the performance is fine. It takes a bit for the terrain to generate at the start, but thats common across nearly every game. And this will be lightened a bit when I implement LODs. Once the game is running, it runs relatively fine, except with (very quick) lag spikes when the chunks update. To address this, I’m planning of offloading some of the terrain generation to the GPU, which can calculate normals a LOT more effeciently and quicker than the CPU.
Current, the CPU calculates all the vertices, indices, normals, and then compiles it into an ArrayMesh, which is given to the GPU for rendering. This can put a lot of strain on the CPU, especially later down the line, so it’s better and more effiecient if the GPU does the very repetetive calculations, by making it do all the normal calculations, including other stuff.

Devlog 11 - General updates 2.0

Editor Tools!! - (to see the terrain in the editor)

So in a previous devlog, I think I talked about how I added @tool in my terrain generation program to be able to see it in the editor. Once I made it dependent on the player position, it didn’t generate in the editor because the player wasn’t loaded in. So now I made it so that if the script was running while the editor (not the game) is open, the terrain would generate around (0, 0) based on how ever big the render distance is. Also I made it so that if you tweak the value of any of the primary noise settings in the editor, it updates in the editor.

On top of that, I set the viewport to display wireframe so that I can see the triangles at different resolutions, which is where I came across:….

FLOATING POINT ERRORS!!! (yay )

I noticed that if I set the resolution to a decimal value that was not a power of 2, the triangles would be off by some amount, causing neighbouring triangles to overlap each other, causing normal and collision problems. The resolution variable is going to be eventually used for LODs, so since I’ll be the only setting it, I’ll just make sure to use a value thats a power of 2

The reason why this happens is because 16 (my chunk size) can be multplied and divided by 0.125 (2^-3) evenly to create an integer, compared to 0.1 which results in 1.6. Any smaller power of two is rounded it to the nearest 3dp, so 0.0625 (2^-4) doesn’t work.

Camera Issues

So I made functionality with the camera where you can scroll to zoom the camera in and out, and if you scroll far enough in, you’ll be in first person, much like how it works in Roblox. There was one problem though. Since the material for the visor on the player model was somewhat transluscent, your view would get darker. Also, you could free look inside the helmet, looking at the areas I wasn’t bothered to model and texture hadn’t modelled. So I disabled that in first person.

The biggest timewaste of my life

In an attempt to offload some of the generation to the GPU for more effecient parallel processing, I tried to figure out which parts of the algorthim were going to be handled by the CPU and GPU. There were some that had to be handled by the CPU, and there was no choice about those, and they were: collisions and figuring out what chunks should be rendered. At first I thought, how about I offload nearly everything to the GPU, including the noise function. Then I learnt that FastNoiseLite didn’t exist in .gdshader. So I did what any normal person would do, and CODE PERLIN NOISE BY HAND. I spent HOURS learning everything my dumbass could about it: vectors, normals, gradients, deviation, erosional generation, and finite difference approximation. At least I probably learnt something useful for FSMQ 🤷 (a British maths exam most students do in yr11 along with their other GCSEs).

Devlog 10 - General updates

Alright, so ik I said I would work on the procedural terrain, but instead I worked on:…

Debugging Tools!! (yayy! )

When tab is pressed, it toggles on debug mode, where all meshes turn into wireframes (to check LOD) and chunk boudaries are shown. There are problems with chunk boundaries not despawning when the terrain its on is gone, but that’s fixed when you toggle debug mode again :). I could fix it but icba I have other stuff that needs to be prioritsed.

Resizabile UI

So before, if you resized the window, the pause menu and settings menu would be offset from the centre and wouldn’t scale with the window. Now when you scale it, the pause and settings menu stay in the centre and scale accordingly.

(the flickering in the video is just an artifact created by the godot editor, and will apparently be fixed once exported)

Devlog 9 - Player Animation!!

Walking and Idle Animations

I finished a basic walking and idle animation for the player. The walking animation is also somewhat inspired from the kerbals from KSP. Both the animations are kinda choppy, especially when the animation loops round, but frankly icba I didn’t have enough time to fix them rn (mbmb 😭 ). Thankfully the walking animation is timed properly so that the player doesn’t look like its sliding around.

Camera updates

I added functionality to the camera where you can freelook around the player when holding the right mouse button. Once released, it goes back to the normal position (motion is lerped).

Prepartions for next steps

For the next steps, I want to go back to the terrain_generation program and start to add variation across the world (like biomes, mountains, etc.). I’m also looking to optimise it, making it generate terrain and collisions faster in prepartion for any future implementation of faster travel. So I added functionality that can allow me to make LODs, which will likely be implemented next devlog.

Devlog 8 - Player Model and other assets!

Player Model

I finished with texturing, rigging and weight painting.
Next Step is to make the walking and jumping animations.

Worked on the settings menu

I updated the setting menu layout to account for different settings I’ll add in the future

Stupid Bugs

So when trying to break the terrain generation, I set the speed of the player to like 300 (which it will never be in the game except when in a space ship) but when I tried to do that, the game kept crashing, spitting out an error saying that something didn’t exist. It was coming from my unload_terrain() function. Basically how it works is it checks for all the instances of the MeshInstance3D node, and checks the name of it. For every chunk that is created, I assigned a unique name to it on creation based on the x and y coordinates of it. The function would checking all the nodes, and seeing which ones were out of the “collision_chunk_size” radius, and then would delete them. But when going super fast, the processing of things got all weird, meaning that when it tried to delete a chunk, and if it didn’t exist, it would crash. So I added a simple if statement if len(child_name_array) > 2: (basically it would check if the length of the name was long enough to see if there was the coord data). Stupidly I wrote the greater than sign the wrong way round, which led to me being stumped for SO long on why the terrain was just not unloading.

tldr: > was the wrong way round and cost me hours.

Devlog 7 - Chunks #2: PROCEDURAL GENERATION DONE (mostly)

Bugs

Managed to fix all the bugs related to this part of terrain generation.

Weird chunk errors

There was an if statement (I changed it out for something else that’s more efficient) that was like:
if abs(player_position.x - chunk_pos.x) > collision_chunk_size or abs(player_position.y - chunk_pos.y) > collision_chunk_size

This logic error create weird stuttering issues and lag. The fix was to switch or with and.

Normals

DEFINITELY the bane of my existence. I know roughly what normals are due to me doing 3D modelling/rendering, but I have no clue how it actually works. And plus, I’ve barely covered the maths I need for this in school, so I spent sooo much time (much of which wasn’t recorded) just researching about normals and how they work.

I think that definitely helped me find a solution to the annoying chunk borders and random artifacts found inside each chunk.

Chunk Sizing

I stupidly and randomly changed the chunk size from 16 to 10, which worked completely fine, except for the fact that the player script was still using the 16x16 chunk system, causing the generation to lag behind, eventually leading to the player falling off the map.

New Features

There were also some ✨ features ✨ that I added.

Colour

I added colour to the world, and if I match it to the fog and sky, I think it would look AMAZING

I will make it so that the colour does vary across the planet.

Player

I added the rig and refined the topology for animation.

Devlog 6 - Chunks #1

Previously, I had it so that the entire world was one big mesh, that could not be expanded without unloading and reloading the whole thing and more. This is obviously very inefficient, especially if I want the terrain to load in and out based on where the player is. Chunks is the answer to that. Split the world into chunks of your choice (I chose 16x16), and load/unload just the chunks you need to, not the whole thing.

It seemed easy for me at first, clearly it wasn’t (the #1 for the header, ik this isnt gonna be the only devlog on this 😭 ).

Bug 1 - The Normals aren’t normal

Last devlog, I talked about calculating the normals, which went smoothly… For the old mesh…

You see, to calculate normals, you need the vertices surrounding the vertex your trying to find out, and with chunks, that meant every 16 vertices, the normals were being calculated incorrectly, causing seams to be found in the terrain.

However, since we did calculate the normals (for the most part) some pretty nice shadows have been cast on our terrain.

Despite it being a bug, it is useful to find out where the chunk boundaries are, which is EXTREMELY useful for debugging, so I haven’t tried fixing it just yet.

Bug 2 - Not so Good Performance

After dividing the terrain into chunks, and making new chunks generate when the player moved into a new chunk, I tested it out. And every time I tried to cross a chunk border, there would be a huge lag spike. This would be caused by the fact the game prioritised the generation of chunks instead of the game. Thankfully I was able to make it so that the chunks would load whenever the processor was ready, to make sure not to overload it too much.

Bug 3 - (Lack of) Collisions

Another reason why chunks are useful is for limiting the area with active collisions. When the terrain was one big mesh, the entire mesh had active collisions, which would all be checking if something hit it, which is very resource intensive. Which is why I limited the area with collisions to a small radius around the player. While coding it, many logic erros came up, such as one that caused the collisions to just not work.

Devlog 5 - Procedural Terrain (FINALLY!!)

I made a start at making the procedural terrain, made some progress with the player model, and with configuring the basic shaders of the game.

Elephant in the Room - Procedural Terrain

Technically calling it procedural terrain is cheating a bit, cos really all it is right now is perlin noise applied to each vertex’s height. And with that, you can change the shape of the terrain by changing the values of some variables, like the seed, frequency, and octaves. I exported these variables so I could change them in the editor, and added @tool at the start so I can see it in the editor.

I’m starting to work on a chunk system at the moment, which will load and unload chunks of the world as the player moves about.

Player Model

I finished modelling the player (added this version to the game) and added the bones for rigging, except when I move the arm bone, the helmet deforms, so next time I will be doing some weight painting

Thankfully UV unwrapping is done as well so I should be able to texture everything before the next devlog.

Also, addressing my last devlog, I said Lapse wasn’t syncing with hackatime. Turns out, if I just told it to create a new project called Celestial (which is what my project is called on hackatime), it’ll just add the time to it, so thats amazing!!!

The WorldEnvironment Node

I accidentally deleted my old configuration of this node while experimenting with stuff, and so I made some changes to the shading of the world. Next up is to recalculate all the normals of each triangle so shadows can be cast properly.

I tried using SSAO, but every time I used that to make some sort of shadow, it changed depending on where the camera was and it made the terrain very pixelated.

As you can see in the video, you can see the outlines of the terrain. That is because of the volumetric fog added. It sounds resource intensive, so if it starts to lag out my game I might remove it, which is a shame cos it looks really nice.

Devlog 4 - A little bit of a few things

I mostly did a combination of small bits, which is probably bad in terms of github commits and actual progress, but at least it’s not burning me out because I’m doing whatever part of the project I fancy at the time.

UI

I spent most of the time making a (hopefully) futuristic(?) looking pause menu that can also redirect you to a settings page, where I’m planning to hold the settings for terrain generation for the player to manipulate. Much of this time was spent experimenting with different Control nodes, finding out what they do and what they’re helpful for and manipulating the styles of them. I ended up with a style shown below 👇👇👇

Player Model

I think I’ve finalised on a particular style, now I basically just have to make it and then texture it. The sad thing is that for some reason lapse doesn’t recognise my hackclub project anymore (already logged 5+ hrs on lapse), so all the time I spent on Blender wasn’t actually logged. If someone could please tell me how to fix this or if theres an extension for blender that would be SO helpful 🙏.

Extras

I also added the devlogs to my repository, it should appear there when I next commit, which should be soon!!

I realise that the popular devlogs have assets from the get-go, so I probably might focus more on that, despite lapse not working if I wanna record time on Blender or Affinity. Again, if someone could please tell me if something is up with lapse or if there’s an extension that I can download for Blender or Affinity, that would be SOO helpful!! 🙏

Devlog 3 - Flat Plane

I know this sounds INCREDIBLY trivial, but I finally figured out how to make a flat plane in Godot, that can be used to make an actual terrain.

There were 2 main ways that I could have used to make this:

Method 1:

I can use a PlaneMesh and then subdivide it down into triangles. Then use vertex shaders or custom scripts to displace the plane as a whole based on noise.

It is faster to make the flat plane using this method since you give Godot most of the control over the tessellation, and the individual vertex placement. This means however that it is a lot harder to load and unload certain parts of the terrain, and it is generally harder to add noise to the terrain since you do not have control over each vertex.

Method 2:

I can use an ArrayMesh, where I create the grid from scratch, telling Godot how to connect every single vertex to create triangles. The downside to this is how long this took. I know it seems short compared to my first devlog (I think the main reason I took so long in that one was not only because I was learning Godot, but it was also because I was experimenting with player models on Blender but hopefully now I’ll be more time efficient) but it is still more time consuming to tell Godot how to connect each and every vertex. I was in fact so stumped on how to go about doing this that it suddenly came to me when I was playing with my little cousin. I even noted down how to do it on my phones notes app (excuse my bad handwriting I was in the car writing with my finger) :/

Despite it being longer to setup, it is overall better for the needs of my game, since I’ll not only need to be able to change the height of each vertex based on a heightmap, but it can also aid with making biomes, by adding custom values to each vertex, which is simply not possible with PlaneMesh. It is also easier to load and unload certain parts of the mesh, and it is better for larger maps, since your CPU isnt doing all the hard work of choosing all the vertices and indexing them.

In order to make the actually interesting part of the terrain (which btw I haven’t done in this devlog, I guess this is just like a future plans part) I can use either vertex shaders or custom scripts to make noise in the terrain. Both of these have their respective use cases, and I wouldn’t be able to say one is better than the other for my case.

Vertex Shaders:

GPU based
no collisions (purely visual)
written in Godot Shader Language (which is written in C, which is terrifying for me who practically only knows Python (GDScript and Python are similar enough for me))

Custom Scripts:

CPU based
can create collisions (actually changes the vertex’s height)
written in GDScript (happy days (ik I can write it in C#, but I’m staying far away from that))

Despite my fear of anything not similar to Python, I will still need to use vertex shaders. And I will explain that in my next devlog because this is getting too long.

Now onto my struggles incredible skill when making a.. flat plane in Godot.

I chose to do Method 2, because of it’s functionality later down the line. But that means I have to tell Godot what vertices to make, and how to connect them up. Obviously that was as simple as could be.. (you can see my failures in the screen recordings below)