Could one of you gl gurus please verify my terrain alogrithm ?
I haven’t programmed it fully yet, but I think it should work well.
I have a triangle based terrain. It is represented as an 2D array
with height values in it. All this data is rendered into one big
To speed up redering, I tried to minimize state changes. So I sort the
polys by texture. When I have three textures, I only need three glBegin()
statements and three changes to the texture state. This gave an performance boost.
Now I want greater terrain. Reducing the view depth (the far clipping plane)
doesn’t bring much. I think I have to manually decide which polys are
in my viewing range. My solution to this:
I divide my terrain into smaler square areas. These areas are rendered into their
own display lists. Then I do a quick check which of these areas are into my
view (shouldn’t be that problem). But now I can’t benefit from sorting the textures.
When I have 10 textures, I have 10 glBegin()/glEnd statements and 10 texture state
changes for EACH of my square areas. A solution would be to create for each texture
in each square area a own display list, but is this a good solution ?
Any ideas for optimizing this alogrithm or a better one would be great…
I hope my English was good enough to make myself clear.