   QuadTree/Rendering data organization for a Terrain Editor
  So the last week or so I started working on a terrain editor(Direct X) that uses height maps. Right now all the geometry(4000-ish verts, 64x64 height map) is loaded into a single vertex buffer and I create appropriate indices to those vertices in a single large indexed vertex buffer. Now I want to add in the ability to select individual vertices and raise/lower them as the user wishes. For that I need collision with a picking system. For collision I need a QuadTree. My question is what would be the best layout per QuadTree Node. Right now I'm thinking:QuadTree will be split up into 4 segments, then split into an additional 4 segments, like such:__________|[][]|[][]||[][]|[][]|-----------|[][]|[][]||[][]|[][]|-----------QuadTree Node:Vector of VerticesVector of Indices to those vertsEvery frame:Find the appropriate Node that the user/camera is in. Create a vertex buffer, copy in the list of vertices from that node, create index buffer, copy in the list of indices from that node. Use the dynamic write flag inorder to keep time down on the lock/unlock process.Does this seem like an adequate approach? Does anyone have any other suggestions?   
  I don't like the idea of copying all that data around on every frame - and I don't really understand why...[smile]My quadtree system managed everything that you've described without a single resource modification unless the data actually had to change (e.g. modifying the heightmap).I only had a 256x256 terrain such that I could fit a single static VB inside of the generally accepted 4mb size. After that, for each node, I maintained an index buffer listing all of it's sub-triangles.This created a lot of seemingly extra IB's, but the extra storage (few hundred KB) was definitely worth the performance.This meant that, whilst traversing the tree, as soon as I hit a node that was completely accepted I could despatch it with a SetIndices() and DrawIndexedPrimitive() call and stop traversal of that branch.In retrospect I know it is possible to have a single IB and still perform the same algorithm, but it would've made the code a lot more fugly [smile]hthJack   ;  I have to agree with Jack - my implementation uses multiple index buffers and a single vertex buffer.  All of them are static and I just select the proper IB's when rendering.  Especially for a 64x64 spot, the extra IB's will not be an issue.Even so, you may want to consider some type of a different system for picking vertices to move up and down.  Maybe start out with the vertex at (0,0) highlighted and move the selection in the x or z direction with mouse movement.  Setting up a whole picking and raycasting engine for a heightmap editor seems like overkill to me.Of course, if this is a part of a larger engine/effort then as long as the picking and raycasting are reusable (Object oriented!) then that is probably the best way to go.  Good luck!   ;  I understand what you both are saying so I'm trying to think of a better way to set this up.One of my problems is all my vertices are created and directly placed into the vertex buffer. I have no copy to actually perform physics on. The only way to fix this, that I can think of, is to create a copy all my vertices. Sure it sacrifices some memory but it also keeps me using only 1 vertex buffer. I can see how I could use a single index buffer to draw so I think Ill try and work with that idea.And yea, the point of this is so I can give this tool to a level designer in our group, and have him create level content for a demo I am working on. I eventually want to add a variety of features to this engine and I'm going to need collision for when the level is imported into the game anyway. I just wanted to make things as simple as possible. I.e.Terrain->LoadTerrain(fileName, etc.)Terrain->GetNodeTriangles(Vec3 POS); // Returns a vector of triangles in QuadTree node.