Jump to content
  • Advertisement
  • entries
  • comments
  • views

Per Light Rendering

Sign in to follow this  


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  


    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
    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.


    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
    • Advertisement
    • Advertisement
    • Advertisement

    Important Information

    By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

    GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

    Sign me up!