I'm in the process of developing a 3D terrain engine for my game, and its going pretty well.

My terrain is divided into segments, and each segment is a simple quad and a heightmap, and I use tesselation to dynamically increase the detail (Using the heightmap to create new vertices) as the camera gets closer to the segment.

This works perfectly until I zoom out byond a certain distance. When zooming out the tesselation factor decreases and eventually reaches 1, which means that each segment is being rendered as a simple single quad (2 triangles). If I continue to zoom out then there is nothing I can do to reduce the amount of detail in a segment (As its already only 2 triangles) and eventually I'm rendering too many segments and too much detail again (Note my maps are massive, and so I need to be able to zoom out to a planet type scale).

I was just wondering if there are any well known algorithms that are design to handle this?

I know Outerra does a great job of it, so its definitely possible.

My first thoughts were that once I reach a certain distance I could increase the size of my segments (e.g. 4 become 1), and I could keep repeating this process indefintely thereby allowing me to zoom out as far as I'd like. However I'd need to work out how to transition from 1 segment resolution to the other without popping.

Maybe when I switch from the smaller segments (Where tesselation = 1) to the bigger ones I could initally set the tesselation factor to 2, which I guess would give me the same as the 4 original segments... and then I could smoothly change from tesselation factor 2 to 1 as the camera continues to zoom out. And once it reaches 1 then repeat.

If you're still following that, then do you think it might work? Are there any other well known techniques?

Thanks
Ben

Well you could create a heightmap out of the segments and switch to this coarser level of segments once you reach that level of detail, continuing with the tesselation algo on these level of segments. This could be done several times as you get farther out, I think the switch could be made unnoticeable if connected properly.

It won't give an optimal coverage, as the more distant parts may want to switch long before the closer ones, but it still could work well for you.

Thanks Cameni

Do you have any plans for more technical explainations of your Outerra engine? The water article was excellent... no if only there was a similar article on how you achieve your zooming all the way from planet scale down to cm scale that would be very interesting too.

But yes, I think I've been thinking about this the wrong way round. I've been thinking from the closest highest detail view and then working out how to zoom out and reduce detail. However conceptually I think it'll be easier to think about starting fully zoomed out and then increasing details as I zoom in.

I'd increase detail by increasing tesselation, and then when I reach a tesselation factor of 64 (The max supported in DirectX 11) I could sub divide each segment in 64x64 segments and set the tesselation factor back to 1. I could then repeat this process until I reach max detail.

Thanks for your help
Ben

Also you could perform smooth tessellation inside geometry shader (or tessellation shaders, on more modern hardware) - although geometry shaders might be too slow, so maybe using them just for transition between tessellation levels and then replace with precomputed higher tessellated mesh (and doing this of course several times as you don't need just 2 LOD levels). Could be cool.

Thanks for your reply

I'm actually using the DirectX 11 tessellation shaders (Hull and Domain shaders), which nicely morph between each tessellation level (Thus avoiding any popping).

Thanks
Ben

Thanks again Cameni

I look forward to reading your article.

The link you included to http://acko.net/blog/making-worlds-part-1-of-spheres-and-cubes looks very interesting too, thanks.

Thanks
Ben

Hmmm, from reading the "Making Worlds" article you linked to, I've realised that its going to be very hard to use my heightmap generator create heightmaps that can be seemlessly wrapped onto a sphere (Made from a cubemap).

Maybe I'll have to stick with a flat world.

It sounds like you are using fixed-sized chunks. Why not use a quad-tree? This would allow you to zoom out (and in) indefinitely. I did this approach morphed to a sphere the size of Earth and was able to zoom in to detail of 1 meter triangles. From very fair away the planet was only around 32 triangles. Of course the data was procedural, but on a smaller scale it would not have to be procedural.

It sounds like you are using fixed-sized chunks. Why not use a quad-tree? This would allow you to zoom out (and in) indefinitely. I did this approach morphed to a sphere the size of Earth and was able to zoom in to detail of 1 meter triangles. From very fair away the planet was only around 32 triangles. Of course the data was procedural, but on a smaller scale it would not have to be procedural.

Hi c_olin

Yes, I'm getting into a different mind set now and a quad tree approach would probably work well.

Previously I had thought from the highest level of detail and been think about how to reduce detail as I zoom out, but that only works so far.

By thinking fromt he furthest lowest detail and then working how to increae detail as you zoom in seems to be a much easier way to think of it.

As you say, each segment of mine was a fixed size and had a high res displacement map (With lower resolution mipmaps of the displacement map).

Going to a quad tree approach will mean that I wont have a simple displacement map and its mipmaps, but instead I'd have a displacement map for each size segment in the quad tree. I don't think that'll be a problem.

I also think I have worked out how to solve the other problem I mentioned above about how to wrap my generated terrain around a spherical world. I could generate a seperate terrain for all 6 sides (Of the cube map) which are oversized (Say by 20%) and use the overlap to blend the sides together smoothly. I'll have to experiment to see what its like.

Thanks
Ben