Sign in to follow this  

Terrain render problem: overlapping patches

This topic is 4103 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
ROAM is notoriously slow.
Divide your terrain into patches, draw each patch with VBOs/VAs with triangle strips and frustum cull unwanted patches. Or CLOD.
I've seen ROAM do a terrain at 8fps but the same terrain is 70fps with another algorithm.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
try the book "Focus on 3d Terrain Programming" - you can read it in about a weekend. Lots of demos on it.
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
Ok, seems that the link is really broken. I found another one http://hasusmurf.ha.funpic.de/downloads/geomclipmap2.pdf. Hope that one works, it did a minute ago.

Also there seems to be an open source implementation, but I have to check that one out. The problem is, that it's in german, but try the code links in the section "Fertiggestellte Implementierung". Here's the link anyway: http://wwwisg.cs.uni-magdeburg.de/~spindler/wiki/ShaderSeminar2005/index.php?n=Projects.TerrainRendering.

Share this post


Link to post
Share on other sites
Quote:
Original post by Silverclaw
gluPerspective(45.0f, (GLdouble)resol.xx/(GLdouble)resol.yy, 0.0f, 500.0f);


Your near clipping plane should not be at zero. The perspective calculations involve (far - near) / near, which has obvious problems when near is zero. I don't know if this will solve all of your problems, but the z-fighting will probably stop if you change your near plane to 1.0:

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

Share this post


Link to post
Share on other sites

This topic is 4103 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this