• entries
    422
  • comments
    1540
  • views
    488802

Per Light Rendering

Sign in to follow this  
jollyjeffers

98 views

So I have something useful to talk about now. Just for a change.


(Click To Enlarge)


The above is my current (high level) thinking on rendering a scene with a single light source that is potentially shadowed using shadow maps.

For what I want to do, I think I can safely restrict shadowed lights to being either point lights (cube maps for shadows) or directional lights (planar shadow maps) - I could add spot lights in later on, but I can't envisage them being particularly useful.

Although it's annoying that I have to target D3D9 with this - it'd be pretty awesome to do point-light shadow mapping with a single pass - as we'll be doing with D3D10 [grin]

One thing I think I'll look into adding to that flow-diagram is softening of the shadow maps. From what I've seen, even the trivial/incorrect softening techniques make it look so much better.

Currently the space complexity for a single light goes something like this:
  • Screen_Width * Screen_Height * Render_Target_Format_Size
  • Screen_Width * Screen_Height * Depth_Stencil_Format_Size
  • ShadowMap_Width * ShadowMap_Height * ShadowMap_Format_Size * Number_Of_ShadowMaps

    So, for a 1024 * 768 display with a 24bit depth buffer, running 64bit HDRI and a 512 * 512 Shadow Cube Map we'd only need 15mb of VRAM. Per Light [oh].

    The reasoning behind modelling a single light source might well become more obvious when I post the next diagram [wink]
  • Sign in to follow this  


    2 Comments


    Recommended Comments

    One thing that i have successfully implemented, and that makes wonders, is a shadow map cache. At work, they call me "Mr Cache" (no joke!), because i like to use caches for pretty much anything.

    In the case of shadow mapping, you can estimate the screen-space size of the light as seen from the camera. For a point light, for example, you can consider the light attenuation to generate a radius, forming a light sphere (for spot lights, a light frustum), then find how "big" it is on screen. Then from this, you can dynamically choose the shadow map size.

    If your light volume is 5% of your screen, no need to use a 1024^2 shadow map. A 64^2 will do the trick :) Then, as you start to move forward, you'll switch to 128^2, 256^2, 512^2, up to your maximum shadow map size.

    This has the advantage of keeping an excellent framerate (no need to update each shadow map each frame like for perspective-like techniques) at a reduced memory cost.

    My Ennemy Territory level-viewer, in a test, was running with 50 per-pixel, shadow-mapped point lights on screen, at a good framerate.

    Share this comment


    Link to comment
    Quote:
    was running with 50 per-pixel, shadow-mapped point lights on screen, at a good framerate.

    I'm impressed [smile]

    Thanks for the tips!

    The whole caching idea makes sense to me. One area that I spent a lot of time looking at (for shadow volumes) was temporal coherancy. If the light changed or the object changed (subject to a threshold function) then the shadow volume had to be recomputed, otherwise it just re-used the existing volume.

    Based on my diagram from above, there are probably a number of opportunities to reduce memory consumption and/or share resources.

    Jack

    Share this comment


    Link to comment

    Create an account or sign in to comment

    You need to be a member in order to leave a comment

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now