I assume this a problem everyone hits when they try and make big outdoor enivironments with heirachical LODs, how do you get round it.... OK I want a big outdoor environment so I create an LOD system to handle the rendering. For the moment, say we just have traditional triangle meshes, created in an art package (no complex rendering techniques or procedural generation). So, say, a wooded area will be represent by a single low-poly blob at 1 mile+, resolving into individual tree models as the camera get closer. Works fine for little patch of trees, that can be considered atomic (i.e. either ALL the trees are at a high LOD or none of them are). But when my wood is big enough that it can't all be rendered at high LOD, you have a problem. For the tree you are standing next too will be represented by two overlapping bits of geometry: a single high poly model and little section in the low-poly blob that represents the whole wood. Rendering one on top of the other not look correct, and not rendering the low-poly representation will cause trees that are far away from the camera to disappear. The problem becomes even more complicated if you have several levels of details (as then you several overlapping representations of them same geometry). These kind of environments have been around for a while, it seems like *someone* ought to have a solution. Do you have to sub-divide you objects into atomic chunks ? So your wood in this example would be subdivided into chunks each of which is represented by either a single mesh or several tree models, but not both. How does this work for multiple levels of details. I guess there could be some kind octree-type solution (where if every level of the octree has an object associated with it, rather the just the leaf nodes), but before I head off and implement it myself, does anyone have any papers, etc. I could look at ? I realize you have use a geometry clipmapping techniques for terrain in this situation but I can't see how this could be applied to objects like trees or buildings.

Normally for such things like trees a seperate system would be used. For large forests the reccomended way is to use batched billboard sprites for distant trees, and LOD meshes for nearest tree.

You would want quadtree or octree to manage culling and such for very large areas, but for smaller numbers it is not needed.

I was using trees just as an example, the same problem would apply to all static geometry (except maybe the lanscape surface itself, which a geom. clipmapping scheme could be used).

But the same problem applies regardless of the rendering techique. The one you suggest would have the same problem, the tree you are standing next to has two representations a billboard sprite (part of the batch for the whole wood) and an individual geometry object. If both the sprite and geometry are rendered then it will look incorrect.

Quote:Original post by griffin2000
I was using trees just as an example, the same problem would apply to all static geometry (except maybe the lanscape surface itself, which a geom. clipmapping scheme could be used).

But the same problem applies regardless of the rendering techique. The one you suggest would have the same problem, the tree you are standing next to has two representations a billboard sprite (part of the batch for the whole wood) and an individual geometry object. If both the sprite and geometry are rendered then it will look incorrect.

Then you just don't render the sprite. The point is, if the tree (or any object) is far enough away you draw the sprite instead. Basically, you calculate the level of detail needed for each tree, and render whatever fulfills that level, whether it be a high-detailed mesh or a sprite. You should never be drawing both the object and sprite at the same time.

The problem I was thinking of was a large ourdoor environment where you might have have several patches of woodland (or buildings or whatever) each with hundreds of trees, so you couldn't afford to test every tree to work out which level to draw.

Quote:Original post by griffin2000

The problem I was thinking of was a large ourdoor environment where you might have have several patches of woodland (or buildings or whatever) each with hundreds of trees, so you couldn't afford to test every tree to work out which level to draw.

Why can't you afford that?

In my engine i just draw every tree sprite in a big batch, and use shader that fades it out when closer than a given distance.

Alternatively, you can use quad tree to determine visiblity..or even easier, just loop through each tree and check the distance.. you can speed this up by spreading the search out over a number of frames so you dont do the whole loop every frame.

Thats a non-trival CPU load, thousands of tests, thats gonna be a significant. Seems seems pretty wasteful seeing as only a handful of trees are going to pass the test and be rendered as geometry. Also will mean you cannot batch the billboards so will be less effecient.

Fading on the GPU seems like a better idea, I will experiment, but while it seems like it work well for trees, I'm not sure it would work for other geometry such as buildings.

You can do this test over several frames, so it isnt slow.. You can use quad tree to speed this up immensly , and if you are doing very large outdoor areas you should have quad tree or octree already.

And all billboards can be batched, its doesnt matter where they are or whatever. Your trees meshes can all be batched too via some kind of instancing..

I have implemented a system tlike this in my own engien and it works well, even unoptimized. This is also how Speedtree work in general.