From: Wolfgang Engel <wolfgang.engel@gm...>  20070412 15:26:06

Hi, I spent some time to think about the best way to generate an orthographic light view frustum for "fullscreen" shadow maps. I actually use code to do this since a long time but I always perceive the resulting frustum as too big. The idea is to tightly fit the light frustum around a slice of the viewer's frustum. Here is how I do it: 1. determine a slice of the camera view frustum 2. calculate a near and far plane for this 3. transform in light space 4. take the extrema and build a bounding box 5. found the center of this box and transform it to world space 5. construct the orthographic frustum from this box By transforming to light space and then taking the extrema, you get a box that encloses one frustum slices. The problem is now rotation. Let's say you contruct the light view matrix upfront just by setting up fixed x and y vectors that just follow the z == light direction vector. If you rotate the camera view under the light what happens is the following: the enclosing orthographic light frustum will rotate around the camera view frustum slice, just by changing its shape. So in worst case it would look on the figure above like a diamond. There are two issues attached to this: the diamond is not necessarily the most efficient form to enclose the slice and second the rotation shows up in the result, because the render target will rotate with it. You can see the shadow flicker because of this. What I did now is a kind of hack: I used the direction of the camera and the x axis of the camera and "crossproduct" them to the light direction. The result is better than before. Do I do anything substantially wrong and is there a better way to handle all this? Maybe I am completely off here ...  Wolfgang 
From: Wolfgang Engel <wolfgang.engel@gm...>  20070412 15:26:06

Hi, I spent some time to think about the best way to generate an orthographic light view frustum for "fullscreen" shadow maps. I actually use code to do this since a long time but I always perceive the resulting frustum as too big. The idea is to tightly fit the light frustum around a slice of the viewer's frustum. Here is how I do it: 1. determine a slice of the camera view frustum 2. calculate a near and far plane for this 3. transform in light space 4. take the extrema and build a bounding box 5. found the center of this box and transform it to world space 5. construct the orthographic frustum from this box By transforming to light space and then taking the extrema, you get a box that encloses one frustum slices. The problem is now rotation. Let's say you contruct the light view matrix upfront just by setting up fixed x and y vectors that just follow the z == light direction vector. If you rotate the camera view under the light what happens is the following: the enclosing orthographic light frustum will rotate around the camera view frustum slice, just by changing its shape. So in worst case it would look on the figure above like a diamond. There are two issues attached to this: the diamond is not necessarily the most efficient form to enclose the slice and second the rotation shows up in the result, because the render target will rotate with it. You can see the shadow flicker because of this. What I did now is a kind of hack: I used the direction of the camera and the x axis of the camera and "crossproduct" them to the light direction. The result is better than before. Do I do anything substantially wrong and is there a better way to handle all this? Maybe I am completely off here ...  Wolfgang 
From: Tibor Klajnscek <tibor.klajnscek@gm...>  20070412 20:55:14

I suspect you're talking about parallel split AKA cascaded shadow maps for directional lights. We're doing a very similar thing. Though a bit different since we're using deferred rendering. What we do is: 1. Setup light space so that it's X axis is as parallel to the view Z axis as possible (cross product :) ) 2. Slice up the frustum 3. Fit a box around the slice in light space (tight around extrema and add a bit of error margin) 4. Create an ortho projection matrix from the box 5. Render shadow map for the slice 6. Render to screen using OOB box from step 3 and matrix from step 4 (positions are sampled from the Gbuffer) This is as close as I've come to a perfect fit. I guess it's good enough as it is. Also, the shadows will flicker no matter what you do when you move/rotate the camera.  Tibor Wolfgang Engel wrote: > Hi, > I spent some time to think about the best way to generate an > orthographic light view frustum for "fullscreen" shadow maps. I > actually use code to do this since a long time but I always perceive the > resulting frustum as too big. > The idea is to tightly fit the light frustum around a slice of the > viewer's frustum. > Here is how I do it: > > 1. determine a slice of the camera view frustum > 2. calculate a near and far plane for this > 3. transform in light space > 4. take the extrema and build a bounding box > 5. found the center of this box and transform it to world space > 5. construct the orthographic frustum from this box > > By transforming to light space and then taking the extrema, you get a > box that encloses one frustum slices. The problem is now > rotation. Let's say you contruct the light view matrix upfront just by > setting up fixed x and y vectors that just follow the z == light > direction vector. If you rotate the camera view under the light what > happens is the following: the enclosing orthographic light frustum will > rotate around the camera view frustum slice, just by changing its shape. > So in worst case it would look on the figure above like a diamond. There > are two issues attached to this: the diamond is not necessarily the most > efficient form to enclose the slice and second the rotation shows up in > the result, because the render target will rotate with it. You can see > the shadow flicker because of this. > What I did now is a kind of hack: I used the direction of the camera and > the x axis of the camera and "crossproduct" them to the light > direction. The result is better than before. > > Do I do anything substantially wrong and is there a better way to handle > all this? > Maybe I am completely off here ... > > >  Wolfgang > >  > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveysand earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithmslist > > 
From: Martin Valigursky <dream.gfx3d@gm...>  20070412 23:52:49

I did similar thing on our last project with few changes: 1. The rotation of the shadow map in world space is fixed (so say u and v axis of shadow map are always parallel with world x and y axis (ground plane)). 2. I texel align shadow map in shadow projector space ... so that when the projected shadow map moves (because scene frustum moves), texels don't slide. This way I was able to use even pretty low density of shadow map texels  even 2 texels per meter was acceptable for static geometry (on low spec machine). There was no pixel flickering at all when the camera was moving or rotating. Martin  Original Message  From: "Wolfgang Engel" <wolfgang.engel@...> To: "Game Development Algorithms" <gdalgorithmslist@...> Sent: Friday, April 13, 2007 1:26 AM Subject: [Algorithms] Othographic Light View Frustum > Hi, > I spent some time to think about the best way to generate an > orthographic light view frustum for "fullscreen" shadow maps. I > actually use code to do this since a long time but I always perceive the > resulting frustum as too big. > The idea is to tightly fit the light frustum around a slice of the > viewer's frustum. > Here is how I do it: > > 1. determine a slice of the camera view frustum > 2. calculate a near and far plane for this > 3. transform in light space > 4. take the extrema and build a bounding box > 5. found the center of this box and transform it to world space > 5. construct the orthographic frustum from this box > > By transforming to light space and then taking the extrema, you get a > box that encloses one frustum slices. The problem is now > rotation. Let's say you contruct the light view matrix upfront just by > setting up fixed x and y vectors that just follow the z == light > direction vector. If you rotate the camera view under the light what > happens is the following: the enclosing orthographic light frustum will > rotate around the camera view frustum slice, just by changing its shape. > So in worst case it would look on the figure above like a diamond. There > are two issues attached to this: the diamond is not necessarily the most > efficient form to enclose the slice and second the rotation shows up in > the result, because the render target will rotate with it. You can see > the shadow flicker because of this. > What I did now is a kind of hack: I used the direction of the camera and > the x axis of the camera and "crossproduct" them to the light > direction. The result is better than before. > > Do I do anything substantially wrong and is there a better way to handle > all this? > Maybe I am completely off here ... > > >  Wolfgang > >  > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveysand earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithmslist 
From: Wolfgang Engel <wolfgang.engel@gm...>  20070413 00:16:23

Hey Martin, can you share how you texel align the shadow map in shadow projector space? This sounds interesting.  Wolfgang On 4/12/07, Martin Valigursky <dream.gfx3d@...> wrote: > I did similar thing on our last project with few changes: > > 1. The rotation of the shadow map in world space is fixed (so say u and v > axis of shadow map are always parallel with world x and y axis (ground > plane)). > 2. I texel align shadow map in shadow projector space ... so that when the > projected shadow map moves (because scene frustum moves), texels don't > slide. > > This way I was able to use even pretty low density of shadow map texels  > even 2 texels per meter was acceptable for static geometry (on low spec > machine). There was no pixel flickering at all when the camera was moving or > rotating. > > Martin > >  Original Message  > From: "Wolfgang Engel" <wolfgang.engel@...> > To: "Game Development Algorithms" <gdalgorithmslist@...> > Sent: Friday, April 13, 2007 1:26 AM > Subject: [Algorithms] Othographic Light View Frustum > > > > Hi, > > I spent some time to think about the best way to generate an > > orthographic light view frustum for "fullscreen" shadow maps. I > > actually use code to do this since a long time but I always perceive the > > resulting frustum as too big. > > The idea is to tightly fit the light frustum around a slice of the > > viewer's frustum. > > Here is how I do it: > > > > 1. determine a slice of the camera view frustum > > 2. calculate a near and far plane for this > > 3. transform in light space > > 4. take the extrema and build a bounding box > > 5. found the center of this box and transform it to world space > > 5. construct the orthographic frustum from this box > > > > By transforming to light space and then taking the extrema, you get a > > box that encloses one frustum slices. The problem is now > > rotation. Let's say you contruct the light view matrix upfront just by > > setting up fixed x and y vectors that just follow the z == light > > direction vector. If you rotate the camera view under the light what > > happens is the following: the enclosing orthographic light frustum will > > rotate around the camera view frustum slice, just by changing its shape. > > So in worst case it would look on the figure above like a diamond. There > > are two issues attached to this: the diamond is not necessarily the most > > efficient form to enclose the slice and second the rotation shows up in > > the result, because the render target will rotate with it. You can see > > the shadow flicker because of this. > > What I did now is a kind of hack: I used the direction of the camera and > > the x axis of the camera and "crossproduct" them to the light > > direction. The result is better than before. > > > > Do I do anything substantially wrong and is there a better way to handle > > all this? > > Maybe I am completely off here ... > > > > > >  Wolfgang > > > >  > > Take Surveys. Earn Cash. Influence the Future of IT > > Join SourceForge.net's Techsay panel and you'll get the chance to share > > your > > opinions on IT & business topics through brief surveysand earn cash > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > _______________________________________________ > > GDAlgorithmslist mailing list > > GDAlgorithmslist@... > > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > > Archives: > > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithmslist > > >  > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveysand earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithmslist > 
From: Will Vale <will@se...>  20070413 04:03:27

On Fri, 13 Apr 2007 12:16:23 +1200, Wolfgang Engel = <wolfgang.engel@...> wrote: > Hey Martin, > can you share how you texel align the shadow map in shadow projector = > space? I did something like this with cascaded orthographic shadowmaps a couple= = of years back  you snap the projection centre to the texel size, so tha= t = movement of the frustum is always by N texels. The end results were quit= e = good. The code was pretty trivial  this is excerpted from the = worldtolightview matrix construction:  // Proposed centre of the map in world space Vector sm_origin =3D ... // Axes of the map in world space  i.e. frustum axes const Vector sm_i, sm_j =3D ... // Dimensions of the map in world space  i.e. frustum size const float sm_width, sm_height =3D ... // Dimensions of the map in texels const float texel_width, texel_height =3D ... // Project origin onto axes float sm_x =3D dot( sm_origin, sm_i ); float sm_y =3D dot( sm_origin, sm_j ); // How wide is one shadowmap texel in world space? const float du =3D sm_width / texel_width; const float dv =3D sm_height / texel_height; // Take remainders to get the distance into the texel sm_x =3D fmodf( sm_x, du ); sm_y =3D fmodf( sm_y, dv ); // Snap origin to texel sm_origin =3D sm_origin  (sm_x * sm_i + sm_y * sm_j);  Then you just go ahead and build the camera matrix using the modified = origin and the axes you had to start with. There are a couple of pictures of the results here  can't recall if I'v= e = posted these before. If so, my apologies. http://www.secondintention.com/portfolio/worldlight/soft_shadow_detail http://www.secondintention.com/portfolio/worldlight/long_afternoon_shado= w You can also see how a depthsensitive screen space filter might look  = I = was pleasantly surprised, although you get some artifacts on steep = surfaces  for example, when looking down a long street with a lowdown = = camera, you can see some stepping on the shadow edges. Cheers, Will 
From: Michal Valient <michal@gu...>  20070413 11:28:18

Hi Wolf, I did something similar some time ago for our sunlight with Parallel split shadow maps (or Cascaded shadow maps, what is the correct name anyway the idea seems to be also in 'Rendering Optimal Solar Shadows Using Plural Sunlight Depth Buffers' paper from Katsumi Tadamura). I actually focused more on the shimmering removal than the best fit. For each split... 1) Determine slice of the camera view (we do splits only in camera view direction) and create smaller view frustum with modified near and far clip planes (according to slice distances)  I'll call it Slice view frustum. 2) Compute "conservative" 2D trapezoid for the Slice view frustum (in local space of that frustum). By conservative I mean that any orthogonal projection of our 3D slice view frustum on a plane would fit into that 2D trapezoid (if properly rotated). For us the computation is simple  it's just diagonal cut of the Slice view frustum (more specifically top left and bottom right points on near and far clip planes). 3) Compute bounding circle of the 2D trapezoid. The center of the bounding sphere is always on the view vector going through the center of the Slice frustum. 4) Place the center of the bounding circle into the world space + snap it to nearest shadow map texel center  similar to what Will and Martin mentioned. 5) Compute orthogonal light frustum for the slice so that central ray (of the light frustum) would go through center point computed in previous step. Width and height of the frustum is 2x radius of the bounding circle from step 3. Up direction (up in light space) is locked constant. The resulting shadow is not the perfect fit, but it has following nice properties: 1) Rotation and movement of camera does not cause rotation of shadow map (as its "up" direction is locked) and does not cause any scaling of the shadow map (unless field of view or shadow slice sizes change) as we always use conservative encapsulation of slice frustum. 3) Rotation and movement of camera only cause movement of entire light frustum as the center of bounding circle moves. This means that the shadow map is only scrolling (panning) in X and Y directions (shadow map 2D space). Since center position is aligned to nearest shadow map texel, the scrolling always jumps exactly by one or multiple texels. As a result there is no shimmering when camera moves or rotates. Cheers, Michal Valient Original Message From: gdalgorithmslistbounces@... [mailto:gdalgorithmslistbounces@...] On Behalf Of Wolfgang Engel Sent: Thursday, April 12, 2007 5:26 PM To: Game Development Algorithms Subject: [Algorithms] Othographic Light View Frustum Hi, I spent some time to think about the best way to generate an orthographic light view frustum for "fullscreen" shadow maps. I actually use code to do this since a long time but I always perceive the resulting frustum as too big. The idea is to tightly fit the light frustum around a slice of the viewer's frustum. Here is how I do it: 1. determine a slice of the camera view frustum 2. calculate a near and far plane for this 3. transform in light space 4. take the extrema and build a bounding box 5. found the center of this box and transform it to world space 5. construct the orthographic frustum from this box By transforming to light space and then taking the extrema, you get a box that encloses one frustum slices. The problem is now rotation. Let's say you contruct the light view matrix upfront just by setting up fixed x and y vectors that just follow the z == light direction vector. If you rotate the camera view under the light what happens is the following: the enclosing orthographic light frustum will rotate around the camera view frustum slice, just by changing its shape. So in worst case it would look on the figure above like a diamond. There are two issues attached to this: the diamond is not necessarily the most efficient form to enclose the slice and second the rotation shows up in the result, because the render target will rotate with it. You can see the shadow flicker because of this. What I did now is a kind of hack: I used the direction of the camera and the x axis of the camera and "crossproduct" them to the light direction. The result is better than before. Do I do anything substantially wrong and is there a better way to handle all this? Maybe I am completely off here ...  Wolfgang  Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveysand earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithmslist 