A Robust Alternative to Perspective Shadow Mapping
There's a siggraph session Practical Logarithmic Shadow Maps next week. Maybe - there's not much information available - it's a similar idea. Let's hope nvidia will make that presentation available as a download soon.
Quote:The distortion method has problems with nonlinearity <-> linear interpolation.
In theory, though, it should be possible to not rely on the hardware's bilinear interpolation (use nearest-neighbour instead) and take multiple warped position samples or a nonlinear-weighted blend yourself. For that matter, it's also just as well that you hide these errors by softening the shadows anyway with some sort of PCF or Variance Shadow Mapping. And soft shadows are anyway perceived as more realistic.
Ok. As usual, much more work was needed than I expected, but it should demonstrate the basic quite well. It's even instrumented to be analysed by NVPerfHUD if you have this wonderful tool handy. A readme is included.
It's also larger than expected, mainly due to the demo world we use. I wasn't able to create a smaller world in the short time so I had to use this one. I hope your internet connection is a flat fee.
Zipped Demo, 90 MB (still uploading, ETA 03:15 AM) [edit]Done. I'm off to bed.[/edit]
Just decompress it somewhere, read the ReadMe and run it. All DLLs are included, I hope. Needs SM2.0 minimum. Could maybe cause problems like crashes or very slow framerates on cards with 128MB VideoRAM or less. Again: Work In Progress. Could crash, burn your monitor or fuck up your system any time. It wasn't me, I'm not responsible. Please don't hurt me.
Shadows look ok at the default config, I think. The large tree you see when loading camera position 1 causes some shadow distortion artefacts because it's billboard leaves are too large. Well... we wanted to redo it anyways. All other trees turn to billboard at a certain distance. If you manage to have a shadow of it close to you, maybe on sunset, you can watch a heavy shadow distortion. These are the nonlinear artefacts I wrote about in an earlier post. Looks like the tree shadow is chasing the viewer. Not nice.
On a second thought, there's room for improvement. When rendering the scene, shadow map distortion could be done in the PixelShader. No more linear/nonlinear conflicts there. This way is impossible when rendering the depth pass, though. Maybe onthefly tesselation with SM4.0 could work. In combination it should be possible to increase the distortion factor to get even better shadows close to the viewer.
Another idea is to use another density function. The cause of this linear/nonlinear artefacts is the slope change of the distortion function, thus the slope of the density function. If we choose a density function which starts even at t==0 and then descends rapidly, the beginning of the distortion functin close to the viewer would be linear, thus interpolating fine. The nonlinear artefacts would at least be moved away from the viewer to scene parts a bit farther away.
Bye, Thomas
It's also larger than expected, mainly due to the demo world we use. I wasn't able to create a smaller world in the short time so I had to use this one. I hope your internet connection is a flat fee.
Zipped Demo, 90 MB (still uploading, ETA 03:15 AM) [edit]Done. I'm off to bed.[/edit]
Just decompress it somewhere, read the ReadMe and run it. All DLLs are included, I hope. Needs SM2.0 minimum. Could maybe cause problems like crashes or very slow framerates on cards with 128MB VideoRAM or less. Again: Work In Progress. Could crash, burn your monitor or fuck up your system any time. It wasn't me, I'm not responsible. Please don't hurt me.
Shadows look ok at the default config, I think. The large tree you see when loading camera position 1 causes some shadow distortion artefacts because it's billboard leaves are too large. Well... we wanted to redo it anyways. All other trees turn to billboard at a certain distance. If you manage to have a shadow of it close to you, maybe on sunset, you can watch a heavy shadow distortion. These are the nonlinear artefacts I wrote about in an earlier post. Looks like the tree shadow is chasing the viewer. Not nice.
On a second thought, there's room for improvement. When rendering the scene, shadow map distortion could be done in the PixelShader. No more linear/nonlinear conflicts there. This way is impossible when rendering the depth pass, though. Maybe onthefly tesselation with SM4.0 could work. In combination it should be possible to increase the distortion factor to get even better shadows close to the viewer.
Another idea is to use another density function. The cause of this linear/nonlinear artefacts is the slope change of the distortion function, thus the slope of the density function. If we choose a density function which starts even at t==0 and then descends rapidly, the beginning of the distortion functin close to the viewer would be linear, thus interpolating fine. The nonlinear artefacts would at least be moved away from the viewer to scene parts a bit farther away.
Bye, Thomas
Author
Quote:Original post by krausest
There's a siggraph session Practical Logarithmic Shadow Maps next week. Maybe - there's not much information available - it's a similar idea. Let's hope nvidia will make that presentation available as a download soon.
I looked at that flyer just now, I bet it is the same idea, because they mention "non-linear rasterization."
Luckally, by me and schrompf posting here before the public presentation at siggraph, this technique won't be patented. Booooo Creative Labs...
Oh yeah, and the fact that Schrompf says he had this idea a year ago and there is a German paper on it... that should keep it publicly available.
Has anyone tried this with omni-directional, short-range lights? It seems that you might get some benefit but I dont know..
To see this type of shadows (using sqrt for compression) being used in a more complete game see TaSpring.
Why not use 1/x as the weight function and let the W divide do the distorsion. Also if you split your shadow map in 4 different regions along the axes and render each of them with a normal 4x4 projection matrix you can use the linear interpolation as well.
I've just finished implementing this type of shadows in a commercial game and it looks pretty well, but no screenshots I'm afraid since it is still in development.
I've just finished implementing this type of shadows in a commercial game and it looks pretty well, but no screenshots I'm afraid since it is still in development.
Quote:Luckally, by me and schrompf posting here before the public presentation at siggraph, this technique won't be patented. Booooo Creative Labs...
The date of acceptance of the research article is usually around 4-6 months before the actual presentation. Furthermore, they could easily apply for a Preregistration even before that. However, i tend to believe it wont be patented (unless its a university graduate who is graduating via a PhD in which their procedure might require a patent).
Edwin
Sorry to bother you, but I don't get it working well so I'm asking for your help.
Let's start with the formula:
1. I don't understand what scaling to apply for t. If the viewer position and current vertex position is in [-1,1]^2 and the input paramter t for the formula has to be in [0,1] then I'd get
nt = ln( k*t/sqrt(4.0) + 1) / ln( k + 1) * sqrt(4) / t.
Actually sqrt(4) might be replaced with the maximum length from the projected viewerPosition to all four corners.
2. When the light position is fixed but the viewer changes the shadows move too - Even a change in k makes the shadows move.
I guess one reason is that (when rendering the scene with light) CalculateShadowTextureCoords() returns a w coordinate != 1. Dividing by w in the vertex shader makes things much worse. Keeping w and computing shadowTextureCoords.xy = w * (gShadowViewerPos.xy + texDiff * nt) helps a bit but it's still very noticeable. How do you handle the w coordinate?
Thanks,
Stefan
Let's start with the formula:
1. I don't understand what scaling to apply for t. If the viewer position and current vertex position is in [-1,1]^2 and the input paramter t for the formula has to be in [0,1] then I'd get
nt = ln( k*t/sqrt(4.0) + 1) / ln( k + 1) * sqrt(4) / t.
Actually sqrt(4) might be replaced with the maximum length from the projected viewerPosition to all four corners.
2. When the light position is fixed but the viewer changes the shadows move too - Even a change in k makes the shadows move.
I guess one reason is that (when rendering the scene with light) CalculateShadowTextureCoords() returns a w coordinate != 1. Dividing by w in the vertex shader makes things much worse. Keeping w and computing shadowTextureCoords.xy = w * (gShadowViewerPos.xy + texDiff * nt) helps a bit but it's still very noticeable. How do you handle the w coordinate?
Thanks,
Stefan
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement