I was wondering... I've done my research on the various methods of Terrain LOD (I've finally settled on a Quadtree method, for it's simplicity), and I'm ready to begin implementing it.

So far I've got a QuadNode struct, each of which contains an array of 4 QuadNode structs (except the leaf nodes, of course). I plan to add the relevant geometry to each Quad Node, and display it only when necessary.

What I'm wondering is how I should implement the geometry. I had planned to make a class (called QuadTerrain), which contains all the information and functions to create, update and access the terrain an associated data. Then, in code, all I'd have to do would be create a new QuadTerrain and call various functions on it. Is this possible, or am I following a dead end? Should I use a custom content Processor, and if so, can I use it in the same 'user friendly' way? Can I use the MeshBuilder class, the heightMap.getpixel function and all the other content pipeline stuff in a normal class?

I tried various things for a few hours before coming here, but didn't really get anywhere... so any help would be appreciated. Examples or tutorials would be brilliant. :)

Thanks,
Qu.

I've been going through a similar process in trying to find information on quadtrees.  Here are several of the articles that I have come across:

http://www.kyleschouviller.com/wsuxna/quadtree-source-included/

http://www.google.com/custom?domains=GameDev.net&q=quadtree&sitesearch=GameDev.net&client=pub-3167291168602081&forid=1&ie=ISO-8859-1&oe=ISO-8859-1&cof=GALT%3A%23339966%3BGL%3A1%3BDIV%3A%233366CC%3BVLC%3A3366CC%3BAH%3Acenter%3BBGC%3AFFFFFF%3BLBGC%3AFFFFFF%3BALC%3A3366FF%3BLC%3A3366CC%3BT%3A000000%3BGFNT%3Agray%3BGIMP%3Agreen%3BLH%3A50%3BLW%3A225%3BL%3Ahttp%3A%2F%2Fimages.gamedev.net%2Fsitelogo.gif%3BS%3Ahttp%3A%2F%2Fwww.gamedev.net%3BFORID%3A1%3B&hl=en

I think you would be able to achieve your goal with a quadtree and these tutorials should be a good place to start.

Thanks for that, I've also spent time looking into Quadtrees. I think I've come to understand them quite well.

What I need now is the other stuff, for making and updating the terrain geometry. I'm not sure if I'm going to need a custom content processor, whether or not I should have each chunk as a seperate model or as a mesh within a main 'terrain' model, and how to implement things like meshBuilder in a custom class in either case. I'm detemined to get it working, but I need some help or I'm going to spend hours puzzling over every simple thing I come across. :)

Alright, I spent another few hours and finally worked out why I couldn't get this working: I didn't properly understand content processors. I didn't realise you could use them to create custom classes in addition to predefined classes such as Model Content.

I have only one question left: Should each QuadNode's geometry be represented by a Model, or is it possible to represent each one as a mesh within a larger "terrain" model? If it is, are there any advantages to this?

Each quad-tree can either have its own vertex and index buffer or can share part of an index and vertex buffer, orrrrr, a combination of those two.

I've always implemented it as a graphics mesh of indexed primitives, and a physics mesh created from the the same mesh. I haven't implemented anything through the content processor yet, but I highly recommend going that route, as calculating the entire terrain at runtime everytime takes awhile, especially if you do it on the 360.

" as calculating the entire terrain at runtime everytime takes awhile, especially if you do it on the 360."

On the other hand, if you want to deploy for 360 then presumably you will eventually want to make it available to others and with the limit of XNA games being only 150 MBs you want to make your data set as small as possible.

150MBs? Didn't know that. What a jip. I think I'll stick with my original idea of making it only for Windows...

I'm not sure I understand what Lord Ikon said about sharing part of an index and vertex buffer, but so far I've made the quadtree structure and have started generating geometry. Each QuadNode has it's own seperate Model, whose edge verticies match those of the one next to it (I'll either work out edge stitching or just cheap out and use skirts later on... for the moment I just want a working terrain).

I'm still not sure if this is the best way to do this... but at least I'm actually getting somewhere. Please tell me if I'm doing anything wrong, as I'd rather not find out the hard way.

Quasar:

150MBs? Didn't know that. What a jip. I think I'll stick with my original idea of making it only for Windows...

I'm not sure I understand what Lord Ikon said about sharing part of an index and vertex buffer, but so far I've made the quadtree structure and have started generating geometry. Each QuadNode has it's own seperate Model, whose edge verticies match those of the one next to it (I'll either work out edge stitching or just cheap out and use skirts later on... for the moment I just want a working terrain). I'm still not sure if this is the best way to do this... but at least I'm actually getting somewhere. Please tell me if I'm doing anything wrong, as I'd rather not find out the hard way.

If you'd like to see the code and example the link to the engine is in my sig. v0.182 is fairly simply compared to v0.19 and newer, and you would simply want to look in the Entities directory in your solution, and you'll find Terrain, TerrainPatch, and QuadTree classes. In fact, if you'd like a very small sample with terrain stuff encapsulated within it, check out the third sample on this page called Simple Physics Sample v0.12. It has most of the engines terrain system inside of it, but without the engine itself (if you don't need it). The same was created for XNA 1.0r, but I believe it will work on 2.0 just fine. 

What I mean by vertex/index buffers, is that I do not use a model, or at least not the XNA model. When you draw a model, you're really just looping through all the vertices of that model through its index buffer. So my heightfield is simply a vertex buffer (a bunch of verticies), and for each quadtree I loop through them using an index buffer, and draw that quadtree chunk of terrain. It is really much easier IMO than using XNA's model structure, as you can control access to your vertices and index buffers very easily, which allows me use terrain smoothing algorithms, and easily create different LODs.....although I'm sure this could be managed somehow with the Model class.

Quasar:

150MBs? Didn't know that. What a jip. I think I'll stick with my original idea of making it only for Windows...

{Puts on yorkshire  accent}

150 mega bytes, luxury!

eeee when I wer a lad you had 64k, and wer glad of it. Then t'operatin system had half of it.

{Takes off yorkshire accent}

Seriously though Starflight shipped on two 5 1/2 inch disks and contained 270 solar systems, 802 planets, half a dozen alien races, a plot, sub plot, you name it.

People have got lazy, I had a massive argument with a graphic artist because he refused to resize his textures from 2048 by 2048.

I have seen commercial games that just threw all the verts at the graphics card, don't bother with fustrum culling or anything, they just said "the game requires a 512M graphic card". They could have shipped the game for 32M graphic cards with a bit of coding.

150 megs is plenty, as long as you plan for it.

I might have missed something. What does the 150 mb limit apply to?

I know what you mean about having a massive argument with a graphic artist though: S.T.A.L.K.E.R on the PC was a good 8Gb on the hard drive, so he doesn't see any reason our games shouldn't be as big. I, on the other hand, appreciate a game where the developers have put a bit of effort into performance and storage. It generally shows that the game is ahead of its time. I always though Halo 1, UT2004 and SW BattleFront ran quite well on systems that couldn't run games which looked half as good. Stalker could probably have been released for systems with a quarter the power.

Back to Lord Ikon... I downloaded v0.182 (I also downloaded v0.19 and the physics thing, but didn't look at the former and the latter wouldn't run). After a couple hours moving backwards and forwards between Terrain, TerrainPatch and QuadTree I managed to work out how it worked and came to understand a little better what you meant about vBuffers and iBuffers.

Meanwhile, I realised that a custom content processor can export to a custom class, but only within the content processors solution (which explains HeightmapInfoContent and HeightMapInfo in the Generated Geometry Sample... now they make sense). Screw using the Model Class, Lord Ikons method is so much better, even if I do have to spend time working out exactly what an index buffer is, and just how it's connected to the vertex buffer.

After this, it's going to be easy doing the game logic. >:)

I'm not a graphics expert, so this may not be exact, but here goes....

An index buffer simply tells the video card which indeces to use from the vertex buffer.

So, picture it this way:

*---*
|   -|
|  - |
| -  |
*---*

Each asterisk (*) is a 3d point, otherwise known as a vert. To draw those two triangles you could simply give the video card each triangle. And it would draw each one
individually:

*---*    *
|   -     -|
|  -     - |
| -     -  |
*     *--*

That means drawing 6 sides total.

But when those two triangles are touching, they form a square. So why draw 6 sides if you're drawing a square? You would think you should only draw 4 sides. This is where index buffers come in. The video card takes care of the work, you just need to tell it what the index numbers of the vertices are.

Lets give the triangles points a cooresponding number:

0    1
*---*
|   -|
|  - |
| -  |
*---*
2    3

So the two triangles are defined as (clockwise):
0, 1, 2
and
1, 3, 2

If this were your entire terrain, your vertex buffer would have 4 vertices, which are points 0-3, and 6 indices, which were the 6 we just mentioned. Given this information, when you make a DrawIndexedPrimitives, you have to tell the video card which vertex buffer your index buffer cooresponds to, the size of each vertex (in bytes), and the starting offset of your vertices which is zero in this case because our first vertex in this draw call is truly our first vertex in the buffer.

What is nice is if you only want to draw the second triangle, you make the same call, and tell it that the vertex buffer offset is to start at 1 instead of zero (because the first triangle's earliest vertex is 1), and the index buffer would start at the 2nd triangle (which is the 4th index.

After writing this I remember seeing something on Riemer's site, his explanation has better pictures and is much more complete:

http://www.riemers.net/eng/Tutorials/XNA/Csharp/Series1/Indices.php