#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)
Change History (17)
comment:1 by , 12 years ago
comment:2 by , 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 , 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 , 12 years ago
Attachment: | screenshot0008.jpg added |
---|
Showcasing the offset shadows problem (aka "Peter Panning")
comment:4 by , 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 , 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 , 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 , 11 years ago
Attachment: | shadows.diff added |
---|
comment:7 by , 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)
follow-up: 9 comment:8 by , 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, if I'm not mistaken.
comment:9 by , 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
follow-up: 11 comment:10 by , 11 years ago
Milestone: | Backlog → Alpha 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.
comment:11 by , 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.
follow-up: 13 comment:12 by , 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.
comment:13 by , 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 , 11 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
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 , 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.
- Implement cascaded shadowmaps to improve shadow precision.
- 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).
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 :)