Hi,
on my PC I can render the terrain without any checkers, using rude GL_TRIANGLES. My last idea - could you render one more image, on which would be the problematic terrain part and normals ( rendered using lines ) displayed at the same time ?
Thanks,
Petr
Hmmm… So how do I change the windings on the triangles? I have glFrontFace set to GL_CW since that’s how the strips are rendered, which corresponds with how my surface normals are calculated for each triangle.
My index buffer links vertex (x,z) 0,0 with 1,0, then 0,1 and 1,1 then 0,2 with 1,2 etc, all the way up the strip of land, then puts in a 1d triangle to get back to the start to build the next strip.
How did you fix the problem on yours?
Originally posted by glPetr:
[b] Hi,
on my PC I can render the terrain without any checkers, using rude GL_TRIANGLES. My last idea - could you render one more image, on which would be the problematic terrain part and normals ( rendered using lines ) displayed at the same time ?
Thanks,
Petr [/b]
Here’s a patch of checkered terrain with the normal lines poking out of it:
http://www-users.york.ac.uk/~adk105/normals.JPG
The corners of all the patches seem to be at vertices… Hmm…
Actually these ‘artifacts’ are quite normal, regardless of how you generate the normals and what kind of geometry you have. It happens because one of the vertices receives more light. I think this is what Minstrel mentioned.
[img]http://home.planet.nl/~buijs512/_temp/normals.jpg[/img]
Here the normal at v2 is pointing more towards the light source; is brighter than the other verts so the interpolated color will result in the brighter diagonal stuff.
Changing the winding may solve the problem locally, but it will apear on other slopes of your terrain again.
What you can try is to render with GL_QUADS, as quads interpolate the color from all 4 vertices (instead of 3).
Furthermore, if your light sources don’t move, I suggest computing a lighting texture at load time and using that. You can also disable lighting and do your own per vertex lighting calculations (glColor instead of glNormal) or shaders and reduce this but it all depends on your needs.
I see, that makes a lot of sense. Using triangle strips probably exacerbates the problem too.
Hmm, well, I was continuing to battle this out only for closure, since I have become quite fond of the lightmap idea due to my only having one stationary lightsource.
I’ll put my attentions towards texturing instead now 
Thanks for the information!
If anybody still thinks the problem can be solved though, I’m always keen to hear more ideas
Interpolating vertex lighting over a polygon is not the same as interpolating the vertex normal and using it to compute lighting per-pixel. With per-vertex lighting, you’re essentially applying a linear gradient over the polygons in an attempt to simulate the appearance of a curved surface. If you think about it, there’s no way this is going to look right.
For the fixed function, per-vertex stuff, the best you can hope to do is tessellate your terrain to the extent that the actual geometry and normals approach that of the curved surface being approximated. Or, as K_szczech suggested, use a high-resolution lightmap.
On the other hand, by interpolating normals instead (with renormalization), you can achieve a similar result, but without all the added geometry. Plus, you’ll have per-pixel normals that can be used for reflection, bumpmapping, and what have you.
Originally I had intended to go down the route of per-pixel lighting, however I’m pretty sure the computers this has to run on will not be able to handle such detail. Since the main aim of my project is not quality (that’s just a personal aim), I think a high-resolution lightmap is the way to go.
I just thought that the per-vertex lighting wouldn’t be quite as bad as it turned out to be!
It continues to surprise me as well