Sign in to follow this  

Terrain + Water Plane Z-Fighting

This topic is 4167 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

Hello. In my game, I have a large depth distance ratio: draw_distance = 5000000.0 near_draw_distance = 3.0 This is because I am using a scale of 1 unit = 1 feet, and flying is an important part of the game. Now, in my game I have a large, low-detailed terrain. It consists of a 128 x 128 grid of quads (with 1500 x 1500 dimensions per quad). I also am drawing water using another single quad that spans across the entire terrain. I am having problems with Z-fighting with the water plane and the terrain. I set the depth buffer to 24-bit to no avail. My card does not support 32-bit depth buffers. Having the vertices match is also not practical because of the low detailed terrain. Is there a way to fix the z-fighting by changing the depth buffer or by using the stencil buffer? How else can I eliminate the z-fighting? Also, I have buildings on my terrain (textured boxes). When the textures are somewhat far away, they "sparkle" when the camera moves. I am using bilinear filtering with no mipmapping because the mipmapping makes everything TOO blurry. Is there a way to change the mipmapping bluriness? How else can I fix the sparkling textures? I tried downsizing the textures so that they would be less detailed, but they still sparkle. Here is a screenshot that illustrates the location of each problem (though the still-life image does not show the actual sparkling or the z-fighting): http://thechuckster.homelinux.com/~chuck/screenshot27.jpg

Share this post


Link to post
Share on other sites
Reducing your depth range will help a lot. Moving your near clip plane further out tends to result in the biggest improvement. Do you really need it at 3.0? (If you do, you might want to reconsider the scale you're using.)

Using mipmaps should resolve the sparkle problem.

Edit: Didn't notice you already ruled mipmaps out. Well...they are the standard solution for that problem that every game on earth uses. They do tend to get excessively blurry at sharp angles--the solution to this would be to enable anisotropic filtering in your video driver.

Share this post


Link to post
Share on other sites
I need it at 3.0 because the plane model is displayed up close in first-person view. Is it possible to use two different viewports with different draw distances in order to draw the up close stuff and then the terrain/water?

Share this post


Link to post
Share on other sites
By first-person do you mean in a plane's cockpit or something? In that case you could just draw the world with a further near clip plane, clear your Z-buffer, change the clip planes, then render the interior.

Share this post


Link to post
Share on other sites
Quote:
Original post by MARS_999
You could try turning off depthmask in OpenGL and see if that solves your problems with the terrain z fighting...

glDepthMask(false)


...I'm not sure how turning off depth writes will help unless he's already rendering things back to front?

Edit: You mean when he draws the water, right? I don't follow how that would help...he'd still be doing a depth test against an inadequately precise depth buffer for the range he wants, wouldn't he?

Share this post


Link to post
Share on other sites
Quote:
Original post by TheChuckster
I need it at 3.0 because the plane model is displayed up close in first-person view. Is it possible to use two different viewports with different draw distances in order to draw the up close stuff and then the terrain/water?
It certainly is possible. It is quite common to have multiple view frustums (viewports are different) in large space scenes. The basic procedure is...
 · split up the main frustum into however many divisions you need
· for each frustum from furthest to closest
· render parts of the scene contained in this frustum
· clear the depth buffer
For relatively empty scenes (such as outer space) the frustums don't necessarily have to touch or overlap.

Share this post


Link to post
Share on other sites

This topic is 4167 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