Perspective shadow maps -- the good and the bad?
- Thread starter Reverend
- Start date
MfA said:
Yes but without the fillrate issues and you can trivially determine the edges on the GPU. Although you could still generate the silouhettes before rendering if so inclined.
Obviously there would still be sampling errors, especially at the corners of sharp objects, but it should clean up most of the worst issues. It's worth spending a few days to play with.
Like this? 8)Fafalada said:Well it's easy isn't it? You just need pixel pipelines that can optionally output Zvalues to arbitrary addresses instead of on a regular grid
The Irregular Z-Buffer and its Application to Shadow Mapping
If they patented that Im gonna cry (although I must admit I hadnt though of using a hash, I was thinking more quad and kd-trees ... not that I was thinking of starting the quad-tree at level 1, so it isnt much of a difference).
BTW Simon, I still maintain you guys would have it easiest implementing something like this You are already basically raycasting to get intersections anyway, you "just" need programmable coordinates for each sample in a tile and a slightly more intelligent binner (you will have some redundancy, wasted samples in a tile, but the advantages of the regular structure likely overrule that). You _really_ dont want the standard way of shadowing becoming this method implemented in shaders.
BTW Simon, I still maintain you guys would have it easiest implementing something like this
You are already basically raycasting to get intersections anyway, you "just" need programmable coordinates for each sample in a tile and a slightly more intelligent binner (you will have some redundancy, wasted samples in a tile, but the advantages of the regular structure likely overrule that). You _really_ dont want the standard way of shadowing becoming this method implemented in shaders.That irregular z-buffer looks great, but there could be a problem for performance characteristics. It doesn't seem to me like the issue of determining which sample points are within the triangle to be rendered is a trivial one, and could be the downfall of the technique.
As for the actual rendering, it may be possible to implement a particle system to emulate this technique, but that would probably require doing a lot of processing on the CPU.
As for the actual rendering, it may be possible to implement a particle system to emulate this technique, but that would probably require doing a lot of processing on the CPU.
Here's the reason why I started this thread ([edit]sorry, haven't read all the replies in this thread... just wanted to post a quick one).
For PSM, we will encounter a problem where reasonably large depth map resolution is still insufficient in a big outdoor scene.... at a certain distance/degree, we get bad texel projection with a visual effect akin to "shadow flickering" with camera movement.
So I asked John what can be done beyond, say, using more depth maps and he said :
For PSM, we will encounter a problem where reasonably large depth map resolution is still insufficient in a big outdoor scene.... at a certain distance/degree, we get bad texel projection with a visual effect akin to "shadow flickering" with camera movement.
So I asked John what can be done beyond, say, using more depth maps and he said :
John Carmack said:
That sounds rather strange, the perspective projection in PSM type methods is there exactly to distribute samples like that for the ground plane (note the logarithmic progression in the distances). Carmack's method doesnt seem to tackle the problem of the sample distribution not being optimal for other planes any better than PSM (you can use multiple buffers for that, but not in the way he describes) so I dont quite see the point in abondoning it.
Chalnoth said:
Assuming DX-Next implements tesselation as an extra programmable shader it should be straightforward with the next gen. It can just traverse the linked list of samples (personally I would try some tight bounding area hierarchy instead of the simple linked list though, maybe circles or AABB). The only problem is occlusion culling ... Id rather see this exposed at a higher level in the API so the hardware can better deal with that.
Scali, I still dont see it. AFAICS a PSM type approach can be optimal for the ground plane no matter the distance, whatever he does he cant do better than optimal ... only worse.
On second thought I would probably go with a plain KD-tree to find which fragments are covered (below the initial low resolution grid). The downside compared to the straight traversal of the linked list is that in essence you are implementing a rasterizer in the shader, but if you only subdivide till you have X samples in a bin you should be able to get a net gain I think.
Construction of the datastructure is more expensive than the linked list option too, but construction is an insignificant operation compared to the actual rendering IMO.
Construction of the datastructure is more expensive than the linked list option too, but construction is an insignificant operation compared to the actual rendering IMO.
Yeah, that's pretty much what I was thinking of.nAo said:
Well, people that have already implemented cascading shadowmaps seem to disagree with that comparison to PSMs (as in it not being any better).Mfa said:
http://number-none.com/happycake/notes_8/index.html
Granted - it does give you 'equivalent' distribution, but without all the problems PSMs have.
I am a bit skeptical myself (haven't tried this approach yet), it seems to put a lot of faith in fancy filtering resolving the resolution artifacts remaining.
I'm confused as to why that guy is having so many issues with instruction limits and shadow map sampling? Should only be about 5 instructions per sample shouldn't it?
MAD - To get your modified coordinates (multiply so you can do fancier things based on a blur occluder distance image or whatever)
TEX - Get your sample
ADD - Need to add in that bias (though this could have been preadded to the floating point texture so thats one potential instruction to remove)
SGE - Is the current depth greater than or equal to the shadow map's distance?
ADD - Add this sample to the running total of samples that passed
Or am I missing something that he is considering "true" percentage-closer filtering?
If you want to randomized filtering by just rotating your poisson sample points it would then be another 2 instructions per sample for your dot products to get the rotation.
MAD - To get your modified coordinates (multiply so you can do fancier things based on a blur occluder distance image or whatever)
TEX - Get your sample
ADD - Need to add in that bias (though this could have been preadded to the floating point texture so thats one potential instruction to remove)
SGE - Is the current depth greater than or equal to the shadow map's distance?
ADD - Add this sample to the running total of samples that passed
Or am I missing something that he is considering "true" percentage-closer filtering?
If you want to randomized filtering by just rotating your poisson sample points it would then be another 2 instructions per sample for your dot products to get the rotation.
Reverend said:
This is basically old news (gd-algorithms list contains lots of discussion about that - J.Carmack isn't writing there though...). I think the current agreement is that for "general purpose" shadowmapping, you can't cover all cases with "I have this big shadow map here!". You need to split the receivers into some clusters, choose appropriate shadow map resolutions for them, etc. PSM/TSM and whatever else projection tricks are just a spice on top of that - they improve the texel resolution (in some cases), but in general you need multiple shadowmaps anyway.
This outdoor "shadow mipmapping" (kind of) thing is one way to choose the receivers/shadowmaps, and I think the most intuitive one.
Jonathan Blow
Newcomer
Cryect said:
All the shading for the surface occurs within one pixel shader, on development hardware that has a 64-instruction pixel shader limit. Most of the instructions are already used up by the rest of the shader, which does a lot of stuff.
Also, you are missing something about "true" PCF. Actually a lot of people don't quite get PCF, and ATI even has a demo on their web site that claims to be doing PCF but isn't actually. What you posted above gives you highly quantized results -- if you have 4 samples per pixel, then your possible values are 0/4, 1/4, 2/4, 3/4, 4/4. That is ass. (And it's what the ATI demo does). In order to get better results you want to at least bilerp between the samples in order to get the right answer. That's at least 3 lerp instructions (for 4 samples), plus however many instructions you need in order to compute the lerp factors, which I haven't sat down and thought hard about, but hey, it's more instructions.
Plus, I am doing this in HLSL so God knows what the HLSL compiler is doing.
That said (my post above), the question "PSM's good or bad?" just scratches the surface. PSM is just fiddling with projection that can increase the texel resolution in some cases.
No way PSM should be viewed as a complete shadowmapping solution. Sure, there are situations where just PSM is enough. There are situations where simple oldkool shadowmapping (no PSM/whatever) is enough. But still...
3DMark's use of "PSM shadowmapping" could mean anything - either their light/scene/camera configurations are such that a single PSM shadowmap is enough in all cases (which may be true - 3DMark isn't a game); or that could mean that they use PSM to improve the resolution (in some cases) and some partitioning of receivers into multiple shadowmaps. In the latter case, "we use PSM" is basically a buzzword to draw attention, because noone would react to "we use multiple shadowmaps!"
No way PSM should be viewed as a complete shadowmapping solution. Sure, there are situations where just PSM is enough. There are situations where simple oldkool shadowmapping (no PSM/whatever) is enough. But still...
3DMark's use of "PSM shadowmapping" could mean anything - either their light/scene/camera configurations are such that a single PSM shadowmap is enough in all cases (which may be true - 3DMark isn't a game); or that could mean that they use PSM to improve the resolution (in some cases) and some partitioning of receivers into multiple shadowmaps. In the latter case, "we use PSM" is basically a buzzword to draw attention, because noone would react to "we use multiple shadowmaps!"
Jonathan Blow
Newcomer
Fafalada said:
Something to keep in mind is that I am so far not doing the same thing John C is doing. John C's version of the idea is definitely better for generalized rendering, and probably even better for specialized cases like my game. I have a milestone deadline on Tuesday, but later that week I am going to play around with John C's version and see how it goes.
The main difference is that in mine, I am switching between shadow maps by testing uv coordinates in the shader and using those to mask one shadow map versus another. When I draw an object, all shadow maps that touch the object need to be selected into the shader at once. For complex filtering operations, I would need to perform them on all the selected shadow maps and throw most away, or else eat dynamic branches. But the biggest problem is that there's going to be a limited number of shadow maps (currently two, I was thinking of expanding it to 3 but that's a bad road to go down), and the object has to fit inside the biggest one. In my scenes shown on that web page, the nearest shadow map is actually a lot more low-res than it could be, because of just this issue.
John C's stencil idea removes this problem. There only has to be one shadow map selected at a time, and for things that cross boundaries, you just render them multiple times and stencil the invalid stuff away. This generalizes to nearby point light sources etc etc (I was worried only about sunlight).
With this scheme I could make the shadow pixels in those screenshots 1/4 the size in each dimension, using the same texture resources I am now (so 16 pixels to 1). That is a pretty good increase, though the fill rate would be a bit higher (due to the stencil, and the fact that I'd be filling 4x the amount of shadow texture space). But it runs great on my laptop already, and my target system is a high-end desktop, so I think it will work fine.
At that point, the aliasing issues will be greatly diminished. Yes, some filtering will be employed too, but I don't think it will be necessary to get decent shadow resolution on a high-end card (like an X800). On an X800 you could just jack up the shadow map resolution one more time (to 1024x1024) so then you have 64 shadow pixels for every 1 in that screenshot.
