I'm not sure I understand what you are saying in the last paragraph.

Maybe I was unclear, I'm saying that no matter how large the original terrain data is, if you don't need a very large view distance could you just not only use a single slice of the original data, at say 1024x1024 and then sample this? (this would give ~1km of view distance assuming 1:1 texel:meters) ? Instead of having to mess around with dynamically creating mip-maps for the terrain during runtime, just render the current "viewable" area to a 1024x1024 texture and use that for all levels.

I made a slightly similar implementation of geoclipmaps and I was pleased with the results until I realized that implementing decals with geoclipmaps is rather difficult since the geometry changes so often. A simple quadtree terrain as used in Frostbyte engine works well for me.
However, the toroidal texture update which is used with geoclipmaps is usable with quad tree terrain too.
Cheers!

Sorry for the double answers here in a row, forgot about multi-quote. Anyways, I was worried about this also, but then decals will most likely be needed at only the finest (or possibly two finest) levels, the way I see doing this is having two splat maps for the terrain, one for detail textures and one for decals, which are also updated as the elevation map is updated.

also considered another terrain renderer to replace my geomipmapping implementation. The implementation of geometry clipmaps appeared a bit too messy for me. Then I discovered the CDLOD scheme and I'm very pleased with the results so far. You only need a single small vertex grid and then instance it over the field of view. Of cource, if you specifically want to implement clipmaps and are already aware of CDLOD, then just ignore my message.

Thanks, I will look into CDLOD

[quote name='turch' timestamp='1348579819' post='4983567']I'm not sure I understand what you are saying in the last paragraph.

Maybe I was unclear, I'm saying that no matter how large the original terrain data is, if you don't need a very large view distance could you just not only use a single slice of the original data, at say 1024x1024 and then sample this? (this would give ~1km of view distance assuming 1:1 texel:meters) ? Instead of having to mess around with dynamically creating mip-maps for the terrain during runtime, just render the current "viewable" area to a 1024x1024 texture and use that for all levels.
[/quote]

Ah, well yes, if you can fit the entire texture in memory then you can certainly get away without implementing any kind of texture streaming. But if that's the case then I'd say that geoclipmapping is overkill and you might as well just render a 1024x1024 terrain as a regular mesh.

Ah, well yes, if you can fit the entire texture in memory then you can certainly get away without implementing any kind of texture streaming. But if that's the case then I'd say that geoclipmapping is overkill and you might as well just render a 1024x1024 terrain as a regular mesh.

Well, not the entire height map texture, but the entire texture of the viable area. I mean, rendering a 1024x1024 terrain as a mesh is still ~1mil verts, which is a bit high.

Anyways, I was worried about this also, but then decals will most likely be needed at only the finest (or possibly two finest) levels, the way I see doing this is having two splat maps for the terrain, one for detail textures and one for decals, which are also updated as the elevation map is updated.

In my terrain project roads are/will be visible at some kilometers range so few nearest rings wasn't enough for me.

Otherwise, if you are using some sort of splatting for the decals, then you should be fine.

Cheers!

I would second CDLOD as well, this is what I implemented. It's much easier to understand, and performance are great - TBH I never really understood why geo clipmap would achieve better results than a chunk based method (but I might be dumb )

Also, CDLOD will give you geomorphing without any further effort, which is a very nice-to-have feature.

I've been looking into CDLOD, I read the paper published, but I felt it was missing a few very important details, like how the height map is updated, how to deal with *really large* terrains, etc.

Edit: Also, I'm not a super fan of relying the fact that the GPU has bilinear filtering of vertex textures, even though it's common now.

So, I've re-read the CDLOD paper two times now, and I think I got the hang of the general algorithm, it does indeed seem way simpler to implement then geoclipmaps, but in the end there's a section called "granularity issues" that read like this:

One limitation of the algorithm is that a single quadtree node can only support transition
between two LOD layers. This limits the minimum possible viewing range, or the minimum
quadtree depth, because only one smooth transition can be performed between two LOD layers
over the area of the same node. Increasing the viewing range will move LOD transition areas
further away from each other and solve the problem at the expense of having more render data to
process. The other options are to reduce the number of LOD levels, which reduces the benefits of
the LOD system, or to increase the quadtree depth to increase the granularity, which increases
quadtree memory and CPU use. The size of the morph area can also be decreased to mitigate this
problem, but that can make the transition between levels noticeable.

Since the LOD works in three dimensions, this problem will be enhanced when using extremely
rough terrain with large height differences: thus, different settings might be required for each
dataset.

In the provided data examples, LOD settings are tuned so that the ranges are always
acceptable. In the case where different datasets and settings are used, these LOD transition
problems can appear in the form of seams between LOD levels. Debug builds of the demo code
will always detect a possibility of such a situation and display a warning so that settings can be
corrected (detection code is overzealous, so a warning does not guarantee that the seam will be
observable - just that it is theoretically possible).
[/quote]

And I just wanted to ask those people that have implemented CDLOD if this effected any real world implementations? And if so, how much? And what considerations did you have to take for your type of environment/game? The section is very vague on the details, exactly when this issue shows up, et

And I just wanted to ask those people that have implemented CDLOD if this effected any real world implementations? And if so, how much? And what considerations did you have to take for your type of environment/game? The section is very vague on the details, exactly when this issue shows up, et

Well, I have had only little time to play with CDLOD, but I have found settings that work nicely for me, although they still might be sub-optimal in some sense. I found that too coarse meshing can make the lod transitions quite visible if the camera moves very fast. On the otherhand, with mesh detail that I was planning on having, I cannot notice any LOD artifacts nor transitions. I could also double the currently sufficient mesh detail without too much performance hit. I can't give any precise figures on this issue, I think you just need to experiment with it to see if it will work out for you.

I also recently implemented reflective water, and CDLOD is just perfect for that, because I can just use lower detail grid version for rendering, so it's quite efficient and still easy to implement.

I think that some sort of mipmapping for the height data should be used if there is very high frequency content included. I'm not sure how to do this in vertex shaders.