Textures tear at distance

Started by
6 comments, last by Ravyne 9 years, 8 months ago

Hello!

I have been building a simple game engine in C++ with SDL and OpenGL / GLEW. I have simple textures and meshes working properly, except that they seem to tear and move when viewing things from a distance. What could be causing this? Does this artifacting have a name? Is there a process or technique to get rid of this kind of tearing?

The following link contains a video:

. Notice how the tearing only happens up close, and disappears when moving farther away.

There's a lot of code in my engine so far, and I didn't want to flood this post with code. If you need me to post something specific, just let me know.

Please and thanks for the help.

Advertisement

That looks like z-fighting to me, not tearing. What resolution is your depth buffer? What are the values for your near and far plane, and how far away is your model from the camera?

GL_DEPTH_SIZE is 16,

Znear is .01 and zfar is 1000,

Model is huge in gl coordinate space, the camera moves fast. So maybe 200-400 units (at farthest point)?

I just realized playing with znear seems to help a lot. I've moved it to .5 from .01 and the z-fighting seems to have almost vanished! =D

Should I modify the depth buffer size, too?

Thanks for the help!


I just realized playing with znear seems to help a lot. I've moved it to .5 from .01 and the z-fighting seems to have almost vanished! =D
Correct - The overall Z precision is a function of (zfar-znear) / znear. The presence of znear in the denominator means it has a huge impact on your available depth precision. The larger you can make it, the better.
SlimDX | Ventspace Blog | Twitter | Diverse teams make better games. I am currently hiring capable C++ engine developers in Baltimore, MD.

Should I modify the depth buffer size, too?

Yes, do this too.

A 16-bit depth buffer is woefully inadequate. All hardware for the past 15-odd years is absolutely guaranteed to support either 24-bit (with 8 unused), 24-bit (interleaved with 8 for stencil) or 32-bit depth buffers. There's nothing to gain from using 16-bit unless you want to run on an ancient original 3DFX or some weird mobile platform.

Direct3D has need of instancing, but we do not. We have plenty of glVertexAttrib calls.

Changing the depth buffer to 24 bit without any problems. Thanks again for the help!

You can also adjust near/far clipping planes on the fly. After all, it's just projection matrix.

Its more detailed than what I can adequately explain in the limited time I have, but you would be wise to go find an article that talks about the distribution of depth values that results from the near and far values you choose. The naive assumption most people make is that you want near to be as near to 0 as possible, and far to be as far away as practical, but IIRC, that generally gives less than optimal results.

Also, as vstrakh said, you can change them on the fly as you render different parts of your scene. For example, some games render very far-away objects as a means to enhance the "skybox" (perhaps because the objects are animated, dynamically lit, or are far away but near enough for perspective to matter) and those would probably benefit from a different distribution of depth values. Its also a handy technique in space games, where the distances are great and the space is sparsely populated. In general, the maxim seems to be that this is helpful when you mix very large objects at great distances together in a scene with relatively smaller objects at much smaller distances. I imagine that the borders between level-of-detail transitions might also make a good candidate, but it probably depends on how near or far the borders are.

throw table_exception("(? ???)? ? ???");

This topic is closed to new replies.

Advertisement