That’s damn funny, seems like it’s a meeting of ShaderX II contributors
Arsil, i don’t think your technic would work. For sure you know the current distance to the occluder for the interpolated position. But this position does not correspond to the one of the shadowed pixel.
In the perspective view, consider a pixel P that lies on the shadow of the occluder O.
By interpolating the distance to the occluder, you are actually computing the O-P1 distance (see second figure). But the real pixel, the one that lies on the surface plane, is not P1. It is P2. And the distance from P2 to the occluder is c-P2, which is actually much shorter than O-P1.
In conclusion: you’ll calculate a wrong pixel-to-occluder distance (if that was your idea, that is).
Unfortunately you might be right Computing correct distance to the occluder may be impossible at all…
But I am going to chcek, if I can render soft shadows based only on distance from the light source (maybe weighted with some estimated distance from the centre of the occluder) without artifacts using only one shadow volume pass.
Is this equivalent to having a white texture, with black where your image is yellow. Then you do a blur, but only write to bits that have a green component in your original image? Then you modulate your lighting by this image.
Could you use the stencil from your outer shadow pass to mask out the rendering of the blur. Are you doing this, and is it quicker than colour modulating due to quicker reject from the stencil result?
So this means that the smoothness of the blur result is cut off by the masking, so you actually get hard transitions where the 2 shadow volumes are close together? (not that it looks bad at all
Also, do you vary the blur kernel radius based on screen-space depth, or not bother?
I look forward to your article
Matt Halpin
PS, I’m also writing a ShaderX II article, but it’s on pre-ps.1.4 specular bump-mapping, so nothing too fancy
Is this equivalent to having a white texture, with black where your image is yellow. Then you do a blur, but only write to bits that have a green component in your original image? Then you modulate your lighting by this image.
Yes, exactly.
Could you use the stencil from your outer shadow pass to mask out the rendering of the blur.
I thought about doing that, but i does not directly work at the moment. The result of the second stencil pass is the yellow area. To do it, it’d have to be the green area, or all i’ll get back is a hard shadows (since pixels in yellow areas remain black anyway). It should give a pretty nice performance boost, since blurring is fillrate intensive.
so you actually get hard transitions where the 2 shadow volumes are close together?
Yes, that’s the idea. The shadow is sharper near the occluder.
Also, do you vary the blur kernel radius based on screen-space depth, or not bother?
Well, that’s magic! A depth correction is not needed; given the same pixel and occluder, penumbras that are far away will end up being smaller, hence sharper (in pixel thickness), than penumbras that are closer to the viewer. It’s due to the fact that the stencil passes output is naturally perspective correct.
I can’t believe there’s another one ShaderX II contributor. I thought this was an OpenGL board
Originally posted by Ysaneya: I thought about doing that, but i does not directly work at the moment. The result of the second stencil pass is the yellow area. To do it, it’d have to be the green area, or all i’ll get back is a hard shadows (since pixels in yellow areas remain black anyway). It should give a pretty nice performance boost, since blurring is fillrate intensive…
Is there any particular reason why you couldn’t re-order the passes?
Do inner stencil passes.
Copy to render-target.
Do outer stencil passes.
Do blur with stencil test on.
Yes, that’s the idea. The shadow is sharper near the occluder.
Well, not quite. The gradient of the blur doesn’t change, so you’re actually cutting off a shallow gradient of blur, whereas you would actually want to adjust the blur to have a sharper gradient.
Well, that’s magic! A depth correction is not needed; given the same pixel and occluder, penumbras that are far away will end up being smaller, hence sharper (in pixel thickness), than penumbras that are closer to the viewer. It’s due to the fact that the stencil passes output is naturally perspective correct.
Again, you’re truncating a shallow blur gradient, rather than creating a sharper blur. I think, unless I’ve missed something It still looks much nicer than having the shadows melt over other surfaces
I can’t believe there’s another one ShaderX II contributor. I thought this was an OpenGL board
Is there any particular reason why you couldn’t re-order the passes?
None at all, technically it should work. It just happened that i wrote the code in that order, so i’d just have to clean up the (current) mess and reorder it.
Well, not quite. The gradient of the blur doesn’t change, so you’re actually cutting off a shallow gradient of blur, whereas you would actually want to adjust the blur to have a sharper gradient.
Point taken. I’m definately not claiming to do perfect soft shadows. It’s still a fake technic. But i consider that, as long as it looks half good and half fast, it’s a success.
Although i must admit it’s still a bit overkill to use in a complete game. 40 fps for one light is not too bad for soft shadows, but not good enough for a FPS for example, considering that nothing else is running. I suppose that it could become interesting in a few years (months?), when the Geforce FX / Radeon 9700 will be the standard
Everything I know has already been done.
Hehe, start looking into things you don’t know, and you’ll be welcome to contribute to Shader X III
Originally posted by Ysaneya: Point taken. I’m definately not claiming to do perfect soft shadows. It’s still a fake technic. But i consider that, as long as it looks half good and half fast, it’s a success.
aye, it’s one of the best examples of soft shadows I’ve seen so far, so no problem with that.
you are doing a single jitter with the single light source right? That would be a problem for some objects in the wrong places.
Yeah, i’m doing a single jitter. But i don’t see how it could be a problem with some objects (except when they’re in the jittering radius of the light).
Using a 256x256 map instead of 512x512 improves quite a lot the performance; but, although you don’t see it well in the 2 shots, there’s some aliasing on the shadows when you start moving, which is the primary reason i’m sticking to 512x512 at the moment
I also tested the stencil trick idea. Doesn’t work well; actually it slows down things a bit. The reason is, although the stencil tests saves some pixel-shading fill rate, the maps have to be cleared between each blurring step. With 2 lights that means 6 clears of a 512x512 map.
I don’t know for sure, but you could get the two volumes with just to volume passes into the stencil buffer, but you’d get minor problems with the volume “cutting through” the corners of the model, by scaling the end cap of the colume, that is scaling the volume “pyramid” base. I had a similar idea, but it’s a bit different, since it needs floating point textures ( =), two stencil passes and a blur filter.
Huh? I don’t really see your idea. The basic shadow volumes algorithm requires 2 stencil passes (w/o stencil 2 sides) already. How can you calculate the penumbra without 2 additionnal passes ? I fail to see how just scaling the end cap would be working; you’d just get a different shadow, but no penumbra…?
Yeah, basically I mean front and back, but you can do it with two sided stencil operations, can’t you? Anyways, I won’t tell more before I’ve tested it :]
But, ToolTech, I would actually get a uniformly blended volume (or not using more stencil passes and “blending concatonation”) but it might/should get a bit more accurate one, that actually changes a bit more correctly over distance than what Ysaneya explained. But it’s just speculation, I haven’t tested it, hate beeing confined by school
Cheers!
[This message has been edited by PixelDuck (edited 02-25-2003).]
Yeah, that’s a promising technicue, but last time I checked it couldn’t really deal with multiple lights as it stores intermediate results in color buffer. Still, even if you have to accumulate lighting through textures it might beat multiple volumes.
Originally posted by JustHanging:
[b]Yeah, that’s a promising technicue, but last time I checked it couldn’t really deal with multiple lights as it stores intermediate results in color buffer. Still, even if you have to accumulate lighting through textures it might beat multiple volumes.
-Ilkka[/b]
It is not a problem. You only have to render to the same v-buffer for every lightsource. There is no difference really between this algorithm and std. shadow volume algorithm, except that a v-buffer is used instead of a stencilbuffer.
Computing correct distance to the occluder may be impossible at all…
