Re: [Algorithms] Maximising precision in floating point shadow maps

[Alen L. <ale...@cr...>]

In this method, I guess you need Nx(M+1) shadowbuffers if you have N lights
and M objects (+1 is for ID buffer). Isn't that much too memory intensive?
Alternatively, you can do it with N*2 buffers, but then you have to make a
lot of rendertarget changes during rendering, because you rerender the
object-specific shadowbuffer before you render that object. Or have I
misunderstood you?

Alen

----- Original Message -----
From: "Tom Forsyth" <tom...@ee...>
To: <gda...@li...>
Sent: Thursday, December 22, 2005 7:28 PM
Subject: RE: [Algorithms] Maximising precision in floating point shadow maps


> In the end, the main problem is that 16 bits isn't all that
> much depth information,

Yep. In fact, I'd say that you're better off simply using 16-bit fixed-point
(i.e. integer) for shadowbuffers. Same number of bits, but totally
predictable precision.

For shadowbuffers that span long ranges, I've been experimenting with a
combined ID & depth buffer. The ID buffer gives you inter-object shadowing,
while the depth buffer gives you intra-object shadowing. So the depth buffer
only needs to have enough precision to hold any single object - and you know
ahead of time how large your objects can be.

Another variant is to scale the value stored in the depth buffer by the near
and far planes of the object itself, so large objects get rather coarse
self-shadowing (aircraft wings on body), but small objects get very precise
self-shadowing (e.g. human faces - noses on cheeks, etc). Any single object
shares the same near and far planes, so you can do this. Different objects
obviously don't, but they have different ID values, so you never even
compare their depth values :-)


TomF.

> -----Original Message-----
> From: gda...@li...
> [mailto:gda...@li...] On
> Behalf Of Jon Watte
> Sent: 22 December 2005 09:51
> To: gda...@li...
> Subject: Re: [Algorithms] Maximising precision in floating
> point shadow maps
>
>
>
> You want to store the depth range normalized to the dynamic
> range of the
> type, which IIRC is about 1/60000 through 60000. In fact, you
> probably
> even want to use the negative range, too -- that way, you use all the
> bits. If you normalize to 0..1, parts of the exponent are
> going unused,
> as well as the sign bit.
>
> You probably also want to make your representation be such
> that the best
> resolution is closest to the camera -- easy with view-aligned depth
> buffers (and the reason why regular Z works better than W buffers in
> practice). However, when your shadow frustum is not view
> aligned, this
> is just really hard to accomplish.
>
> In the end, the main problem is that 16 bits isn't all that
> much depth
> information, unless you can put the near clip plane very far from the
> shadow light source -- no clouds or airplanes allowed to cast
> shadows! I
> would really look into using a format like R32F for the
> shadow information.
>
> Also note that, even though 16-bit floats may support filtering, they
> will filter the wrong way -- you really want to filter your samples
> AFTER the depth comparision (percent closer filtering);
> regular texture
> filtering will first average the depth values, and then do a single
> depth comparision. Thus, with floating-point depth maps, you probably
> want to sample it four times yourself, and do whatever soft edge
> algorithm you can think of.
>
> Cheers,
>
> / h+
>
>
> Rowan Wyborn wrote:
> > Hullo,
> >
> > So now we have these wonderfull 16 bit floating point
> formats to render
> > our shadow maps into, there are a lot of options for storing depth
> > values. Given an [x,y,z,w] point transformed into the shadow map, we
> > could store:
> >
> > - projected (z/w)
> > - z or w
> > - z or w scaled and biased to the range of [0..1]
> > - inverse of any of the above
>
> --
> -- The early bird gets the worm, but the second mouse gets the cheese.
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep
> through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.
> DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=6188
>



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=ick
_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_ida88