Okay, I could not get it to work all during initially filling the volume (the neighbour estimation was either too bad or too slow), but I managed to speed up the additional xz-direction smoothing a lot.
So instead of 2 seconds, it now takes ~0.4 seconds for the 500x500x500 volume.

Here are a far away and a close up picture of how it looks now:
Far away
Close up

As you can see, very smooth and no more terrace.

Next step will be to introduce overhangs. I'm curious how that will work out
Btw. once I'm finished with my research here, I'm going to pack this together into some kind of Showcase-Diary-Topic.

_________________
My site! - Have a look
Also on Twitter - with more ketchup

Wow, looking really good. I look forward to reading your overview.

_________________
Matt Williams
Linux/CMake guy

Moar progress!!

My test to introduce overhangs to a heightmap-based terrain achieved first results.

Here you can see them:
From afar
Standing below some kind of overhang, looking upwards

As you can see, from close, some of the overhangs do look pretty good. But from afar, it just looks pretty weird and "artifact"-ridden. Of course, much of it is due to me only applying one texture to the whole terrain, no trees, no correct shadows, etc. but still too strange.
There is a lot room for improvements, but those improvements basically mean fiddling around with noise values, and other tweaking. I will do that when I find the time, but I'm not going to do it until it looks totally awesome, as it is basically just a proof of concept.

What I did for these deformations is basically the following:
I create two 3D noise maps (lower resolution than terrain). Then I clone the original volume (one becomes the "old" volume, one the "new").
Then, I iterate over each y-layer of the new volume and each x/y coordinate inside that layer and apply a randomized offset to each x/y coordinate based on the two 3D noise maps, so we get xOffset and zOffset.
Then, I apply to the x/y/z voxel of the new volume the xOffset/y/zOffset voxel value of the old volume.
When done with every coordinate, I delete the old volume and smooth the new volume 2 times (more would look even better, I guess), then I generate the mesh form it.

So what this does is basically displacing each coordinate in each y-layer in a way that is randomized, but still coherent as it is based on the "orginal" volume and the offset is applied via coherent noise (instead of wild gibberish).

That is of course quite the hassle and cost me quite some brain cells to get the theory right, and I begin to think that it would work better (if a bit slower) to simply generate 3D noise form the get-go and create the terrain from that instead of from a heightmap and then displace it.

Also, I switched the used noise library from noise++ to ANL (Accidental Noise Library). ANL is slower (as it isn't threaded), but the flexibility is astonishing. Have a look at the docs.

_________________
My site! - Have a look
Also on Twitter - with more ketchup

Looks good!



I guess it depends how much artistic control you want over the output. If you are starting with a heightmap then this actually gives you quite a lot of control, and you can make sure that your hills and valleys all appear in the right place. With just 3D noise you can get some nice (and infinite) results but there's a bit more luck involved as to eactly what it looks like.

For what it's worth, the terrains in Voxeliens were all generated procedurally though of course they are much smaller than yours. We generated over 100 and just picked the nicest ones to be included in the game, and also did some minor adjustments by hand.

Also, you've seen this article: http://http.developer.nvidia.com/GPUGem ... _ch01.html ?



Yes, I've seen that library and it does look very interesting. I'm sure you've seen this page and the images at the bottem came from PolyVox. I'm not sure how actively developed it is though, I couldn't see any commits in the repository.

Not necessarily, I think. With something as flexible as ANL, I could easily imagine using different combinations of noises, offsets, constants, etc. all depending on the biome.
So, the "thinking" of the responsible function would be: "Ahhh, you want the value of the voxel at x/y/z! Okay, that means we#re in the plains biome and I have to chain this and that and this... *strange noises* then flatten it a bit *boing!*, apply an offset. Done! Here you are! *ka-ching*"



Haha, yeah the famous GPU gems 3 Chapter 01. The article is nice, but IMO completely useless for any real world application. It has all the terrain info in the GPU, but a game actually needs it in the CPU for AI, physics, pathfinding, etc.
So that would make you end up doing the same algorithm twice (once for each *PU). Also, that generation alone puts quite a lot of heat on the GPU. And it does nothing but displaying the terrain.
The article does have a few interesting tidbits that are not tied to the GPU, though.

And who knows, if I have too much time during the project, I might end up implementing that as a dynamic loading screen


Funny, I didn't know that was from PolyVox
Well, it is not currently maintained, but it is from 2011 and by that, it is the most recent library. Noise++ is about 4-5 years old and libnoise... 8? 9? 10? I don't know
The only interesting thing about libnoise (to me) is that it has a good example of noise worms (used in Minecraft to generate the tunnels and mines).

And the good thing about ANL is that the author is still pretty alive and active on the gamedev.net forum, so one can actually contact him for questions.

_________________
My site! - Have a look
Also on Twitter - with more ketchup

I completely agree about the problems from having it run on the GPU, but I was more interested in the algorithm for generating the terrain. It does look a bit alien though (possibly good for underwater).



I think I might check it out at some point... I've mentioned elsewhere that we're currently working on higher-level integration of PolyVox into other game engines, and a landscape generator might be a useful addition to this.

I would have thought it was meant to be underwater. Notice the blue fog in the background?

@TheSHEEEP:

I was interested so I read this entire thread, and noticed that you made mention of needing to keep the number of scene nodes in Ogre down to a bare minimum. Let me suggest batching. Have you had a look at the New Instancing system in the latest version of Ogre? It's seriously fast

I've been doing a large number of experiments recently in the realm of creating my own Minecraft clone, so I experimented with the New Instancing system also. It took me two weeks to work out how to use it because it's not very well documented, but when I worked it out it all made sense and it made rendering about 10000 planes entirely possible (and at a good 80fps!) on my mid-range laptop. I strongly suggest you try it, and if you have any problems at all feel free to ask me....can you PM on these forums? The only other way you could contact me would be to get my attention on the TGC forums somehow....or maybe post an off-topic thread on these forums.

Clonkex