I read the thread back and actually realized you never claimed this to be Variance shadow mapping, you just happen to have a variable called variance, right?
The edges looks very hard with your approach, what’s giving those artifacts on the BSR is dithering. If you just pick the shadow value with no filtering you’ll have hard edges, and no artifact on rounded objects, but very bad aliasing.
Bumping up the shadow map size of course reduce aliasing, but it’s not a viable solution for wide areas.
Also…as wrong as it is in real life, one always prefer soft shadows to hard shadows.
One question : how does it perform compared to actual shadow mapping? (the BSR).
Also the PSSMShadowRender performs better with a single map than the BSR. It supports PCF, dither, nearest and bilinear filtering for edges.
It also crops the light matrix to fit the casting/receiving objects to not waste parts of the shadow maps in non shadowed areas.
Maybe you should give it a try.
I’ll have to test your filtering to wrap my head around what it exactly does.
@nehon said:
I read the thread back and actually realized you never claimed this to be Variance shadow mapping, you just happen to have a variable called variance, right?
The edges looks very hard with your approach, what's giving those artifacts on the BSR is dithering. If you just pick the shadow value with no filtering you'll have hard edges, and no artifact on rounded objects, but very bad aliasing.
Bumping up the shadow map size of course reduce aliasing, but it's not a viable solution for wide areas.
Also...as wrong as it is in real life, one always prefer soft shadows to hard shadows.
One question : how does it perform compared to actual shadow mapping? (the BSR).
Also the PSSMShadowRender performs better with a single map than the BSR. It supports PCF, dither, nearest and bilinear filtering for edges.
It also crops the light matrix to fit the casting/receiving objects to not waste parts of the shadow maps in non shadowed areas.
Maybe you should give it a try.
I'll have to test your filtering to wrap my head around what it exactly does.
Yes... though it IS the method for doing VSM.
And no... it is not what does it in the BSR... it is the hardocded texture size.
And performance... slightly faster... just due to 3 less texture lookups. Though, hoenestly... it is not a noticible change in context... on my crappy machine anyways.
@Momoko_Fan
Please read what I said about the hardcoded texture size in Shadow.glsl... I modified a version to pass in the texture size and ALL of the artifacting went away... it actually looks really nice! No more patterning on faces not in the shadow. If you take nothing else from this, please, please ,please update the current BSR to take care of this issue. It (in it's current state) is useless past 1024 and the dithering looks like crap at anything but 1024.
And a side note... the shadows would look a heck of a lot better lighter ;) Perhaps a shadow strength uniform?
hmmm, it seems t0neg0d is right.
i see that issue.
mhh You’re right about the hardcoded 1024 texture size. Actually it’s only done properly in the PssMPostShadow15.frag that is using the textureSize method.
Ok so you are using VSM resolving directly on a depth buffer? I thought the point of VSM was to render to a color map to make the hardware generate mip maps for you to have “free” edge blurring.
@nehon
Holy crap… the PSSM uses Shadow.glsl as well doesn’t it? Um… you’re gonna see a drastic improvement in the PSSM as well if this is fixed. Your relying on pixSize2 for dither/blurring/whatever you’re doing to soften shadows… and it is wrong 
@nehon said:
mhh You're right about the hardcoded 1024 texture size. Actually it's only done properly in the PssMPostShadow15.frag that is using the textureSize method.
Ok so you are using VSM resolving directly on a depth buffer? I thought the point of VSM was to render to a color map to make the hardware generate mip maps for you to have "free" edge blurring.
It is... this was an experiment that produced cool results. It just happened to fix a problem in the BSR that I hadn't really noticed at first. Um.. clarifying... hadn't noticed why it was happening. once I did away with Shadow.glsl... the problem was resolved by not relying on the texture size. However... this would have shown up again if I had taken the same approach ... if u follow
@t0neg0d said:
@nehon
Holy crap... the PSSM uses Shadow.glsl as well doesn't it?
Nope
All the function are embed in the shader (i don't remember why tbh)
But the postShadow for ogl 1.0 has the same issue you mention.
Not the 1.5 shader though, so recent hardware owners should never have the issue.
@nehon said:
Nope
All the function are embed in the shader (i don't remember why tbh)
But the postShadow for ogl 1.0 has the same issue you mention.
Not the 1.5 shader though, so recent hardware owners should never have the issue.
Ah... cool. It would still be an issue in the BSR though.
@nehon said:
Also the PSSMShadowRender performs better with a single map than the BSR. It supports PCF, dither, nearest and bilinear filtering for edges.
It also crops the light matrix to fit the casting/receiving objects to not waste parts of the shadow maps in non shadowed areas.
Yeah, for all of the above reasons we are considering deprecating the BSR anyway.
But still it should be fixed in 1.0 pssm, so nice catch.
TBH i'm not really satisfied with the actual shadowing system. It's slow, and give good results only with high filtering...making it slower :p
VSM could be a lead to follow.
Also to optimize current shadowing system we should focus on the bottleneck : the number of rendering passes.
Right now you have one pass for the shadow map and one pass for the post shadow. Add this to the main render pass, and that's almost 3 rendering passes of the whole visible scene on fully lighted environment.
It's worse with PSSM because the splits have to overlap a bit to avoid banding artifacts, and in some case some objects are rendered in several shadow maps because of this overlap.
There is also a lot of overdraw when the frustum is aligned with light direction
If you are looking into shadow speed improvement that's where you should dig.
Interestingly enough:
[java]if (depth - 0.0018 <= lookupDepth && depth + 0.0018 >= lookupDepth)[/java]
is the self-shadow portion only.
[java]if (depth - 0.0018 > lookupDepth)[/java]
are shadows that are cast
Yes… I know this is obvious to some… maybe not so much to others.
mhhh where does this code comes from?
@t0neg0d said:
[java]if (depth - 0.0018 <= lookupDepth && depth + 0.0018 >= lookupDepth)[/java]
[java]if (depth - 0.0018 > lookupDepth)[/java]
this code.
is it somewhere in the shadowing code?
I don't get where the "0.0018" number is coming from
@nehon said:Yeah, for all of the above reasons we are considering deprecating the BSR anyway.
so which should we use, to obtain faster render? PSSM is slow :(
PSSM with one split and dither is as fast as BSR.
But gives better results because of the matrix cropping
1 Like
@nehon:
hmm, if you say so… then it’s true.
but i don’t use it because of issue i have.
screenshot would not show enough, so i made video of issue i have.
http://www.youtube.com/watch?v=l-XnGQZ6FOw
maybe it's problem of "WGL_ARB_multisample" that it seems i don't support :?
i have not so many time to look at that.
I get that issue too (or very similar) when I turn on shadows. It looks terrible.
@nehon said:
this code.
is it somewhere in the shadowing code?
I don't get where the "0.0018" number is coming from
It's from me... 0.0018 should be a bias for offsetting the depth to remove noise. This should be adjustable because that bias will need to change depending on the scale of the models. At smaller scale the bias should be larger or shadows will start getting degraded. At larger scale... you would see noise you may not want.
It was one of the reasons I was saying to remove PolyOffset 5 0 from the material def file and give a bias control.
@oxplay2 mhh that’s strange i don’t have this issue.
So you don’t have this issue with the BSR?
@t0neg0d mhh ok, that’s an idea, some kind of low pass filtering. I’ll look into it.
@nehon said:
@oxplay2 mhh that's strange i don't have this issue.
So you don't have this issue with the BSR?
exactly, BSR don't have this issue.
i wrote a topic about that issue 1 year ago, where you assumed that was hardware issue.
http://hub.jmonkeyengine.org/groups/graphics/forum/topic/shadow-problem-1
some quotes of user posts:
moved the camera near to the shadow, it seems to render fine, but sometimes
when I rotate the camera just a litte bit, shadow disappears.
Oh yes, I did see this too once or twice but lost track of the location/angle it was vanishing, and couldn’t reproduce.
even @zarch says, that he have this issue.
it would be nice, if you could test it on older hardware. Because i belive it's hard to guess what is wrong. :roll: