Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Page 2 of 2 FirstFirst 12
Results 11 to 13 of 13

Thread: Optimizing cascaded shadow mapping

  1. #11
    Junior Member Newbie
    Join Date
    May 2018
    Posts
    11
    Quote Originally Posted by Dark Photon View Post
    Typically you only shadow diffuse and specular, which typically fade to zero intensity along light-space tangent surfaces
    Thanks for the hint, I went through the source code and saw that shadows were applied to the final, lit color instead of just diffuse + specular. Fixed it.

    Quote Originally Posted by Dark Photon View Post
    So why is the surface so bright here?
    I increased my shadow factor just to demonstrate the artifacts.

    I also used a bounding sphere to compute the frustum splits (to avoid shimmering edges on camera rotations), but that resulted in bounds that were too large in terms of (culling) performance and shadow map resolution. For now, I resolved that by using more splits and increasing the shadow map resolution. Here's a demo of my current state:
    https://www.youtube.com/watch?v=QivCx4WEwcM
    Last edited by fleissna; 06-03-2018 at 12:19 PM.

  2. #12
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    4,394
    Quote Originally Posted by fleissna View Post
    Thanks for the hint, I went through the source code and saw that shadows were applied to the final, lit color instead of just diffuse + specular. Fixed it.
    Good deal!

    I also used a bounding sphere to compute the frustum splits (to avoid shimmering edges on camera rotations), but that resulted in bounds that were too large in terms of (culling) performance and shadow map resolution.
    That's interesting. When I used that trick, I didn't have that problem (and I did it for the same reason: to get rid of shadow edge flickering and keep the shadow edge appearance static with static light source positions). How are you choosing your split distances? IIRC, I was using the "practical split" strategy which is basically a blend of the pure linear and pure log split distances. That helps pull in the split distances, reducing the size of your bspheres. And also, what are your camera FOVs? Of course, the larger those are, the bigger the sphere has to be to circumscribe the splits. ...just wondering what might be different about your situation where you didn't get sufficient shadow res.

    For now, I resolved that by using more splits and increasing the shadow map resolution. Here's a demo of my current state:
    https://www.youtube.com/watch?v=QivCx4WEwcM
    Looks great!

  3. #13
    Junior Member Newbie
    Join Date
    May 2018
    Posts
    11
    Quote Originally Posted by Dark Photon View Post
    That's interesting. When I used that trick, I didn't have that problem (and I did it for the same reason: to get rid of shadow edge flickering and keep the shadow edge appearance static with static light source positions). How are you choosing your split distances? IIRC, I was using the "practical split" strategy which is basically a blend of the pure linear and pure log split distances. That helps pull in the split distances, reducing the size of your bspheres.
    For now I'm just doubling the distances for each consecutive split (16, 32, 64, 128, ...), nothing sophisticated. I'll probably look into more advanced solutions later. Bounding spheres can be significantly larger than the actual split bounds, so there can be lots of wasted space depending on the split distances and FOV of course. I guess this is what caused worse performance and resolution, because the sphere is not that tight as a box.

    Quote Originally Posted by Dark Photon View Post
    And also, what are your camera FOVs? Of course, the larger those are, the bigger the sphere has to be to circumscribe the splits. ...just wondering what might be different about your situation where you didn't get sufficient shadow res.
    It's currently fairly small with 45 degrees.

    I guess I should also take possible shadow receivers into account when computing the splits. This would result in tighter boxes at the expense of more culling work to do on CPU. Also cases like the camera looking straight to the ground would be much more performant then. (Only if I remove that giant ground plane that currently covers the entire scene in the demo )

    Anyways, the main bottleneck in my engine is polygon count due to the lack of LOD (except for instancing). I'm going to look out for mesh-simplification techniques or libraries (MeshLab?) that can do that for me.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •