[SOLVED] Near Clipping Plane and Z-Fighting

[ulf.schroeter]

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 ?!?

 

[Steve Yin]

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.

[Guest extaliones]

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.

[ulf.schroeter]

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

[ulf.schroeter]

Took some time, but finally there is a solution for improved z-buffer precision in UNIGINE on platforms with supported 32bit float depth buffer support (DX/DX11?)

 

Added render_use_d32f console command to toggle a depth buffer with 32 bit floating point precision. (For example, for rendering more then 100 km within the visibile range).

[manguste]

Yep, it's here - both for DirectX and OpenGL :)

[ulf.schroeter]

Just some updated great background information on depth buffer precision and how to improve it. Still sad in a way that depth precision even with float depth buffers is wasted to a very big extend.

[Ugly1-1]

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 :)

[ulf.schroeter]

Took a while,but finally logarithmic depth buffer found its way into Unigine engine

 

https://developer.unigine.com/en/devlog/20151120-unigine-2.1