VBGamer

Pretty damn slow compared to what ??? Rendering every poly brute force ??? =) Quadtrees and octrees are not slow, they are a simple heirachical data structure, if the parent is completely within the viewing fustrum, all of it's children can be rendered, if the parent is not visible at all, all of it's children can be discarded. An AABB (Axis Aligned Bounding Box) test against the view fustrum is a negligable speed loss compared to rendering every poly brute force. Simple as that. Yes brute force is nice, for simple low detail level terrains, but when you start rendering 256x256 (131,072 tris) or higher you simply can't just render them all every frame. I agree that for extremely large levels, compiling a quadtree can take a little while, but this is usually done as a pre-process anyway. With regards to what type of method you choose, I would say that in your case, quadtrees would be the better option to begin with. If you are planning to add buildings, structures and the like, then Octrees are a relatively simple extension of Quadtrees if you come to that point. There are a million and one resources about quadtrees on the net, so imho they are the best place to start. The other advantage of using a quadtree type system is that texturing can be a lot more detailed than "Stretching one texture over the entire terrain".. Remember that if your terrain again is 256x256 and your texture limit is 256x256, then thats 1 texel per quad.. Ok so you could MultiTexture a detail texture over the top, but by using a quadtree, you can easily assign a texture for each set of N*N Quadtree nodes allowing you to have much more detailed texturing for your terrain. Going the quadtree route will also help you out if you plan to implement a Level Of Detail system further down the line. Jack, sorry if you've taken offence by my contradiction to your statement, it was not my intention =) -- Adam Hoult Lead Programmer Atypical Interactive http://www.atypical-interactive.com