Well then, let me start by showing off how my glorious terrain looks like right now:
 |
Yup, that's it.Pretty basic... |
 |
| Zooming |
It doesn't really look like much now, but that piece of land there stretches to infinity and beyond. What I was trying to say metaphorically(but failed miserably) is that so far my game generates infinite procedural terrain in both directions.At any given time, the game only generates as much terrain as is needed. That means memory is used efficiently and the game usually runs smooth when not viewed from extreme zoom-out distances.
The game renders terrain using small "chunks" to represent each material block, unlike minecraft where the term chunk is used for a bigger terrain zone. In the picture on the right, I have taken many screenshots of the game at different zoom levels. 1x is the default level and the level at which the game will be played. It strikes a balance between detail and performance. I have made these screenshots in wireframe, so that you can see how much the data increases in size when the view is zoomed out extensively. As you can see, the last picture doesn't even look like wireframe anymore, that's because the individual chunks get to be less than a pixel wide. At this zoom-out level, the game was running at about 5-10 frames per second. I will work later on changing the level of detail when there is much land to be rendered. That means I will try to use less chunks to represent the same amount of terrain, because at such high zooming out, you don't really see the difference.
As you can see, some chunks are red. Those are "border" chunks. When the camera goes in a direction and terrain must be generated, for the player to view and play on, a whole "parcel" of land is generated at once, that is because of the nature of the generation algorithm(more on that further down). The border chunks simply show where two such parcels meet. When a whole parcel of land is out of the view(together with the border chunks), it gets deleted from memory, releasing all that precious RAM we pay so much for.
 |
| Terrain editing(digging) |
There also is a chunk with blue outlining. That is simply the chunk which lies underneath the mouse. I use this in order to be able to modify the terrain(e.g.: to dig out caves). So far I cannot create caves procedurally.
 |
| Midpoint Displacement |
So how about this whole generation thing. How does it work? Well, I use an algorithm called "Midpoint displacement". Basically you take a line and find its center point, or "midpoint". You then move, or "displace" that point up or down by a random amount. You repeat this procedure until the terrain looks smooth enough. Each time you do this, is called an iteration. In the picture to the left I have taken some screenshots that illustrate clearly how this algorithm functions. In my opinion, it works wonders. As you can see, with each iteration the terrain gets gradually smoother, but also more complex. The number of chunks actually doubles with each iteration. In my game, I use 8 iterations, as they are detailed enough to look pretty smooth, but also not too detailed, so as to not have performance issues.I have put some links below, in case you wish to read more about this method.As you probably figured out by now, with this algorithm I can only generate whole "parcels" of terrain at once, rather than generate only one chunk and use that, but it is worth it, because, in my opinion, the terrain looks pretty natural and has great variation, so it doesn't get boring.
I am currently working on cave generation and I guess it's gonna take a long time before I get it right. Until then I have a few ideas for funny posts, to loosen up from two posts filled with serious and formal language(god, I don't even recognize myself anymore! :)). Until the next post. Stay lazy, it's good for you!
Foarte tare!
ReplyDelete