Opened 12 years ago

Closed 11 years ago

Last modified 11 years ago

#1224 closed defect (fixed)

Shadows are offset for units and buildings

Reported by: Wolter Hellmund Owned by:
Priority: Must Have Milestone: Alpha 12
Component: Core engine Keywords: shadow offset
Cc: Patch:

Description

I have seen that in both units and buildings the shadows appear offset about 1 m (in the world's scale) offset away from the entity's base, in the line traced between the entity and the sun.

Attachments (2)

screenshot0008.jpg (171.4 KB ) - added by wraitii 12 years ago.
Showcasing the offset shadows problem (aka "Peter Panning")
shadows.diff (4.3 KB ) - added by myconid 11 years ago.

Download all attachments as: .zip

Change History (17)

comment:1 by historic_bruno, 12 years ago

This is inevitable to some extent, though I wouldn't mind if it was improved, Philip would know more of the technical reasons behind this :)

comment:2 by wraitii, 12 years ago

It's not too bad if it's in rare cases, but for example on iberian walls, the shadows are clearly off from the wooden planks that come out of the walls. It's not a huge deal, but it does look dumb.

comment:3 by historic_bruno, 12 years ago

Referred to as "Peter Panning" in this article. Suggested solution:

Peter Panning results when the depth offset [bias] used is too large. In this case the depth offset causes the depth test to erroneously pass. Like shadow acne, Peter Panning is aggravated when there is insufficient precision in the depth buffer. Calculating tight near planes and far planes also helps avoid Peter Panning.

Because it seems to be most noticeable at low light angles, can we vary the bias/offset dynamically? (Currently it's a fixed value of 0.02, see m_ShadowZBias in Renderer.cpp, and you can use renderer.shadowZBias to set/get that value from the in-game console)

by wraitii, 12 years ago

Attachment: screenshot0008.jpg added

Showcasing the offset shadows problem (aka "Peter Panning")

comment:4 by wraitii, 12 years ago

this is particularly problematic on the random map "Oasis", where the light is simulating a sunset/sunrise (see attached screenshot). It kind of detracts from the nice scenery.

comment:5 by myconid, 11 years ago

I think there's a bug in the shadowmapping code that messes with the precision. A bias of 0.02 is huge, most implementations I've seen are at about 1/10 of that, if not less. I'll try to review the math, hopefully tomorrow or the day after, and maybe I'll spot something.

A smaller bias will certainly help, but it won't be a magic bullet. I doubt it'll be enough to avoid the shadows looking slightly offset (for distant objects), and blurry (at low angles). The article linked to by historic_bruno has the right idea: cascaded shadowmaps. Meaning, the world is split into partitions based on depth, and each partition is rendered to a separate shadowmap, so we have more precision overall. 

comment:6 by myconid, 11 years ago

Uhhhh.. Never mind about reviewing the math. It took all of five minutes to notice that the bias is pre-applied in light space and saved to a texture.. The whole point of having a bias is that the texture doesn't have the precision to store that level of detail. Derp.

by myconid, 11 years ago

Attachment: shadows.diff added

comment:7 by myconid, 11 years ago

Patch does the biasing during rendering instead. Using a generous bias of 0.004, let me know how that value looks on your PCs.

(Not meant for commit, btw. It breaks ARB mode)

Last edited 11 years ago by myconid (previous) (diff)

comment:8 by historic_bruno, 11 years ago

Not bad! It definitely helps with this problem, though it noticeably aggravates #1203 which I guess is a consequence of the smaller bias. That could be helped by fixing the shadow popping issue (#504), if I'm not mistaken. Funny how it's all related :)

Last edited 11 years ago by historic_bruno (previous) (diff)

in reply to:  8 comment:9 by myconid, 11 years ago

Replying to historic_bruno:

Not bad! It definitely helps with this problem, though it noticeably aggravates #1203 which I guess is a consequence of the smaller bias.

Does it happen always, or only when the sun is at a very low angle, like less than 10-15 degrees? We should fade everything to shadow past that point, as we don't want shadows stretching all the way across the map.

In addition to the previous patch, see if this small change makes any difference for you

diff --git a/source/renderer/Renderer.cpp b/source/renderer/Renderer.cpp
index 5f211ac..5700ae9 100644
--- a/source/renderer/Renderer.cpp
+++ b/source/renderer/Renderer.cpp
@@ -847,7 +847,10 @@ void CRenderer::RenderShadowMap(const CShaderDefines& context)
 
 	{
 		PROFILE("render patches");
+		glCullFace(GL_FRONT);
+		glEnable(GL_CULL_FACE);
 		m->terrainRenderer.RenderPatches();
+		glCullFace(GL_BACK);
 	}
 
 	CShaderDefines contextCast = context;

If yes, try changing the "shadowBias" in terrain_common.fs to something smaller until you find the lowest acceptable value for your GPU. I can get away with 0.0005! :D

comment:10 by historic_bruno, 11 years ago

Milestone: BacklogAlpha 12

r12884 looks good. I wonder, can we still use the ShadowBias config value or does it need to remain in the shader? Personally I think it would be great to have the option so it can be modified in-game or with the config file.

in reply to:  10 comment:11 by myconid, 11 years ago

Replying to historic_bruno:

r12884 looks good. I wonder, can we still use the ShadowBias config value or does it need to remain in the shader? Personally I think it would be great to have the option so it can be modified in-game or with the config file.

I use different biases for the models and terrain, so one config value isn't enough. Could add two of them, or get rid of it completely. It's not a value that players or map devs will need to mess with, I think.

comment:12 by historic_bruno, 11 years ago

Is it something that can vary between different systems, maybe based on GPU capabilities? If so, I'd say keep it around, otherwise we can find the optimal value and remove it.

in reply to:  12 comment:13 by myconid, 11 years ago

Replying to historic_bruno:

Is it something that can vary between different systems, maybe based on GPU capabilities? If so, I'd say keep it around, otherwise we can find the optimal value and remove it.

If it varies, it's because some vendors deviated from the standard, not because the GPUs lack capabilities. The only way to know if that's the case is to have it tested on different hardware and check if we get any unexpected results. A small sample usually suffices.

As soon as we get an autobuild, anyone who uses the SVN will pipe up and tell us if something got broken, I think...

comment:14 by Kieran P, 11 years ago

Resolution: fixed
Status: newclosed

According to Michael, the shadows are fixed, so closing this as resolved. Nice work Costas. You've proved yourself a very valued team member :-)

comment:15 by myconid, 11 years ago

Glad I could help!

Note that my comment above (5) is still valid. The shadows on the terrain should look near perfect with these patches, but the shadows on models will still be slightly offset (even though significantly less than before).

I can think of two ways to improve this - a combination of both would be best.

  1. Implement cascaded shadowmaps to improve shadow precision.
  2. Ensure that all our models don't have holes (unfortunately, some models such as the roman CC omit polygons on their under side because they aren't visible from above).
Note: See TracTickets for help on using tickets.