Terrain LOD [Free ScreenShots!!]

hah, i knew offering free screen shots would get you to read this, just give me your credit card number to confirm your age and everything is free!! erm.. heh, just kidding. anyway,

After a bit of vacation from graphics prgamming im back!

I decided to re-write my terrain engine from scratch. Im implementing a LOD (Level Of Detail) system based on Roettgers Algorithm. So far ive just finished the distance based part of it, next up is to add the interpolation error calculations (keeping a min level of detail for "rough" regions independent of distance to the viewer) and geomorphing so vertices "popping" in and out arent noticable.

Here's a wireframe screen shot of the distance based LOD in action. The view point in this scene is the corner near the bottom of the image (a little out of view). Notice how the area near the viewpoint uses the most detail (high number of tri's). As the distance to the viewer increases the detail does too! This is totaly dynamic and updates every frame as the viewpoint moves. My implementation uses triangle fans and performs T-junction elimination as well.

*Note: Frustum culling is not enabled in this screen shot (even though it kinda looks like it ;) ) Im just viewing the mesh from the corner.

Heres a shot with filled polys. I stole.. erm, borrowed this heightfield and texture from a free internet source. I will eventually create some of my own and use my texture generator to make some custom textures, but untill then....

I like the first one, very nice :)

Is this in OpenGL or DirectX or something else?

Finally, I love your avatar :)

Looks very good perspective. I'd be extremely interested to see what you churn out. Been wanting to get an LOD system working for quite some time.

7smurfs: Thanks, this is being done with OpenGL

Bubba: My pseudo vision for this ATM is a complete outdoor environment library. The main attraction being the terrain but also including things like skyboxes, clouds, rain, snow, etc... I dont currently have plans to make a game of it, but we'll see what happens :) There's this little piece of me wanting to make fully 3D RTS giving the user (almost) complete camera control. maybe in the future.

Implementing terrain LOD is a pretty interesting problem. There are quite a few different approaches and the algorithms are not trivial. So far its kept my attention quite well, but im only half way through implementing this algo, (and that doesnt include the geomorphing) :)

sidenote: It feels damn good to get back into graphics programming again!

Well I was interested because I want to implement real-time space to planet transitions in my game. This has not been done before and for obvious reasons, but I'm not a big name corporation so I don't have to worry about going under while developing the thing.

This kind of transition would require a lot of detail culling and a lot of LOD rendering for the terrain. I will have to significantly alter the engine for the space portion in order to get this to work. Also the planet meshes will no longer be just spheres...they will be approximations of the mesh of the actual planet - just rendered with much much less grid resolution on the terrain. As you approach the planet...the resolution will increase.

Won't be easy but with your terrain system it might be possible to pull it off.

The hard part will be deciding when to replace the actual terrain mesh with the approximated sphere version of it. Wrapping an entire planet of terrain around a sphere might not be possible yet so I will probably use approximated sphere surfaces that 'represent' the actual terrain data. This is a simple matter of displacing the sphere vertexes away from the center or toward the center of the sphere creating hills and valleys in the surface. This will require a LOT of triangles and my culling system will have to be top notch to do it.

But think about it, once you are close enough to actually see the terrain details, not much else will be in the frustrum anyways so all the vertex processing power will be focused on the terrain, not the space sector.

The other alternative is to actually wrap the terrain by minute amounts - simply displacing the x,y,z vertices a certain distance from a common center point. This would not be visible until at high altitude or from space.

Wow, I got to say it looks really nice. The only thing I can see, is in your first SS, you can easily see the transformation between the shifts, now I didn't notice it as well in the second shot, when the poly's where filled in, I was just wondering if you have looked into any thing to smooth the transition, or if its not noticable enough that when running this in game, it would become noticable, especially if being viewed in the air like that first shot.

Again though, I have to say a job well done :cool: :D

Real cool, i will be taking a class on openGL next semester. I hope i get to learn what you know ehehe, keep it up.

Quote:

---

Originally Posted by Xipher

Wow, I got to say it looks really nice. The only thing I can see, is in your first SS, you can easily see the transformation between the shifts, now I didn't notice it as well in the second shot, when the poly's where filled in, I was just wondering if you have looked into any thing to smooth the transition, or if its not noticable enough that when running this in game, it would become noticable, especially if being viewed in the air like that first shot.

---

The first screen shot was in wireframe mode just to show how the algorithm works. When you use filled poly's you dont notice any transition between detail levels at all. The only evidence of the algorithm is the "popping" effect that occurs when the view point changes and vertices are add and removed. This can (will) be remedied by geomorphing the vertices in and out of place instead of just popping them in and out of place.

Quote:

---

Originally Posted by InvariantLoop

Real cool, i will be taking a class on openGL next semester. I hope i get to learn what you know ehehe, keep it up.

---

this type of thing is definately beyond what i learned in my graphics class. Though we did do some other interesting things like ratracing, polygon clipping, etc... If you have a thirst for it and a solid understanding of how things work though, the possibilities are limitless! :)

Bubba, I think the best approach for your situation is to use a continuous LOD (like mine) but one designed for spherical meshes. The algorithm im useing uses quadtrees and relies on an (x,z) plane of heights. mapping that around a sphere would have adverse effects on the algorithm I use because the begging and end of the mesh would be joined and the sides would be compressed around a pole (you loose the "grid" part of the grid). Im sure it could be adapted but it would probably be easier to start with an algorithm designed for spherical meshes. here's a web site that you may find handy.
http://vterrain.org/LOD/spherical.html

If you used a spherical mesh with CLOD you wouldnt have to worry about replacing an imposter (sphere) terrain with the real one because at its minimum resolution, the terrain would (well, could depending upon implementation) resolve to a sphere! As you move closer featers can be morphed into place.

feel free to bug me about CLOD stuff if you want opinions or just to discuss options. I havent looked into the specifics of spherical meshes though.

Quote:

---

Originally Posted by Perspective

The first screen shot was in wireframe mode just to show how the algorithm works. When you use filled poly's you dont notice any transition between detail levels at all. The only evidence of the algorithm is the "popping" effect that occurs when the view point changes and vertices are add and removed. This can (will) be remedied by geomorphing the vertices in and out of place instead of just popping them in and out of place.

---

Cool, again, great work, can't wait to see where this goes. :D

Quote:

---

The only thing I can see, is in your first SS, you can easily see the transformation between the shifts, now I didn't notice it as well in the second shot, when the poly's where filled in, I was just wondering if you have looked into any thing to smooth the transition,

---

The idea behind CLOD is to reduce the number of triangles the farther from the camera, or based on some other scheme - but you still reduce the overall number of tri's. After you texture this and light it, you won't notice the CLOD changes as much. It's very hard to linear interpolate smoothly from one LOD to the next because of T intersections and degenerate triangles being produced. Getting rid of T intersections is no trivial task.
The reason you don't notice it in the false color image is because you cannot see the actual tri's - and if Perspective does a bi-linear filter or cubic filter on the terrain, you will never ever notice the difference.

But the popping and geomorphing you will notice quite easily at LOD threshholds or boundaries between two different LODs. Most games to date have simply ignored this problem because it really doesn't look all that bad...and who cares when you are getting fragged by a zillion baddies? But for flight sims and other games where you might actually get to take in the vista of the terrain, solving the geomorphing and popping again is not a trivial task and it is extremely hard to do it in real-time and maintain an FPS that allows interactivity. Remember you only have so many frames and even if your terrain looks awesome, it doesn't matter if it can't be used in conjunction with other classes that control animation, sound, etc. You can't waste everything on just rendering the terrain. There will be tradeoffs.

But for Perspective, he can waste all the FPS he wants getting the terrain to look exquisite since this is not a game.

Well, i got the surface roughness based level of detail working a little while ago. Im still strugling with the geomorphing part of the algo though.

Heres a screen shot of the surface roughness based LOD (with the distance based LOD disabled to help illustrate). Ive been wrassling with the geomorphing with limited success so i needed to post this small victory... heh.

Wow. That looks extremely good Perspective. Given my experience with terrain systems I know how hard it is to produce results like that.

Very, very nice work my friend.

Once you get the system up and running, perhaps a pixel shader is in order. Would be such a waste to use the default vertex lighting scheme. I see you have the normals working correctly in that shot, but it does appear that you are just interpolating from the vertices. I am extremely interested to see what comes of this. And I'd love to talk about the algo here if you don't mind - I really need to get an LOD system up and running.

If you cannot fix the geomorphing I wouldn't worry too much about it - I've seen very few sims where that has been totally removed. FS2004 even pops the terrain now and then. A good engine to look at would probably be FarCry because they are probably using something similar to your setup given their insano viewing distances. Doom3 and Half Life2 prob don't care about terrain too much and specialize more in indoor environments with lots of objects and culling going on.

>Wow. That looks extremely good Perspective. Given my experience with terrain
>systems I know how hard it is to produce results like that.
>
>Very, very nice work my friend.

Thanks Bubba, Im pretty proud of what ive accomplished so far. This is without a doubt the most complex personal project ive taken on to date.


>Once you get the system up and running, perhaps a pixel shader is in order.
>Would be such a waste to use the default vertex lighting scheme.

Very true, ive yet to look into pixel shaders.


>I see you have the normals working correctly in that shot, but it does appear
>that you are just interpolating from the vertices.

I do have vertex normals working however im not using them at the moment. The shading you are seeing is part of the texture. My short term plan is to precalculate a light map based on a fixed sun position and vertex normals. But if i want day/night transitions ill need a dynamic solution like shaders.


>I am extremely interested to see what comes of this. And I'd love to talk about
>the algo here if you don't mind - I really need to get an LOD system up and
>running.

Im up for chatting about this algo any time, I really like the approach it takes. Not only does it provide for efficient LOD system, it also caters nicely to other things commonly done in real time graphics like frustum culling. The first place to start would be Roettgers original paper. Ive read this paper about million times and will probably read it a million more before im done ;)
http://www9.informatik.uni-erlangen....rs/TERRAIN.PDF
He also provides an LGPL implementation but i havent looked at it yet. Im tempted to because of the issues im having finishing off the geomorphing but i really want to "do it my way" and have an unbiased implementation. Ive already based by Triangle-Fanning off an article but its pretty bad and innefficient so i already have plans to rewrite that a different way. (The article actually got a part of the algo wrong at an early stage and just hacked and changed everything to suit the error, even claiming that Roettger may be wrong with some of his formulas...)


>If you cannot fix the geomorphing I wouldn't worry too much about it - I've seen
>very few sims where that has been totally removed.

yeah, with a high detail setting the popping only happens far off in the distance and if you were actually engaged in some sort of game play its unlikely to be a huge factor. However, i dont think I'll be able to let myself do that ;) I'm 3/4 of the way up this mountain and Im determined to get to the top :)