realtime terrain LOD - updating buffers?

Started by
-1 comments, last by Melvin2 21 years, 10 months ago
OK, so this is the basic idea for highly functional terrain (not talking about height maps here): You have a bunch of basic "surfaces" for your terrain. ie. NURBS patches, subdivision polygons, or whatever. As each one gets within sight, you calculate it using some sort of algorithm to optimize the resulting mesh. ie. you break quads up into a quad tree, breaking more-detailed areas up further. You attach the adjacent surfaces together so that as you refine the mesh, you can repair any cracks that might appear along the borders. I''m getting to my questions, hold on The camera moves. New surfaces become visible and get added. Old ones change their level of detail. As this happens, adjacent surfaces get changed too, since we have to prevent any cracks from appearing. The big problem is that because of a few cracks in the edges, a surface has been altered slightly, even if it never increased or decreased its LOD level. The punchline: Now that our data structure for this surface has been slightly altered, how should we update the buffers? First off, to simplify things, lets assume that the data structures are filled to the highest LOD, and that each higher LOD uses all of the previous LOD''s vertices plus any new ones. Now our vertex data is constant for the entire existance of the surface, and only index values change. The question is, how do you change them efficiently? The solution to cracking involves using patterns of triangles to match neighbors. This means some triangles no longer exist, and new triangles are created. However, only a very small portion of the triangles are changed. What will yield the best performance? Creating a whole new list of indices every time a surface changes seems impractical. Is there a simple, efficient way to overwrite triangles inside of the index buffers? I have never done the following, nor seen it done, but would it make sense to lock dynamic buffers without the NOOVERWRITE flag, and then make the appropriate changes? I imagine this might make directX cry... Finally, perhaps none of these are efficient solutions for terrain. Perhaps adjusting LOD based on camera position is not practical. If this is the case, I still have the same problem, since adding new surfaces as they become visible can still generate cracking, but the number of occurrances of this problem is drastically reduced. Is camera-based LOD too slow to make the optimization worth it? Sorry to blab. I probably gave too much information, but it seemed neccessary to clarify my questions. Thanx, off to play Neverwinter Nights

This topic is closed to new replies.

Advertisement