Well, I want to use triangle strips, but I can't get to figure the order of vertex right.
I want to use CCW.
Lets say that I have this triangle strip:

B--D--F--H--J--L
|\ |\ |\ |\ |\ |
| \| \| \| \| \|
A--C--E--G--I--K

Now, which order should I feed the vertex (ABCD...) to OpenGL to render it properly in CCW fashion? (so my lights gets right)

If you wish, please re order the vertex naming in another ASCII art

Thanks a lot.

ACBDEFGH...

See the OpenGL specification 2.0, section 2.6.1.

It always worked for me this way (one gives you CW, the other CCW).

It would be better if all four points of all the quads lay on the same same plane. On a heightmap terrain this is rarely the case.

Just write some code and test it. I usually pick one culling method (usually CW) and flip everything that is rendered incorrectly.

Thanks for all the advice.
Well, I think that I get the theory right, but I still can't figure how to keep this stuff in memory
I did a drawing about how my terrain mesh is organized, to see if someone can advice me a way to keep this on memory ; I think that an array of pointers to arrays or something like that.
My problem is : how to pass the right pointer to OpenGL (when I set the matrix), and how to know the proper size of each array (so I get dynamic memory) ; yes, I have problems with pointers, never got them right

Now, here is my drawing about how I will organize this, theoretically.

http://xs50.xs.to/pics/05414/dsc04334.jpg
(note: the size of grids is just for the drawing, I will have a bigger mesh than 6x6)

At left, is the original mesh, then, I divide it on nXn zones, and each zone (middle) has nXn triangles on them, so I divide each zone on triangle strips (right).
I will render each one of this triangle strips as a vertex array ( this is the part that is giving me the bigger blues)
The idea is: when the player is moving around map, I only draw the zone where the player is on.
If I get this right, I probably will do a multi-zone system, that means, for each "Y" level I will have a set of zones with varying level of detail, so when the player goes higher, I draw more zones (with less polygons each one), and when the player goes near the floor, I draw a more detailed zone.

I don't know if this sounds right or not, and I'm very confused about how I'm going to implement this

Well, thanks for all the advice, and any more advice is very appreciated.

p.s if helps, I'm using C++ to do this, so no malloc/free, but new and delete.

Triangle strips can be useful because with them there should be better use of vertex cache.

I used NvTriStrip Library to build triangle strips out of my models.

Btw, when you divide your heightmap to pieces see that it is not in too little pieces. I think the best size is somewhere around 512-2048 triangles per chunk.

Well, let me first start off by telling you that your idea is flawed. You have to draw all squares that the player can see, not only the one that the player is in.

Furthermore, what you are doing is basically quadtree based culling, here is a good tutorial on it: Gamedev.net Quadtree Tutorial

After you have what you are trying to do down, I also suggest you look into GeoMipmapping, but I'll save the information on that to when you get there.

Sure you can but if there is a tool that can generate the same thing I see little point in coding your own wheel

I can't give any heightmap rendering specific test results but general batch size and speed relation can be found here:
http://www.driverheaven.net/articles/efficiency/testing2.htm It seems like rendering 512 triangles in one patch is about only about 2x faster than rendering 2048 triangles. That means drawing 4x512 triangles takes twice the time than rendering 1x2048 triangles. Of cource these results come from G70 but I'm quite sure other non-r520 based GPU's have about the same efficiency. In real world the situation might not be the same but I don't think rendering the terrain is very pixelshader intensive and is only limited by driver efficienty/vertex shaders.

just because your using triangle strips doesnt mean you need a separate renering call for each strip of triangles, you just need to use degenerate triangles. A good post describing this method can be found here.
Of course, using degenerate triangles means you need a longer strip to save any memory

Afaik, the nv tristrip library could stitch together whatever model you gave it to a single triangle strip

I've been watching this thread and have been interested. This, of course, has been done many times before but is an example of one of those things that is very useful that someone goes through "new" on the first time, learning this stuff. Landscape engines are the "pong" of 3D, imo .

Anyway, generating triangle strips and segments to use for complete hardware implementation is pretty easy and probably using a tool like NvTriStrip is not needed. Definitely one should implement the rendering using VBO or even better vertex + index buffers since in each patch the verts are shared at least twice if not up to 4 times. I don't know how it would go in OGL but I used D3D, which although initially harder than OGL basically forces you to do things at least a "very good way" if not the "best way" by not allowing immediate mode rendering.

I've one other very important point to mention. The intersection of the frustum and the land is actually a trapezoid and not a triangle, and even that is only when the ground is flat. An ultimate solution probably involves a bounding box and frustum check if you allow great distances in height, or a quadtree/octmap if the land allows for concavity.

However, if your view is always on the ground and ground is "flat enough", using a triangle is an excellent optimizing approximation. Interestingly enough in my university I learned a very fast algor for rendering a triangle without clipping on the screen given three points. The frustum problem is the exact same thing if you treat the landscape (in the form of a quadmap) as a "pixellated screen". Literally all I did was replace the "putpixel(x,y)" in the algor with "drawTerrainBlock(x,y)" and you have an extremely fast clipping algor . To account for the approximation, though, you should expand the size of the triangle. The amount to compensate is dependent on the view height from ground, the maximum height difference from lowest to highest point in the terrain, and the maximum amount of pitch (looking down) allowed.

My point is, that when triangle list is properly ordered (eg. you generate strips and fans and merge them all into one triangle list) it shouldn't make much difference whether you are using GL_TRIANGLES or GL_TRIANGLE_STRIP, since post-transform vertex cache will work the same way in both cases. Using GL_TRIANGLES this way seems to be always better than GL_TRIANGLE_STRIP, because you can render geometry in strips using triangle list, while rendering complex object using GL_TRIANGLE_STRIPS usually requires using degenerated triangles or rendering geometry in many parts.

To put it simply, if you are using:

[      mode       ] [ index buffer contents ]
GL_TRIANGLE_STRIP   1 2 3 4 5 6
GL_TRAINGLES        1 2 3 3 2 4 3 4 5 5 4 6

you should get the same performance because of transformed vertex cache. Is there any error in my logic?