And now, for something totally different...naturally, a terrain engine can't hold one's attention forever. I've taken a temporary break to revisit the GUI engine that I started some time ago and left in an embarrassing state. I'd like to start making some stupid, simple game demos, just to have some fun with the engine...but I'd certainly need a tight GUI system for such a game.
So far, I've overhauled fonts, labels, edits, and buttons, and added basic windows and windowing. Everything is shaping up nicely, or, at least, much better than last time. I ended up using a fairly interesting design pattern for the GUI elements, since I wanted to modularize functionality as much as possible without losing efficiency. To this end, I went with a templatized decorator pattern. As in, the c++ decorator pattern, but with templates, so that all code is generated at compile-time and any given GUI object (in theory) becomes the sum of all of its functional parts without the overhead of dynamic linking.
Finally, all the kinks have been worked out (at least for now...) of the GPU terrain engine. Borders are totally seamless, so there are no longer any visible artifacts of the chunk boundaries (note that those first-order discontinuities in the screenshot are from the Voronoi Noise, not the terrain engine!). Looks pretty smooth! I've also got a system in place that should allow for some advanced semi-global heightmap effects like erosion, though I've yet to really put it to the test.
Great! Now, shall we make it adaptive? *shivers*
I'm dreaming...of a white Christmas.
Implementing normal mapping really helped the appearance of the terrain - they can push the effective resolution of the terrains up by a factor of at least 16 or so. The screen shot this time is from a demo that runs at 60 fps on my laptop, unlike the previous one (which ran at ~10 fps on my laptop).
In addition, I've found that Voronoi noise (aka Worley noise) makes a very compelling basis function for the terrain!
I've finally admitted it to myself: CPU-based terrain generation just isn't smart, and it'll probably get crushed by all things GPU-based in the future. Sure, it makes threading and precision easier to deal with, but it doesn't make sense that my current terrain takes about the same amount of time to generate on my Intel HD Graphics-driven laptop and my 560GTX-powered desktop. Why on earth are all those processors going to waste?
So, here we go. My second endeavor into GPU-based terrain generation. I've already come farther than last time, when I gave it all up because of cracks that I thought were the result of GPU precision problems. I managed to solve the crack problem this time. Of course, my skirts were hiding the problems, but it still made me uneasy that tiles didn't line up perfectly - luckily, a little math solved that.
It may look like the screenshot is a regression from my previous shot, but, since it's GPU-generated, it definitely represents a step in a direction that I think will ultimately prove to be a worthwhile investment in the future of XDX's terrain engine. The terrain below is obviously simple: just a single layer of iterated value noise. Building up layers is the next step, and should be relatively easy with a few shaders.
I'm getting a bit better with terrain functions. Slowly but surely...
I started working with preliminary texturing on the terrain, aiming to get some pleasing variation in texture patterns. Everything is still horribly ugly due to the lack of nice textures for grass, dirt, etc. I'll have to go back and revisit procedural textures soon, as the texture quality is becoming an ever-more-noticeable bottleneck on this terrain.
The sky also looks a bit better now. It's not "real" in the technical sense, but at least the gradient looks better than before.
This terrain experiment is shaping up to be a decent little demo...I hope to evolve it into an integral part of the XDX engine over time.
Still working with the new terrain engine. I've decided that overlapping and praying just isn't the right approach - it's way too fragile. Constants like overlap factor and skirt displacement have to be tweaked to perfection in order to get a non-cracked terrain. Rather than spend my time searching for the perfect constants, I've opted for a more fool-proof approach: skirting.
So far, I'm extremely pleased with the results. After fooling with normals and texture coordinates for a bit, I've reached a point where I can't see any anomalies in distant terrain, other than discontinuous normals. Of course, the discontinuous normal problem is a common one and should be easy enough to fix.
When I get some more time, I'll start the arduous process of making it adaptive. Luckily, I expect to face far fewer threading errors this time, since the tiles operate totally independently of one another.