Heightmap generation

Ah, it’s working again.

I apologize for not posting this until now, I haven’t been able to access the blog page during the weekend. First of all, from now on, I will be writing my blog posts on sundays instead of fridays, as it works better for me.

Last week I was creating a heightmap generation tool. As I had written in my project plan, I started off doing this through the use of Perlin noise. I managed to create heightmaps doing this, but I was however not pleased with the result. Instead, I was recommended another way of creating realistic heightmaps. Instead of creating some kind of noise, you would create Diffusion-limited aggregation clusters, and then calculating the normalized value of several differently blurred copies of that same picture. Doing this results in a very realistic mountain range. I decided to go at it with this approach instead.

Now, when the heightmap generation is finished, I will attempt to change the level of detail of the terrain depending on the camera position. Look forward to it!

Level of detail

Ah, I apologize for not posting this post until now, haven’t had enough time to write it during the weekend.

Right now, I have a fully functional level of detail system for my terrain grid (Note that this does not include changing the LOD of the rendered nodes depending on the camera location, as this was scheduled to be implemented later on). I will attempt to explain how I decided to make this work. The different LOD levels are created by stepping through the heightmap pixels using different step lenghts (Right now I use 8 pixel steps for the lowest quality, 4 pixels for the second lowest, 2 for medium quality and 1 pixel for full quality). This, however, is not enough, as it will produce cracks where different levels meet each other, as the pixel that the lower level of quality will skip is probably not aligned with the other two adjacent pixels.

I decided to solve this by making the outer borders of each node use the highest quality, no matter the LOD level. Doing it this way is on one hand heavier for the application to render, as we require quite a few extra polygons. On the other hand, if I had done it the opposite way and used a specific lower quality for the borders, we would be able to spot the node edges much easier as we move around, as the lower quality around these areas will stick out more heavier (While we won’t notice the higher quality edges on the lower quality level nodes, since they’ll be too far away). I could have solved it by continously checking if each node is adjacent to a node with a different quality level, and changing the border edges to match that quality. However, the method I’m using right now is working without any problems, so I’m using it until I am forced otherwise, or I figure out a much better method.

Well then. I think it’s about time to begin looking into the creation of heightmaps. Stay tuned!


Hello again!

Last week, I finshed the basics for the graphics engine. The past few days, I’ve focused on generating meshes from a heightmap. There’s been a lot of bumps on the road (Literally, the map mesh is completely made out of bumps!), and I’m still not completely done, but the least I can say is that I have a functioning prototype. Right now, I only draw the top left part of the heightmap, but I’d say that’s more than enough (Look at the sample below. See that tiny, tiny dot to the far right, next to the corner of the terrain mesh? That’s a box about the size of a person). I’ve tried to get a video capture of the scene, but I haven’t had enough time, unfortunately. Possibly, I might have time to fix that during the weekend.


I’ve had some trouble actually loading everything into the code (There’s a lot of data), but after restructuring the code, I managed to get it working.