Logarithmic Z Buffer Issue

Unity Engine
1

Hi,

I’m trying to implement logarithmic depth buffering in a Unity surface shader as explained in this Outerra blog http://outerra.blogspot.co.uk/2009/08/logarithmic-z-buffer.html.

In the first pic I’m using the standard unity diffuse shader and in the second I’m using my logarithmic shader: -
1437451--76947--$diffuse.gif
1437451--76948--$log..gif

As you can see the planet has been flattened on the z axis and the terrain skirts are z fighting with the planet surface. Has anyone else experienced these kind of problems? Any help would be muchly appreciated.

Here is the shader code: -

Shader "Custom/LogDiffuseSurf"
{
	Properties
	{
		_MainTex ("Base (RGB)", 2D) = "white" {}
	}
	
	SubShader
	{	
		Tags { "RenderType"="Opaque" }
		LOD 200
		
		CGPROGRAM
		#pragma exclude_renderers gles
		#pragma surface surf Lambert vertex:vert

		sampler2D _MainTex;

		struct Input
		{
			float2 uv_MainTex;
		};
		
		void vert(inout appdata_full v)
		{
			float c = 1.0;
			float far = 1000000;
		
			v.vertex.z = log(v.vertex.w * c + 1) / log(far * c + 1);
			v.vertex.z *= v.vertex.w;
		}

		void surf(Input IN, inout SurfaceOutput o)
		{
			half4 c = tex2D(_MainTex, IN.uv_MainTex);
			o.Albedo = c.rgb;
			o.Alpha = c.a;
		}
		ENDCG
	} 
	
	FallBack "Diffuse"
}

Further info: -

  • The camera is sitting at the origin with 0.3f near and 100000 far clipping planes.
  • The planet is sitting at x0 y0 z10,000 and is constructed of multiple ‘chunk’ gameobjects
1 Like
2

I think he says Using the following equation to modify depth value after it’s been transformed by the projection matrix: The coordinates you are modifying are still in object space.

3

He sure is saying that. The adjustment should be in clip space instead of object space.

I’m not sure whether this is possible when combined with surface shaders. With a full shader it should be easy. I’m not sure where you would have to output you own custom clip space position and whether that would actually work with a surface shader. The whole idea of a surface shader is that you focus on the appearance of the material and let unity handle the normal decoding and z-buffer writing.

4

It’s a pretty interesting concept. I used to read that guys blog a lot it’s quite impressive. Yeah you are right on the surface shader stuff. I heard in Unity 4 you can actually modify the z-buffer. So rather than transforming the verts you might be able to just modify the z-buffer directly. Well I guess that might be what you are doing by moving the vertex coordinates:)

5

The color of the pixel is actually the only mandatory thing a pixel/fragment shader must write out. There is an optional depth value in for example HLSL. Writing a depth value in a surface shader should work just fine. (Wouldn’t break the generated prepasses, forward passes, etc.) The only place it probably would break things is in the depth passes for the shadow maps. But I’m guessing not many people are using custom depth shaders for the shadow maps anyway.

6

Thanks for the replies. I did try the same thing in a basic vert/frag shader but it produces the same results (apart from the lack of diffuse lighting ofc). I’m not clear on why as in this one you can see it is transforming to clip space first (or at least that is my understanding of multiplying by UNITY_MATRIX_MVP).

I’ll try editing the depth value in the frag shader and see what happens.

Shader "Custom/LogDiffuse"
{
	Properties
	{
		_MainTex ("Base (RGB)", 2D) = "white" {}
	}
	
	SubShader
	{
		Pass
		{
			Tags { "RenderType"="Opaque" }
			LOD 200
			
			CGPROGRAM
	        #pragma target 3.0
	        #pragma vertex vert
	        #pragma fragment frag
	        #include "UnityCG.cginc"
	            
			sampler2D _MainTex;
			float4 _MainTex_ST;
			float c = 1.0;
			float far = 1000000.0;
			float offy = 1.0;
			
			struct v2f
			{
				float4 pos : SV_POSITION;
				float2 uv : TEXCOORD0;
			};
					
			v2f vert(appdata_base v)
			{
				v2f o;
				
				o.pos = mul(UNITY_MATRIX_MVP, v.vertex);
				o.pos.z = log(c * o.pos.z + 1) / log(c * far + 1) * o.pos.w;
				o.uv = v.texcoord;
				
				return o;
			}
	
			half4 frag(v2f i) : COLOR
			{	
				half4 c = tex2D(_MainTex, i.uv);
			
				return c;
			}
			ENDCG
		}
	} 
	
	FallBack "Diffuse"
}
1 Like
7

Here’s first attempt messing with depth. Creates some interesting results! I tried placing two spheres slightly apart scaled to xyz100,000 at z100,000 from camera. One sphere appears to overlap the other. What’s strange is moving the sphere that appears behind towards the camera does not cause it to draw in front of the other one even if you bring it really close to the camera!

Shader "Custom/LogDepth"
{
	Properties
	{
		_MainTex ("Base (RGB)", 2D) = "white" {}
	}
	
	SubShader
	{
		Pass
		{
			Tags { "RenderType"="Opaque" }
			LOD 200
			
			CGPROGRAM
	        #pragma target 4.0
	        #pragma vertex vert
	        #pragma fragment frag
	        #include "UnityCG.cginc"
	            
			sampler2D _MainTex;
			float4 _MainTex_ST;
			float c = 1.0;
			float far = 1000000.0;
			float offy = 1.0;
			
			struct v2f
			{
				float4 position : POSITION;
				float2 uv : TEXCOORD0;
			};
					
			v2f vert(appdata_base v)
			{
				v2f o;
				
				o.position = mul(UNITY_MATRIX_MVP, v.vertex);
				o.uv = v.texcoord;
				
				return o;
			}
	
			void frag(in v2f i, out half4 col:COLOR, out float depth:smile:EPTH)
			{	
				half4 c = tex2D(_MainTex, i.uv);
			
				col = c;
				depth = log(c * i.position.z + 1) / log(c * far + 1) * i.position.w;
			}
			ENDCG
		}
	} 
	
	FallBack "Diffuse"
}
8

My theory is that Unity already uses the reverse depth buffer trick from here: Outerra: Maximizing Depth Buffer Range and Precision

9

I’ll give that a read thanks.

Further testing shows that there is a problem writing depth values in general as setting the depth to any value even a fixed one e.g. 0 or 1 produces the same output as if it is ignoring the depth completely.

10

I’m reviving this thread to see if anyone has figured out how to do this in Unity yet. Here’s another thread where someone was able to get it working, but his solution didn’t entirely work for me. Custom Z-buffer problem on mac and windows - Unity Engine - Unity Discussions . When I tried it, using .01-1bill on the cameras culling planes, I didn’t have normal Z-tearing issues like you would expect. However the draw order seemed backwards, like it was drawing back to front, so I could see faces that should have been blocked by closer geometry.

I would like to get it working with surface shaders though (like OP was trying to do here) because I am still learning shaders and it seems like surface shaders do a lot of the boilerplate stuff for you. It seems like you can only edit the input vertices for the surface shader though.

I’m making a space exploration game and my current setup is with two cameras, one from .3-1000 and the second from 1000-1million, but I would like to reduce the overdraw of objects in both cameras (among other reasons). That is why I am searching for alternatives.

Thanks,
-Buck

11

Here’s my implementation of Outerra’s solution in a planetary terrain shader, it works flawlessly for me so far.

            struct a2v
            {
                float4 vertex : POSITION;
                float4 texcoord : TEXCOORD0;

            };

            struct v2f
            {
                float4 pos : POSITION;
                float2 uv : TEXCOORD0;
                float2 uv2 : TEXCOORD1;
                float flogz : TEXCOORD2;
                float3 lightDirection;
            };
      
            struct Output {
                float4 col:COLOR;
                float dep:smile:EPTH;
            };

            v2f vert (a2v v)
            {
                v2f o;
           
                o.lightDirection = WorldSpaceLightDir(v.vertex);
                o.pos = mul( UNITY_MATRIX_MVP, v.vertex );
           
                o.pos.z = log2(max(1e-6, 1.0 + o.pos.w)) * (2.0 / log2(_ProjectionParams.z + 1.0)) - 1.0;
                o.pos.z *= o.pos.w;
                o.flogz = 1.0 + o.pos.w;
                return o;
            }

            Output frag(v2f i)
            {
                Output o;
                o.col = color;
                o.dep = log2(i.flogz) * (0.5 * (2.0 / log2(_ProjectionParams.z + 1.0)));
                return o;
            }

I cut out almost everything that wasn’t essential to the log depth buffer.

2 Likes
12

Can’t you use the _ProjectionParams built-in shader variable instead?

// x is 1.0 (or –1.0 if currently rendering with a flipped projection matrix),
// y is the camera’s near plane,
// z is the camera’s far plane
// w is 1/FarPlane.
float4 _ProjectionParams;
13

Yes, you absolutely can. Updated my post above.

14

I don’t believe it did, but it does now in the Unity 5.5 beta, so logarithmic z-buffer modifications should no longer be necessary for most scenes:

Graphics: Improve shadows precision for large worlds

Use reverse-float depth buffer for improved depth buffer precision on modern GPUs. Particularly improves directional light shadowing for large view distances.

15

According to Aras inverse-z is in 5.5, but only for DirectX 10+ ( DX9 has no floating point depth buffers and relevant GL-extensions are not available on Mac / mobile, so no inverse-z for DX9 and OpenGL)

1 Like
16

Thanks for the clarification there.