Hey everyone, I have been experimenting with terrain rendering lately, and in particular quad trees, to try and render a huge scene with little FPS drops. Currently, I am generating my terrain in Direct3D 9, using procedural techniques (diamond square algorithm), and/or loading external heightmaps, and storing the terrain into one single vertex buffer. Now, I have been reading a bit about quad trees, and how I could go about implementing them, and had my first go. Although I have managed to implement the basic structure, with culling working, and some additionnal custom LOD algorithms to try improve things, I am still having issues with finding a suitable way of storing my terrain inside the nodes. Although this is certainly not optimized, for testing purpose of my quadtree, I naively went on adding an index buffer per node, and a chunk size of 1 quad. Obviously, this process is very slow (both when creating the tree, and rendering), as I am constanly changing the current index buffer, and rendering very small chunks (in fact much slower than one single huge vertex buffer being rendered at a time). My issue is that I do not know exactly how to split up my data inside the tree, and I haven't been able to find explanations on how to implement the tree efficiently. How do people usually go about storing the terrain inside the nodes? Obviously, in my case, I need to start by increasing my chunk sizes to hold more vertices, and limit the buffer switches. However, is it a better idea to have one index buffer per node (or patch) ? I have read several people tend to use the same "global" index buffer, and one vertex buffer (possibly global, and dynamic with the height being plugged in at runtime) per node. Would that be preferable? I am just thinking in terms of implementing the data easily (without having to go through the trouble of creating a complex index algorithm to find the appropriate verts in my huge buffer), as well as being able to alter the geometry as a whole (e.g. via an array, without having to alter each patch individually : in the case of one vertex buffer per patch), still with the perspective of an "infinite" terrain (by that I mean the possibility of using multiple vertex buffers, or streaming for a larger geometry). I have also read about using dynamic buffers; for instance having my generic transformed chunk grid of xy coordinates, and a generic static index buffer for that grid, and simply lock my vertex buffer, alter the heights depending on the patch, and locking it again. Would that be efficient? Although I am not looking at creating an incredibly huge geometry for now, I would still set it up in a way that it would allow it, so I would like to minimize memory cunsumption (avoir duplication of data, using too many buffers, and so on) Note that I am not looking into using shaders or the GPU either for the purposes of my terrain, so I'm just thinking in terms of optimizing my current algorithm for the CPU. Anyway, I hope you can point me out in the right direction, and/or tell me what I'm doing wrong/right. Sorry for the long message, but I just want to be precise about what I have, and make it easier for you guys to help me out :p Thanks in advance for your advice ;) !!