Tag Archives: terrain

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.

Exploration

Wow, this is addictive! Over the past two days I roughly quadrupled the performance of the terrain engine. I also cleaned up some of the threading and moved normal generation to the threads, so now there are almost no hitches in the framerate while traversing the terrains. In fact, the terrain engine is almost to the point that I think fairly high-speed flyovers should be possible in spaceships. That'll be nice, instead of having to heavily restrict atmospheric speeds just for technical reasons.

I'm having loads of fun exploring new and ever-more-complicated terrain functions!

Note: the level of detail shown in this screenshot is probably not realistically feasible for games. The terrain function is insanely large, and takes too much time to compute for high-speed traversal to be possible. However, it may still be possible to walk the terrain without running into problems.

Finally, an Adaptive Terrain

It's nothing special. Quadtree-based with multithreaded, CPU-side generation (no framerate stutter, not quite as fast as GPU, but high-precision). Effective resolution is 262144 x 262144, rendered using 33x33 nodes with maximum depth value of 13. Extremely detailed when zoomed in (exceeds resolution of height function). Super-fast high-altitude flybys are still pretty rough, as the threaded queues get clogged. Still working on solutions for rapid regeneration. No crack-patching (yet). Basic, but beautiful.

Finally, a terrain that is, without a doubt, better than the ones I made in Esenthel so long ago when I didn't know a thing about graphics programming.

23kb executable. Procedural is the future.

Landscape in DirectX

The XDX Engine has come a long way this month, as proven by the screenshot below:

Real terrain, a skydome/clouds, distance fog, and a lovely bloom filter make this scene far more appealing than the previous landscape tech-demo. I'm excited about how quickly the engine is progressing. I believe that I will soon be getting nearly the same results that I achieved with Esenthel!

I've really been focusing on size optimization this month, and I think it shows. After UPX compression, the demo from which the above screenshot was taken is only 25kb. When you think about the fact that this entire executable, which generates a procedural landscape and sky for the user to explore, fits in roughly the same disk space as a small word document, I think you'd have to say that my optimization endeavors have been successful. The XDX Engine is lightweight, there's not really any doubt about that.