Tag Archives: procedural terrain


I've been playing around with post-processing functions (so to speak) on the terrain heightfields. When I designed the current terrain engine, I did so in such a way that terrain chunks have some amount of overlap, with the idea being that a "small amount" of post-processing can be done on the heightfield while avoiding seams. Of course, the only way to do this for anything that requires information about surrounding heights is to compute some redundant information (i.e., to overlap tiles a bit) and discard it.

Inspired by http://www.decarpentier.nl/scape-procedural-extensions, I started playing with using finite differences to modulate the heightfield according to its normal vector. The results are very compelling, although I'm not getting as nice of results as Giliam yet, presumably because he's using an analytic derivative and distorting the input to the noise function, whereas I'm using a finite difference and just distorting texture coordinates.

Certainly looks promising.

GPU Terrain, Part III

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*

GPU Terrain, Part II

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!

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

Bigger Terrain

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.

Big Terrain: Now With Skirts!

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.