Jump to content

[SOLVED] Near Clipping Plane and Z-Fighting


photo

Recommended Posts

Hi UNIGINE,

 

while testing rendering of overlay/subface surfaces (e.g. river in the screenshot with material using polygon offset 4) on larger ground surfaces we realized that z-fighting artifacts decrease when decreasing near clip plane distance.

 

This is a little surprise for us as general advice (e.g. OpenGL-programming) for decreasing z-fighting always has been to increase near clip plane distance as much as possible to increase z-buffer precision ?!?

 

post-82-069245700 1287417673_thumb.jpg

Link to comment

well, I think there is a way to solve this, but I don't know if it is suite for you.

 

see, your object might have local transfrom, means the center of your mesh is not placed in geometry center, most likely your object center is far from it's geometry center, so, this will happen.

 

In your case, the problem seems only on z axis, but if your rotate your world around x, or y axis, it will still happen.

 

My advise, move center of mesh to a meanful position, like bottom of object or center of geometry, then use node transform to position the object in world.

Link to comment

for decreasing z-fighting always has been to increase near clip plane distance as much as possible to increase z-buffer precision

If you decrease near clip plane distance it means you increase z-buffer precision so z-fighting artifacts decrease.

Link to comment

If you decrease near clip plane distance it means you increase z-buffer precision so z-fighting artifacts decrease.

 

Unfortunately moving the near clip plane to small values reduces z-precison in the distance -> z-fighting/flimmering in the distance (bad for outdoor scenes).

 

Found some interesting stuff on

 

Logarithmic Z-Buffer + Improved Logarithmic Z-Buffer

 

Maybe this could also be included into UNIGINE

  • Like 3
Link to comment
  • 2 years later...
  • 2 weeks later...
  • 9 months later...

When I had this problem in another engine I cheated a little with a hack that offset the z-buffer value. The offset was a fudge factor based on the linear distance between the camera and the vertex. Basically it was along the lines of (this can be optimized but it's clear what it does)...

	// I need the depth offset proportional to the camera distance from the vertex
	#ifdef DEPTHOFFSET
		float dist = length(modelvertex.xyz - cameraposition ) / 512.0;
		float z = DepthToZPosition(gl_FragCoord.z);
		z = z - dist;
		gl_FragDepth = ZPositionToDepth( z );
	#endif

And could only be used on certain objects where z-fighting was a problem with objects close to the camera. Hacky or what?

 

Non-linear depth buffers like those referenced above are a great solution, Brian's solution was referenced and tested in Patrick Cozzi's book on virtual globes. When these APIs were specified I don't think people considered we'd have the power to render life-like planets with them so it's not surprising we're seeing some shortcomings in this area :)

Link to comment
  • 2 years later...
×
×
  • Create New...