   Shadowmap Peter Pan Calculation?
  I've abandoned my gradient shadows (largely from the ShaderX5 book) on account of ime it doesn't really solve anything - I get no acne but I have other issues that, at least in the sphere of stuff I do, are just as bad and therefore those many gpu cycles are wasted.So anyway, one thing I do miss is that the GSM method gets the biases nearly right no matter what, whereas an old-fashioned peter pan bias seriously depends on camera far and even spotlight fov changing the res.Is there some sort of magic math or simpler shader routine that gets the bias roughly right no matter what? I could then move this by say 10% either way on a slider and know that the default is at least going to be in the parish.I know there's a necro thread about that addressed this issue, but I also remember trying out all the numbers suggested and none of them worked generically - I guess they work just in the ranges the contributors are used to using or something.   
  I agree with you on this, I've never found that magic setup between peter panning and acne removal (after LOTS of tinkering). What I have found that helps is a higher resolution shadow map and as tightly-bounding a light frustum as possible to avoid the imprecision of the shadowmap buffer.Interestingly, if you look carefully at some shadowed areas on call of duty 6, you can see evidence of peter panning and in some occasional places, some shadow acne - so if those guys can't get it right, what hope is there for us??   ;  lol, that's true enough.I think it's technically impossible to make it perfect due to the inherent problems representing small areas with single pixels.However, something that "just works" will do me just nicely even if it has some flaws. I just don't want to keep dicking around with sliders to reduce 1/10 of a texel of peter pan - just gimme a fift of a texel and I'll smile. I just want it to be a fifth all the time so I can draw a line under this and move on.Frankly I think that the Peter Pan effect is far too overly criticised. With a 2048 texture and a full scene of moving, textured action that's not a black on white sample app, you hardly notice it. Which is why I'd prefer to have something that automatically does it.Probably the least accurate but guaranteed amount of bias is 1/width, but even that didn't work well unless I mucked something up.;  There was some old paper which described a method of rendering front and back faces of the objects and calculating the average distance of the two.This should help in most cases, but has obvious problem of increasing z-rendering load.For a static or rarely updated shadow maps this shouldn't be a problem tough.Happily the actual sampling or compositing with other shadow maps shouldn't be any different. :)   ;  It's certainly an option, just not one I want to take atm - I'm trying to simplify not complicate.I'll start with advancements on "1/Width" for the bias tbh.   ;  What do you mean, exactly, by 1/width?  Width of what, the shadow map texture?   ;  Yes. :)   ;  What format do you use for your shadowmap textures?  And are the depths stored linear or non-linear?   ;  I use R32F and none of those GPU hacks for now. Depth can be either easily, but I think it's linear atm. Its just a /.w in the light caster I think.   ;  Since reading your initial post, I've gone back to have a look at my shadow processing as I've never really been overly happy with it.  I had made some improvements by encoding an object id into the depth buffer and adding a larger bias when drawing a pixel from an object with the same id as that of the depth buffer and a smaller bias when the ids are different.  This works great for acne and peter-panning, but doesn't really work so well if you have an object that shadows itself, e.g. a wooden chair, as the peter-panning becomes pretty noticeable.I played around with some more bias values last night (without encoding IDs) and I think the results are just not good enough.  I was wondering, could someone explain whether (and possibly why) it would be beneficial to use a linear shadowmap over a non-linear shadowmap?  My assumption is that using a float value will give the best precision between 0 and 1 but each whole number you use after that will lose a factor of precision so having a larger (or deeper) light-space frustum would give poor results.  The way I've made my shadowmap linear is by multiplying the actual float depth value by some factor of, eg, 10000, chopping off the frac part and then dividing by 10000 when doing the comparison (this particular factor giving 4 digits of precision).  Doing that though doesn't really make much visual difference.  I'm only testing with a couple of cubes close to the ground so the light-space frustum is very small anyway.   