Do you generate the terrain in real-time? I'm also working on a marching-cubes terrain, and right now I'm trying to work out a good way to generate new chunks real-time.

I've updated the method for generation quite a bit since this was posted.

Right now I'm generating a 3x3x3 km, with three different levels of detail in about 10 seconds. That's only the startup cost. After that, blocks are generated real-time around the user.
A Block is made up of a number of cells, each cell being a marching-cube cell. (the exact number depends on the resolution). But to avoid repeating samples within the same block, I create a 3d array of samples first, then from that generate each cell, store the triangles in a VBO and erase the samples array.
It works fine for real-time rendering, especially since the blocks are small, and as soon as one gets too far, it's moved ahead of the user to represent terrain there.

Not sure what exactly you need, but that's just a rough outline of what I do.

I'm just trying to find a decent way to generate new chunks in real-time. The plan for my next attempt is to have chunks store 64x64x64 cells, but only generate geometry for one 4x4x4 piece of one of those cells each frame. What block size are you using?

Ok, let's make sure we're talking about the same thing. For me, the most basic unit in my terrain, the little cube that samples the density at the 8 corners, and then creates triangles, is known as '[b]Cell[/b]'. The cells are organized into larger collections called '[b]Blocks'[/b] which get moved around, as necessary. That's just my terminology.

Now here's a diagram of what I use to determine the sizes:

[img]http://www.milchopenchev.com/RandomPics/terminology.jpg[/img]


And these is my actual code:

[code]
lowResResolution = 10;
lowResBlockSize = 600;
lowResNumBlocks = 7;

midResResolution = 12;
midResBlockSize = 200;
midResNumBlocks = 5;

highResResolution = 20;
highResBlockSize = 30;
highResNumBlocks = 5;[/code]

Edit: the NumBlocks is how many blocks I have per level of detail, on one axis. That means highResNumBlock = 5 makes 5x5x5 = 125 high resolution blocks around the player (with the player being at the center).
I just timed my startup, and to generate all those blocks (high+mid+low ) takes about 6 seconds. This is nothing considering the huge volume generated, and after that you only need to update a fraction of them at a time. Of course this is done all in another thread.

Also, if I'm getting you right, you want to do 64x64x64 samples per block (or chunk, whatever). The point is, if you're using a complex density function that will take a while to generate. (I'm using 2 perlin noise functions, and if I set either to more than 5 octaves it can get pretty slow).


It all depends on what you want to do, but if you don't want long wait times at startup, just create what's around the user, and do the rest at runtime. I also posted a thread on the forums for what 'acceptable' terrain resolution is. After applying texture I found that 1 sample per 2 meters gives pretty good results.

There's dependence on your density source of course - applying the Nyquist rate, if you're density variates greatly every X units, you need to sample every X/2 units for good results. In my case I have control over the source density so I changed it to vary accordingly.

You're right, I was getting my terms mixed up. Sorry about that. And thanks for the info. Like you mentioned, I'm using a fairly complex noise function (ridged multi-fractal, with 6 octaves currently). I'm also doing a pretty high-res sampling so it does take a while. Thanks for your input; I was really just trying to get a feel for the numbers you were using.