After a few weeks of research and coding, I finnaly completed my terrain renderer using a Split-only ROAM implementation. Sadly, the engine is running slow, I'm guessing it's because I'm using triagle output (instead of fanning or striping). I had to adapt the renderer to my previously made engine in which I rotate the matrix twice: first, I rotate it so that the zz-axis points upwards (positive), the yy-axis inside the screen and the xx-axis remains untouched. After that, I render the heightmap using the "z" coord of the glVertex3f has the height at the vertex's location. Everything runs fine and I have have the players mesh walking on the terrain correctly. So, I switched from wireframe to textured mode, and I noticed that some triangles that should be behind a hill, appear in front of it. Sometimes I have the player floating in mid-air because the triangle (terrain-patch) that he "suposably" should stand on doesn't get to the screen. My guess is that it got culled by the z-buffer, so I de-activated it. No effect. Tried to cull back-faces and so on, but only managed to reduce the ammount of triangles misplaced. Any ideas?

What values are you using for your Near and Far planes? Try to reduce the distance between them, sounds like you are running into precision issues.

gluPerspective(45.0f, (GLdouble)resol.xx/(GLdouble)resol.yy, 0.0f, 500.0f);

So, I can assume that the error has nothing to do with my glRotate and subsquent Z-axis growing to top of the screen? Also, by activating z-buffering again (depth-testing), will it not generate problems? I had to de-activate it and order terrain patches to draw from far to near.

I'd change the algorithm, but the information I find on the net is somewhat obscure and making a program out of it is difficult. For example, Thatcher Ulrich's implementation is well-known and fast, and the article he wrote is elucidative, but he failed to explain how the algorith prevents t-junctions (mesh consistensy) in his article. A bit of code there would make things clear. I tried to find implementations on the net to check out the code, but I am still unexperienced and the code is confusing. Also, it is my intention to make a deformable terrain, and that is impossible with some implementations where the error-ratio is precalculated.

Any suggestions? I've already dug up vterrain.org and several other articles and pdf's.

about your real problem: it is called z-fighting and is caused by loss of precision on depth buffer. look for "polygon offset" opengl call, which will resolve such things for you.

Quote:Original post by ade-the-heat
I don't see what you don't understand about the method I suggested - just everything into VAs and draw using glDrawElements to draw a patch.

My problem is extrating the triangle division into strips. I'm currently reading about SOAR, but again, the terrain mesh is static, but I have some ideas to work around this.

Again I ask if the rotation of the axis I made interfere with the Z axis buffer. Depth testing after the transformations will be made on the yy-axis?

If you're able to use gpu programs you could use this approach: Terrain Rendering Using GPU-Based GeometryClipmaps.

This seems to support deformable terrain.

The link you supplied is broken. I attempted to download the file with Firefox resulted in a "corrupted file" error by Acrobat Reader.