[2.2] Self Shadowing errors

Lax · Post by **Lax** » Sun Jun 21, 2020 1:37 pm

Hi dark_sylinc,

I tested some Ogre demos, and there is something wrong. Echout eg. the SSAO, SMAA demos.

Best Regards
Lax

SolarPortal · Post by **SolarPortal** » Sun Jun 21, 2020 2:05 pm

Both demos post fx work fine for me, on the smaa i get the same incorrect shadows on the rotating cubes that i described on one of my earlier posts.
Tested on both the opengl and DX11 render system, both demos look like they always have for me apart from the smaa demo shadows look wrong in dx11 but fine in gl..

SSAO demo doesnt use shadows i thought?

Lax · Post by **Lax** » Sun Jun 21, 2020 2:26 pm

I have the same issues as in the Ogre demos. Something wrong with render queue??

http://www.lukas-kalinowski.com/Homepag ... rQueue.mp4

Best Regards
Lax

SolarPortal · Post by **SolarPortal** » Sun Jun 21, 2020 2:30 pm

That looks like a render target has been made without a depth buffer or if you have turned sorting off on the render queue? I dont get anything like that on mine. This didnt happen for you on the last version of the shadows? but appears after the new patch. Have you recently tweaked any compositors?
Edit: Perhaps try a full clean / rebuild of your app or redownload the latest version and try that. I cant say i have much information to help you.

Lax · Post by **Lax** » Sun Jun 21, 2020 2:38 pm

Hi,

This didnt happen for you on the last version of the shadows? but appears after the new patch.

I did't change anything on the code nor on the compositors. I only updated to newest Ogre version.
I also checked the compositors via winmerge and everything looks the same.

I also replaced hlms code with Ogre's code. Is it maybe because I'm still on the 'shadow_bias_improve' branch?

Best Regards
Lax

SolarPortal · Post by **SolarPortal** » Sun Jun 21, 2020 2:40 pm

I too am running on the Shadow_bias_improve branch. perhaps matias has some answers

Post by **dark_sylinc** » Sun Jun 21, 2020 5:19 pm

Lax wrote: ↑Sun Jun 21, 2020 1:37 pm I tested some Ogre demos, and there is something wrong. Echout eg. the SSAO, SMAA demos.

I tested the SSAO in GL and it was working (will try D3D11 later). HOWEVER, I left MSAA enabled, and I totally forgot SSAO demo does not work with MSAA (we should fix that) and does not warn about it either, so it looks very weird when MSAA is enabled (the whole screen is darkened). Perhaps this is what you experienced?

Btw there are no shadows in the SSAO sample (because that's how the sample was setup)

Lax · Post by **Lax** » Sun Jun 21, 2020 8:42 pm

Hi dark_sylinc,

see the attached video, what is going wrong:

http://www.lukas-kalinowski.com/Homepag ... rQueue.mp4

I have also the same effect on the Ogre demos.

Best Regards
Lax

Post by **dark_sylinc** » Sun Jun 21, 2020 11:04 pm

Lax wrote: ↑Sun Jun 21, 2020 8:42 pm Hi dark_sylinc,

see the attached video, what is going wrong:

http://www.lukas-kalinowski.com/Homepag ... rQueue.mp4

I have also the same effect on the Ogre demos.

Best Regards
Lax

I don't know why the demos are affected for you, but I have a very good guess on your app:

One of the DLLs is out of date (e.g. OgreMain or RenderSystem)
The headers are out of date
You need a full rebuild of either Ogre and/or your app

The reason I suspect that is because we added a new boolean, mDepthClamp, to HlmsMacroblock right before mDepthCheck.

Thus if one of the builds got out of sync, it would read mDepthCheck = false (thus disabling depth buffer) because it's reading from where now mDepthClamp is. Or inversely, it now reads garbage from mDepthWrite because it's reading from mDepthFunc.
Additionally, sizeof(HlmsMacroblock) changed.

One of your builds getting out of sync would explain what you're seeing.

Lax · Post by **Lax** » Mon Jun 22, 2020 8:47 pm

Hi dark_sylinc,

thanks for the information. Indeed, something went wrong by surprise when building RenderSystem_Direct3D11 project. Its strange, as it worked a few days ago. The error is, that the file OgreD3D11RenderWindow.h cannot be found. I took a look and found the file in a deprecated folder.
Do you have any idea how to fix that?

[Edit]: Damn it, in cmake config I had quad_buffer_stereo enabled and because of that some deprecated stuff was used. Sorry for spamming you guys.

Best Regards
Lax

Post by **dark_sylinc** » Tue Jun 23, 2020 12:32 am

Column-major vs row-major strikes again!

Fixed. That was the reason D3D11 showed some shadow acne while OpenGL did not.
The geometric normal D3D11 was using was pure garbage.

Both APIs now visually match.

SolarPortal · Post by **SolarPortal** » Tue Jun 23, 2020 4:47 pm

@dark_sylinc, that last shadow patch makes both renderers the same for me now

Lax · Post by **Lax** » Tue Jun 23, 2020 9:09 pm

@dark_sylinc, that last shadow patch makes both renderers the same for me now

Yes, I can confirm, that shadows do look very good now!

Post by **dark_sylinc** » Tue Jun 23, 2020 11:43 pm

Great!

Sounds like this is going to get merged into master soon

xrgo · Post by **xrgo** » Wed Jul 01, 2020 7:27 pm

Edit: lol, just read the commit: https://github.com/OGRECave/ogre-next/c ... 4d5ef15edd
and I got most of the answers, so I am going to test those stuffs, sorry

Hello!
I am just trying this and I do get less acne and peter panning, mostly noticeable on thin stuffs, so that's great!

buuuuuut... I have a problem concerning setShadowMappingUseBackFaces that was removed:
1) I have some scenes with single faced walls/ceilings that now no longer cast shadows
2) Now I get acne on floors on far splits with very low resolution (I also use stable for every split, so they are very low res), I can increase bias and remove the acne but I get lots of peter panning on other objects

I know that I can just duplicate the faces to make them have thickness so they cast shadows, and I can make my floor just not to cast shadows.... I just prefer when thinks works automagically. So... bringing back setShadowMappingUseBackFaces is compatible with this new features?

Also in one particular (very simple) scene shadows disappear when the light is pointing perfectly down (0,-1,0) (aka 12pm in an ideal planet), as soon as I move the sun a little the shadow appear, and I cannot find a bias value to fix this

I haven't seen this last problem in a proper application yet so its not serious, still strange

Thank youuu!!!!

Post by **dark_sylinc** » Wed Jul 01, 2020 7:42 pm

xrgo wrote: ↑Wed Jul 01, 2020 7:27 pm So... bringing back setShadowMappingUseBackFaces is compatible with this new features?

It's not. Normal offset mapping way distorts too much with setShadowMappingUseBackFaces( true ), thus if that were to be enabled, everything would have to work the way it was before in order to look correct, which is too much work both for us and you (from our end we need 2 codepaths, and from your end settings need to be in sync i.e. different bias parameters, setting up caster blocks, etc)

2) Now I get acne on floors on far splits with very low resolution (I also use stable for every split, so they are very low res), I can increase bias and remove the acne but I get lots of peter panning on other objects

Stable splits for very far splits lose too much quality

If it's the floor which is causing noticeable self shadowing, then I'd recommend to disable shadow casting on that particular troublesome object, or increase either of the 2 biases.

I know that I can just duplicate the faces to make them have thickness so they cast shadows

Hold on!
You can also:

Call setTwoSidedLighting( true, true, CULL_NONE );
Not use the above, but still flip the culling mode (or set it to CULL_NONE) via setMacroblock( flippedMacroblock, casterBlock=true );

Also in one particular (very simple) scene shadows disappear when the light is pointing perfectly down (0,-1,0) (aka 12pm in an ideal planet), as soon as I move the sun a little the shadow appear, and I cannot find a bias value to fix this

That looks like a bug, and I'm interested in looking into it.
I think I can pull the latest changes from your repo and try it out myself? (if you somehow manage to repro that on the samples it would be even awesome).

I can't look at this immediately though, but thanks for the feedback.

Update: I was able to repro your "disappearing box shadow" problem in ShadowMapDebugging by setting the sun to exactly 0 -1 0 and all splits set to stable

Post by **dark_sylinc** » Mon Jul 06, 2020 12:05 am

Also in one particular (very simple) scene shadows disappear when the light is pointing perfectly down (0,-1,0) (aka 12pm in an ideal planet), as soon as I move the sun a little the shadow appear, and I cannot find a bias value to fix this

Fixed. It was a precision error. Some padding fixed it.

xrgo · Post by **xrgo** » Mon Jul 06, 2020 8:46 am

thank you! the problems are solved, and I found values for bias that fit my needs. Shadows are great now!

Lax · Post by **Lax** » Sat Jul 11, 2020 11:49 am

Hi folks,

I now had the time, to debug and adapt my shadows etc. But as I analysed everything something weird came to my mind, which I think does not work for a long time. When I move the camera a bit away from an game object with shadows, the shadows will blur out immediately. In all Ogre Samples, this is not the case.

See the attached video:

http://www.lukas-kalinowski.com/Homepag ... stance.mp4

Does anybody have an idea what is going on?

I tested the following:
- I used the workspace from Sample_PbsMaterials for exclusion.
- My camera has a near clip distance of 0.1 and far clip distance of 500
- The setShadowDirectionalLightExtrusionDistance and light extrude distance is 500
- I' using the default shadows values:
- constantBiasScale = 1.0f
- normalOffsetBias = 168.0f
- autoConstantBiasScale = 100.0f
- autoNormalOffsetBiasScale = 4.0f
- pssmLambda = 0.95f
- splitPadding = 1.0f
- splitBlend = 0.125f
- splitFade = 0.313f

This is the json script for the brick:

Code: Select all

{
	"samplers" :
	{
		"Sampler_Platformer" :
		{
			"min" : "anisotropic",
			"mag" : "anisotropic",
			"mip" : "anisotropic",
			"u" : "wrap",
			"v" : "wrap",
			"w" : "wrap",
			"miplodbias" : 0,
			"max_anisotropic" : 1,
			"compare_function" : "disabled",
			"border" :[1, 1, 1, 1],
			"min_lod" : -3.40282e+38,
			"max_lod" : 3.40282e+38
		}
	},

	"macroblocks" :
	{
		"Macroblock_Platformer" :
		{
			"scissor_test" : false,
			"depth_check" : true,
			"depth_write" : true,
			"depth_function" : "less_equal",
			"depth_bias_constant" : 0,
			"depth_bias_slope_scale" : 0,
			"cull_mode" : "clockwise",
			"polygon_mode" : "solid"
		}
	},

	"blendblocks" :
	{
		"Blendblock_Platformer" :
		{
			"alpha_to_coverage" : false,
			"blendmask" : "rgba",
			"separate_blend" : false,
			"src_blend_factor" : "one",
			"dst_blend_factor" : "one_minus_src_alpha",
			"blend_operation" : "add"
		}
	},
        "M_Brick" :
		{
			"macroblock" : "Macroblock_Platformer",
			"blendblock" : "Blendblock_Platformer",
			"shadow_const_bias" : 0.001,
			"workflow" : "SpecularWorkflow",
			"brdf" : "blinn_phong",
			"diffuse" :
			{
				"value" : [1, 1, 1],
				"background" : [1, 1, 1, 1],
				"texture" : "M_BrickD.png",
				"sampler" : "Sampler_Platformer"
			},
			"specular" :
			{
				"value" : [1, 1, 1]
			},
			"fresnel" :
			{
				"value" : 0.1,
				"mode" : "coeff"
			},
			"normal" :
			{
				"value" : 1,
				"texture" : "M_BrickN.png",
				"sampler" : "Sampler_Platformer"
			},
			"roughness" :
			{
				"value" : 1.7
			}
		}
	}
}

Edit: If I change the camera near clip distance to e.g. 0.0001 its even more weird:

http://www.lukas-kalinowski.com/Homepag ... tance2.mp4

I hope someone can help.

Best Regards
Lax

Lax · Post by **Lax** » Tue Jul 14, 2020 4:21 pm

I think I found out one aspect, why shadows are disapearing. It has something todo with the size of the item! When I scale my box by x10. The shadows will remain even when the camera will be moved far away. See:

http://www.lukas-kalinowski.com/Homepag ... caling.mp4

When I change the extrusion distances, the following happens:
http://www.lukas-kalinowski.com/Homepag ... caling.mp4
The pssm shadow textures are switched to early? I use default Pbs workspace with default pssm values (to avoid interferences).

@dark_sylinc: can something be done about it?

I'm using the newest Ogre version from git master.

[Edit]: The Pbs Samples the items are also small

. So why are the samples working correctly...

Best Regards
Lax

Lax · Post by **Lax** » Sun Jul 26, 2020 10:23 am

Ouch, I found the evil of my shadows

I use a MainGameObject, which is just an Node carrying meta data information. The MainGameObject is placed by default at the coordinates: -1000 -1000 -1000. This causes all my shadows issues. I think proportions of the scene do explode, as all other game objects are laying nearby but the MainGameObject is far away...

Also when I increase the plane size from 50x50 to 500x500 I get similiar shadow issues.

Ogre Forums

[2.2] Self Shadowing errors

Re: [2.2] Self Shadowing errors

Re: [2.2] Self Shadowing errors

Re: [2.2] Self Shadowing errors

Re: [2.2] Self Shadowing errors

Re: [2.2] Self Shadowing errors

Re: [2.2] Self Shadowing errors

Re: [2.2] Self Shadowing errors

Re: [2.2] Self Shadowing errors

Re: [2.2] Self Shadowing errors

Re: [2.2] Self Shadowing errors

Re: [2.2] Self Shadowing errors

Re: [2.2] Self Shadowing errors

Re: [2.2] Self Shadowing errors

Re: [2.2] Self Shadowing errors

Re: [2.2] Self Shadowing errors

Re: [2.2] Self Shadowing errors

Re: [2.2] Self Shadowing errors

Re: [2.2] Self Shadowing errors

Re: [2.2] Self Shadowing errors

Re: [2.2] Self Shadowing errors

Re: [2.2] Self Shadowing errors