The trees were thrown together at very high speed in Milkshape 3D, and I’m using the ms3d format at the moment. The number of terrain chunks in a level is completely customisable and a lot of pre-processing work takes place as the level is being loaded. In these shots there are 256 chunks each 32x32 tiles in size. So that’s 16x16 chunks covering a 512x512 tile area.
I’m trying to find out what works best - lots of small chunks or a fair number of medium sized ones.
Well that is the answer I want to know, too. I hope that you will write your conclusion here… 
I’m curious… Do you load your height data (for terrain) in some sort of heightmap? That is, 512x512 texture divided in 16x16 pieces? That is my idea how to start to handle that part of my engine…
Any (2^n +1) x (2^n +1) heightmap will do - the ‘chunking’ is all done automatically. It’s +1 to each dimension so that I still have 2^n x 2^n tiles.
I use chunks of 33x33 for a 513x513 heightmap with geomipmapping - meaning five detail levels (33x33, 17x17, 9x9, 5x5, 3x3), but the problem is, that the chunk size heavily depends on the type and scale of terrain you want to model (soft hills vs. rocky mountains). I fear such settings need to be “hand-tuned” for each location of a game.
That’s exactly what I’m running with just now - 32x32 tiles in each chunk made up of 33x33 verts. Only I’ve got 3 details levels at the moment, not 5.
I am planning to rise the number of detail-levels even more by providing detail meshes per quad node, this way I get more flexibility regarding the terrain type and chunk-size.
If I understand you correctly isn’t that going to take up a LOT more memory?
No not really, since a lower detail level only needs a 4th of vertices than the next higher level. The way I plan to do it needs the double amount of vertices than the original vertex data at maximum.
I fear that memory consuming will be heavier then you predict. And you are right, I think that some locations in game will have to be “hand-tuned”.
Cylab’s right. Example: 16x16 = 256 verts for the full detail mesh, plus 128+64+32+16+8+4+2+1 = 255 verts for the detail levels.
That gives 511 vertices for the full detail mesh plus all the detail levels. Nice one!
Ahh… :-[
Seriously, nice approach!
It’s even better ;D
16x16=256 full detail, 8x8=64(!) half detail, so you end up
256+64+16+4+1= 341 vertices for all levels (including full detail)
To be correct it has to be 17x17 + 9x9 etc., but powers of 2 are easier to think of 
Also you will need some extra vetices for gap filling and such…
Actually I’ve done that all wrong.
256x256 = 65,536 (full detail verts)
128 = 16384
64 = 4096
32 = 1024
16 = 256
8 = 64
4 = 16
2 = 4
1 = 1
Total: 87,384 verts - only about one third more memory.
Edit: (just noticed your post above- yes, 256 * 1.333333 = 341 verts!)
And how do you guys render each chunk? Did you make displaylists for every LOD (since its static), with glDrawArrays, VBO’s ?
I allocate a single (static) VBO with all chunks and detail levels and call drawing of single triangle strips via glVertexPointer passing a precalculated index. I will give glVertexPointerListIBM and glVertexPointervINTEL a shot to reduce GL calls some more if necessary. Also I am tossing the idea around to create different detail levels “on the fly” by using apropriate vertex storage and utilizing the stride-parameter to save more gfxcard memory, but this might not be possible (I haven’t thought through this one yet…)
So, Peter, whats new? And yes, happy new year!
I saw some new screenshots at your homepage - really serious looking particle engine. Can we expect to walk around your world a little in near future?
p.s. your clouds look really good, i remember that you are doing them with 5 textures, so you have bounding box, not skydome?
hope to hearing from you soon…
Hi hvor2, thanks for the comments on the Particle engine. As you can see from my site I’ve had my head down over christmas and new year working on the game and this particle studio utility. I bought the license for Terragen from planetside - able to create lovely skies and huge maps in great quality.
I’ve been taking a hard look at the performance of the game engine - my terrain and tree drawing methods are eating up far too much framerate at the moment. I also brushing up on my physics as the particles and other projectiles in the game need to look realistic!
Hope to have a 1-on-1 multiplayer near the end of February with Mace, but there still lots to do!
Ah, yes, performance. Be sure to know what is eating up majority of rendering time, pure rendering of your display lists or maybe frustum culling checks (i hope that you don’t check that for every foliage object), or collision checks. Hope to see it soon, keep up. Great news for Terragen licence, it is really promise of great looking game.
Hi
I just want to tell you the game looks incredibly nice, lovely terrain. Dont forget if you gfx card is radeon 5500 its very old…so new computers will maybe have much greater performance.
Thanks for your comments Zulo! The card I’m using is a Radeon 9550 that I picked up recently for only 45 GBP (about 80 USD)
I understand this is - in the graphics card market - and ‘old’ card but I’d rather be forced to write more efficient code and learn well, than to use lazy code on an X1800 or NV 7800 and then wonder why others complain it’s too slow!