Near Clip Plane and Radeon Z-Buffer Problems.

[Jamm0r]

Howdy,

We're having Z-Buffer issues with Radeons on a PC Simulation project I'm working on. Here's an example:

Only Radeon r200 and r300 vide cards suffer from this rendering error. Basically, when in the cockpit, where we set a near clip distance of 8, some objects such as tree lines and portions of the landscape seem to loose their Z values, and show through the scenery, as can be seen above. In external view, where the near clip plane is set to 200, the problem disappears. Nvidia and other video card users do not have these rendering errors.

Any ideas?

 

[sireric]

What's your far plane set at? If your far/near ratio is too large, you'll exceeed the precision of the Z buffer.

Different cards have different rendering techniques. Are you using 16b or 24b Z?

 

[Jamm0r]

sireric: 16 or 24 doesn't seem to make a difference. Far clip plane is set to the minimum possible value implemented by the original developers (I'll dig it up in a few minutes, and it's not a huge value IMHO.) Here's another shot that better illustrates the problem:

I set the near clip value to 8 for this external shot. Normally, it would be 200 as I stated above.

 

[Jamm0r]

The minimum far clip value ("Near" horizon distance), without some tweaks we recently added, is 1114112. However, we recently added a multiplier, selectable through the GUI, that decreases this significantly if needed. In the rainy condition seen above, which I coded, the clip value is 1114112 * 0.3

 

[Jamm0r]

I think that says it all. As you can see, the far plane is set to 314572. I'm using the line:

g_lpLib3d->SetNearClipPlane( NON_COCKPIT_NEARZ );

to experiment with different near clip values. When I set the near plane to NON_COCKPIT_NEARZ ( 200 ), I get no rendering issues. When I set it to COCKPIT_NEARZ ( 8 ), I do.

 

[Jamm0r]

Is there a problem with Catalysts and applications using the D3D7 EnumZBufferFormats? I'm noticing that the returned ZBufferBitDepth and StencilBitDepth values are not what they should be...

 

[KimB]

Well, that ratio shouldn't be that excessive.

Unreal Tournament uses 0.5 for the near clip plane, and 32,768 for the far plane. That's about twice as high a ratio. While there are z-buffer errors in UT, they are typically not anywhere close to that severe. I usually only notice them with decals.

 

[Kristof]

Try using a tweak tool to disable HyperZ and other options. On FableMark we found that to get it to render correctly on R200 we had to disable HyperZ (caused a weird Z issue with stencil shadow effect) and even hardware vertex processing (different lighting paths were causing slightly different vertex results and created Z-Fighting) for some driver revisions. I am not sure if these issues got fixed in later driver releases.

K-

 

[Jamm0r]

Thanks for the replies. Kristof: is it even possible to disable Hyper-Z and other options on the r300? I know it's possible on an r200, but I was under the impression that these tweaks didn't work on an r300.

 

[Jamm0r]

Ok. I fixed the problem. Early on in rendering, a check is made if the viewpoint is in the cockpit or not, and sets the near plane to 8 or 200, as discussed above. This is wrong, because it is being set to 8 BEFORE rendering the landscape (and clearing z.) Since it already sets the near plane to 8 right before rendering the cockpit, I changed it from 8 to 200 (before rendering the lanscape.)

Ahh well, this was definitely an interesting, if not frustrating, experience. Thanks again for all the help. I would have preferred if ATI had a more precise Z-buffer in the first place, even if it costs a little in the speed dep't.

 

[Kristof]

Not sure, our problem never appeared on R300 only R200 so I never really tried.

K-

 

[OpenGL guy]

Ok. I fixed the problem. Early on in rendering, a check is made if the viewpoint is in the cockpit or not, and sets the near plane to 8 or 200, as discussed above. This is wrong, because it is being set to 8 BEFORE rendering the landscape (and clearing z.) Since it already sets the near plane to 8 right before rendering the cockpit, I changed it from 8 to 200 (before rendering the lanscape.)

This sounds weird. It sounds like you are changing the near plane without clearing the Z buffer, this is a very bad idea. The Z buffer values depend on the near and far planes so if you change them, you must clear the Z buffer. Sorry if I am misunderstanding you.

Ahh well, this was definitely an interesting, if not frustrating, experience. Thanks again for all the help. I would have preferred if ATI had a more precise Z-buffer in the first place, even if it costs a little in the speed dep't.

I can't speak for the R200, but the R300 has about the same Z accuracy as the GeForce 4. I've verified this myself. However, the GeForce 4 (and R200) has W buffering which the R300 does not support so this can cause some differences in results.

 

[Jamm0r]

We do indeed clear Z when modifying clipping planes. And yes, you are correct, the game uses a W-buffer if available.

 

[OpenGL guy]

We do indeed clear Z when modifying clipping planes. And yes, you are correct, the game uses a W-buffer if available.

Then that explains why you didn't see any problems on the GeForce

 

[Jamm0r]

Rgr that.