Jump to content
  • Advertisement
Sign in to follow this  
Silverclaw

Terrain render problem: overlapping patches

This topic is 4465 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
Advertisement
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
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!