Tnx

Thank you. Nerveless "geometry clipmapping" is a 100% GPU technique :P. Will take look at ROAM also. Seems very complicated.

Green_Baron said:

Yes, but much of it is renderer stuff and not directly connected to the lod algorithm. First read the paper. And you will have to go through this yourself in order to understand what's going on. I did actually take the time for myself to dissect and re-implement it in my environment.

But because i am a nice guy and have some time, here's a high level overview:

Setup:

• For a given heightmap texture, build a quad tree hierarchy of nodes, calculate their bounding boxes, offsets and sizes.
• prepare a regular gridmesh the size of a single node
• calculate lod level ranges and transition areas from higher to lower lod level (this can also be done in the loop).

In the loop:

• select the nodes that appear in the view frustum, sort them front to back
• for every selected node, draw the gridmesh
• for every vertex/grid mesh position:
• calculate the world position and determine the distance to the camera from the node's offset and size.
• use lod level ranges to morph the base grid from higher to lower levels, displacing the positions slightly in 2d. Don't forget height displacement (*).

Or use roam or geometry clipmapping, afaik they lend themselves better to cpu based lodding, but need more preparation and gymnastics to optimize meshes, stitch and skirt nodes, can pop between lod levels and so on.

(*) in the vertex shader, this can be done in two steps, a pre- and an exact lookup, so that terrain height is already observed for morphing.

Have fun :-)



There is one thing I dont understand from the papers and you description. The QuadTree, do I have to Split and and Unsplit the nodes in the loop depending on the distance, before I select the nodes?

Baron said:Yes, but much of it is renderer stuff and not directly connected to the lod algorithm. First read the paper. And you will have to go through this yourself in order to understand what's going on. I did actually take the time for myself to dissect and re-implement it in my environment.But because i am a nice guy and have some time, here's a high level overview:Setup:For a given heightmap texture, build a quad tree hierarchy of nodes, calculate their bounding boxes, offsets and sizes.prepare a regular gridmesh the size of a single nodecalculate lod level ranges and transition areas from higher to lower lod level (this can also be done in the loop).In the loop:select the nodes that appear in the view frustum, sort them front to backfor every selected node, draw the gridmeshfor every vertex/grid mesh position:calculate the world position and determine the distance to the camera from the node's offset and size.use lod level ranges to morph the base grid from higher to lower levels, displacing the positions slightly in 2d. Don't forget height displacement (

Actually I just understood that! It tests every time the 4 child's for if it's not in more finest level. Now Im trying to understand (make a picture in my head :D), how cdlod handles when you are vertically away from the mesh (like far away from planet)

Ok I think I understood that! Sorry for trolling!

"For a given heightmap texture, build a quad tree hierarchy of nodes, calculate their bounding boxes, offsets and sizes"

I don't understand yet this part. How is the quad tree generated from height-map. What does it mean? How does the height-map effect the quad tree structure?

good. i like

Yeah, ok.

But that is all explained in great detail in the paper linked on the github account, i can't do it any better. And, btw., i had to read it 2 or 3 times as well, if that comforts you :-)

If you want to go with cdlod (which imo is the most straight forward take on terrain lod, others are more complicated), let me suggest that you build a basic version of the algorithm, without normal- and shadow mapping, building a node hierarchy, doing the selection process, and only draw the bounding boxes without terrain yet. You'll need that functionality anyway later for debug purposes.

hangchuyenhang said:

good. i like



Whaat?

Green_Baron said:

Yeah, ok.

But that is all explained in great detail in the paper linked on the github account, i can't do it any better. And, btw., i had to read it 2 or 3 times as well, if that comforts you :-)

If you want to go with cdlod (which imo is the most straight forward take on terrain lod, others are more complicated), let me suggest that you build a basic version of the algorithm, without normal- and shadow mapping, building a node hierarchy, doing the selection process, and only draw the bounding boxes without terrain yet. You'll need that functionality anyway later for debug purposes.



I opened a thread in https://gamedev.stackexchange.com/questions/177378/question-about-cdlod-quad-tree . Maybe u can look into. I also read the paper 4-5 times. But this questions don't think are answered there

Ok, i think i understand your problem.

For this kind of lod technique you need the heightmap texture. That can be a perlin noise generated texture, but it needs to be fully available in its finest grain when the tile is loaded and it's quadtree is generated. Calculating min/max heights for a region of that tile, a node, is then nothing more than a nested loop and a comparison.

Somebody interrupt me if i talk nonsense, but i think that if you use a noise function to generate your terrain "on the fly", you must take a different approach for lodding, e.g. refine the octave or frequency as you come closer and generate your mesh accordingly. All the lod we talked about until now requires the data to be available when the spacial data structure is generated, or that it can be generated or loaded fast enough even at the highest detail level. Which is, if i may say, impossible with todays technique at interactive rates when using noise for a planet's surface at a resolution of let's say 10m.

Hope that wasn't totally nonsensical, if so, maybe a more experienced person helps me out.