Decals z-fighting [SOLVED]

Problems building or running the engine, queries about how to use features etc.
Post Reply
Oogst
OGRE Expert User
OGRE Expert User
Posts: 1034
Joined: Mon Mar 29, 2004 8:49 pm
Location: the Netherlands
Contact:

Decals z-fighting [SOLVED]

Post by Oogst » Sat Feb 27, 2016 12:36 pm

Shadows on the ground in my game Cello Fortress are simply planes with a texture. This means I want to put those shadowplanes at the same height as the ground itself, like a decal. However, my shadowplanes partially disappear under certain angles or when I come too close.

I figured the only thing really needed would be to let Ogre render those objects last, but it isn't working. I'm using the following material definition:

Code: Select all

material GroundShadowMaterial
{
	technique
	{
		pass
		{
			scene_blend dest_colour src_colour
			depth_write off
			transparent_sorting force
			depth_bias 1
			texture_unit
			{
				texture Lightmap.tga
			}
		}
	}
}
According to documentation depth_func defaults to less_equal, so that seems fine as well.

I've also noticed that if I zoom the camera out, the shadows starts appearing on top of other objects, as if it gets an extreme depth_bias. This happens even if I remove the depth_bias.

What am I doing wrong here, why are my shadowplanes z-fighting?

Thanks in advance! :)
Last edited by Oogst on Sun Feb 28, 2016 12:34 am, edited 1 time in total.
0 x
blog.oogst3d.net: my dev blog and portfolio
Ronimo Games: my game dev company
Awesomenauts: platforming MOBA (PC/Mac/Linux/XBox360/PS3/PS4)
Swords & Soldiers: side-scrolling RTS (PS3/Wii/PC/Mac/Linux/iPhone/iPad/Android)
Proun: abstract racing game (PC)
Cello Fortress: mixing game and live cello performance

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 3770
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 131
Contact:

Re: Decals z-fighting

Post by dark_sylinc » Sat Feb 27, 2016 3:59 pm

Sorting takes into account the AABB. I imagine your shadow planes are inside the cello's AABB, hence to Ogre the Cello is always "closer".
I suggest you move the planes to a higher-numbered RenderQueue ID, which is a way of explicitly controlling render queue order.

However, you still have depth reads on; which can cause it to Z-fight against the cello's depth values. Turning it off or increasing the depth bias could work.

Or you could increase the near plane, which dramatically increases the Z Buffer's precision.
Oogst wrote:I've also noticed that if I zoom the camera out, the shadows starts appearing on top of other objects, as if it gets an extreme depth_bias. This happens even if I remove the depth_bias.
If these objects also have depth writes off and things aren't being rendered back to front, it would explain this behavior.
0 x

Oogst
OGRE Expert User
OGRE Expert User
Posts: 1034
Joined: Mon Mar 29, 2004 8:49 pm
Location: the Netherlands
Contact:

Re: Decals z-fighting

Post by Oogst » Sat Feb 27, 2016 9:53 pm

Doesn't Ogre automatically render objects that are set to "transparent_sorting force" last? If so, why would setting the renderQueueID help?

Also, it seems like "depth_bias 1" is a very high value or something like that: if I zoom out, objects are still rendered correctly, no Z-fighting at all, but the ground shadow starts moving up through those objects. Not an instant flip as if Ogre thinks the shadow is above the object, but a gradual moving through. As if that depth_bias is very large compared to the precision of the Z-buffer. Which is odd, since the Ogre manual says: "Constant biasing is expressed as a factor of the minimum depth value, so a value of 1 will nudge the depth by one 'notch' if you will." What am I misunderstanding here?

I've now tried a combination of setting renderQueueID, removing depth_bias, increasing camera near clipping distance and putting my shadow plane slightly above the ground. Together this seems to have done the trick! However, I still don't get why putting it on the same height as the ground in combination with depth_bias didn't work.
0 x
blog.oogst3d.net: my dev blog and portfolio
Ronimo Games: my game dev company
Awesomenauts: platforming MOBA (PC/Mac/Linux/XBox360/PS3/PS4)
Swords & Soldiers: side-scrolling RTS (PS3/Wii/PC/Mac/Linux/iPhone/iPad/Android)
Proun: abstract racing game (PC)
Cello Fortress: mixing game and live cello performance

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 3770
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 131
Contact:

Re: Decals z-fighting

Post by dark_sylinc » Sat Feb 27, 2016 10:23 pm

Oogst wrote:Doesn't Ogre automatically render objects that are set to "transparent_sorting force" last? If so, why would setting the renderQueueID help?
Because Ogre's 1.x sorting in the render queue is very convoluted, I don't fully trust it's being rendered the way you want. Also there could be other minor details at stake that affect the rendering order. A RenderQueue ID makes this robust.
Oogst wrote:Not an instant flip as if Ogre thinks the shadow is above the object, but a gradual moving through. As if that depth_bias is very large compared to the precision of the Z-buffer. Which is odd, since the Ogre manual says: "Constant biasing is expressed as a factor of the minimum depth value, so a value of 1 will nudge the depth by one 'notch' if you will." What am I misunderstanding here?

I've now tried a combination of setting renderQueueID, removing depth_bias, increasing camera near clipping distance and putting my shadow plane slightly above the ground. Together this seems to have done the trick! However, I still don't get why putting it on the same height as the ground in combination with depth_bias didn't work.
Well you would have to debug thoroughly with PIX to find out. But also:
Despite what the documentation says, depth_bias has always had the problem that it wasn't fully defined by spec. "1" by NVIDIA does not necessarily mean that same as "1" from AMD. And then there's Intel. And then there's older cards from the same vendor. Effectively making this function useless to almost all applications.

This is why Microsoft recommended slope depth bias instead, which is strictly defined by spec how it should work. However slope depth bias doesn't do exactly the same. It hasn't been much of an issue because you could just move the position of the decal a bit (if it's a plane on top of another plane), or adjust the Z output in the vertex shader (if it's a complex object); both options more reliable than depth bias.
0 x

Oogst
OGRE Expert User
OGRE Expert User
Posts: 1034
Joined: Mon Mar 29, 2004 8:49 pm
Location: the Netherlands
Contact:

Re: Decals z-fighting

Post by Oogst » Sun Feb 28, 2016 12:34 am

Thanks for the clarification! And thanks for the help, as I've got it working now through your tips! 8)
dark_sylinc wrote:... depth_bias has always had the problem that it wasn't fully defined by spec. "1" by NVIDIA does not necessarily mean that same as "1" from AMD. And then there's Intel. And then there's older cards from the same vendor. Effectively making this function useless to almost all applications. ...
Sounds like a quote that should be copy/pasted straight into the manual to avoid future confusion. :)
0 x
blog.oogst3d.net: my dev blog and portfolio
Ronimo Games: my game dev company
Awesomenauts: platforming MOBA (PC/Mac/Linux/XBox360/PS3/PS4)
Swords & Soldiers: side-scrolling RTS (PS3/Wii/PC/Mac/Linux/iPhone/iPad/Android)
Proun: abstract racing game (PC)
Cello Fortress: mixing game and live cello performance

Post Reply