nbohr1more
Newcomer
Has anyone played with doing random sampling distribution in stencil shadow volumes to reduce the fillrate costs (akin to SSAO random sampling algorithms)?
Random Sampled Shadow Volumes?
- Thread starter nbohr1more
- Start date
nbohr1more
Newcomer
Well you've mostly answered my question I guess. I was afraid that the coupling between the stencil buffer and depth buffer would
prevent any useful data manipulation methods.
My assumed implementation would be:
1) Determine volume bounds, clip, etc
2) render depth pass \ depth fail (etc) pixels using a sparse sampler to the stencil buffer
where the umbra has 100% probability whilst the penumbra has a probabilistic falloff
3) Do something akin to blurring in the buffer (cheap 2D lerp, etc) in the penumbra regions
Am I missing some fundamental limitation here?
prevent any useful data manipulation methods.
My assumed implementation would be:
1) Determine volume bounds, clip, etc
2) render depth pass \ depth fail (etc) pixels using a sparse sampler to the stencil buffer
where the umbra has 100% probability whilst the penumbra has a probabilistic falloff
3) Do something akin to blurring in the buffer (cheap 2D lerp, etc) in the penumbra regions
Am I missing some fundamental limitation here?
Sorry, I missed the little "Stencil" implementation detail. 
I thought of shadow mapping with random kernels. Anyway maybe this idea can work:
You can interpolate the distance of the shadow volume's extruded edges to the silhuette edge(s) where it makes contact with the light. That together with the area-light size gives you the size of the penumbra. You have to read depth from the z-buffer and calculate the one of the shadow volume on-the-fly, when rendering the shadow volume geometry. The penumbra size and the depth-distance gives you the amount of light cast on a pixel.
There is a problem if the light is larger than the geometry, and the shadow casts an inverse cone, then you don't get the opposite side penumbra overlap with the front side, or any other type of multiple penumbra overlap.
I thought of shadow mapping with random kernels. Anyway maybe this idea can work:You can interpolate the distance of the shadow volume's extruded edges to the silhuette edge(s) where it makes contact with the light. That together with the area-light size gives you the size of the penumbra. You have to read depth from the z-buffer and calculate the one of the shadow volume on-the-fly, when rendering the shadow volume geometry. The penumbra size and the depth-distance gives you the amount of light cast on a pixel.
There is a problem if the light is larger than the geometry, and the shadow casts an inverse cone, then you don't get the opposite side penumbra overlap with the front side, or any other type of multiple penumbra overlap.
nbohr1more
Newcomer
Thanks for the feedback. I had another possibly silly thought...
1) Render the Volume surface projection center as a single pixel value
2) Render the volume surface silhouette to the stencil buffer as a pre-defined value
3) Use a 2D parser to quickly find the center pixels and fill to the silhouette outlines
4) Repeat the analogous operation for the penumbra wedge operations
I presume these 2D actions would be far less taxing then the standard shadow volume operations
where every pixel passes through the 3D draw chain?
1) Render the Volume surface projection center as a single pixel value
2) Render the volume surface silhouette to the stencil buffer as a pre-defined value
3) Use a 2D parser to quickly find the center pixels and fill to the silhouette outlines
4) Repeat the analogous operation for the penumbra wedge operations
I presume these 2D actions would be far less taxing then the standard shadow volume operations
where every pixel passes through the 3D draw chain?
nbohr1more
Newcomer
Ack. I need to wait for my coffee to work before posting
This wont work because we need the 2D region center and need to make 2D silhouettes of
the 3D projection silhouettes. Without a-priori knowledge of how the translation will look, there
would be no way to do that.
This wont work because we need the 2D region center and need to make 2D silhouettes of
the 3D projection silhouettes. Without a-priori knowledge of how the translation will look, there
would be no way to do that.
Similar threads
- Locked
