RE: [Algorithms] Object-ID based shadow maps aliasing

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

I wonder if it would be sensible to spot the cases where sorting isn't
feasable (intersecting objects, near-intersections, places where you want
self-shadowing that don't partition well, circular sorts, etc), assign them
all the same sorted ID, and use a secondary 8-bit unsorted ID just for them.
That should be do-able in a single pass I think, because the 8-bit sorted ID
is read at the same time as one of the unsorted samples. (I think you
suggested something like that in the GPG2 article?)

I have to admit that partitioning objects into sortable order is a real pain
in some cases. The question is whether the extra reads (i.e. you can't use
them for other things like lightmaps and bumpmaps, so you need extra passes
for those) are worth the reduction in pain.

Hmmmm... an idea I had (or heard somewhere :-) was to render your
shadowbuffer IDs (let's assume they're 8-bit for the moment) into one
buffer. Then render from there into a second buffer the same size, but for
each pixel copy the ID to the red channel, the ID one pixel to the right to
the green channel, one pixel down to the blue, and one pixel right+down to
the alpha. Then use that as your ID buffer. So with a single sample, you
read all four texels, so you're not burning texture reads. Hmmmm.... now
that sounds a lot cooler :-)

Tom Forsyth - Muckyfoot bloke and Microsoft MVP.

This email is the product of your deranged imagination,
and does not in any way imply existence of the author.

> -----Original Message-----
> From: Sim Dietrich [mailto:SDi...@nv...]
> Sent: 05 December 2002 19:04
> To: 'Tom Forsyth '; 'gda...@li... '
> Subject: RE: [Algorithms] Object-ID based shadow maps aliasing
> 
> 
>  I'm working on a shader that uses 2-passes to get 
> non-aliased 16-bit object
> id shadow maps on ps.1.1 hw.
> 
>  It's really tough to use 8 bit object ids for characters and 
> backgrounds
> together, because of the aliasing problems mentioned.  
> Sometimes sorting is
> not feasible, so you'd rather just allocate unsorted IDs.   
> But, 8-bit IDs
> aren't enough for many scenes, so 16 or 24 would be better.
> 
>  It turns out that you can check 2 16-bit unsorted IDs from 
> the shadow map
> vs a constant 16-bit ID in a single pass.  Do two passes and 
> you can check a
> 2x2 area in the shadow map to ensure that all 4 ids are 
> unequal.  This is an
> extension to the method I described in 'practical priority 
> buffers' in gpg2,
> which used sorted 8 bit IDs.
> 
>  16-bit IDs should be enough for most scenes, especially if 
> you are a bit
> clever about allocation, like making sure most coplanar faces 
> in the world
> geometry share the same id.
> 
> 
> -----Original Message-----
> From: Tom Forsyth
> To: gda...@li...
> Sent: 12/5/2002 6:45 AM
> Subject: RE: [Algorithms] Object-ID based shadow maps aliasing
> 
> It looks like you're doing a simple equality test -
> if(myID!=shadowbufferID){shadow_me}.
> 
> The problem is that because of sampling innacuracies and bilinear
> filtering
> suchlike, at the edges of an object, you are bound to pick up some
> texels
> from objects behind it. Some hardware can do the ID equality test
> _before_
> the filtering, and only shadow if all the texels fail the 
> test, but you
> still have to deal with precision problems, so it's not the full
> solution.
> 
> The best thing to do is to replace your == test with a >= 
> test, and sort
> the
> IDs assigned to the objects from front to back. So if we say things
> nearer
> to the light have lower IDs (1=close to light, 100=far away), 
> then your
> test
> becomes
> 
> if ( objectID > shadowbufferID ) { shadow object }
> 
> That way if you have your teapot (ID=1) picking up some 
> texels from the
> table (ID=2), the teapot is still rendered completely unshadowed,
> because
> the IDs aren't the same, but the teapot knows it's just picking up IDs
> from
> things that are definately behind it.
> 
> 
> The sorting can be slightly tricky in some cases, but it can be fairly
> slow
> and careful in the nasty cases. I first see if objects can be 
> separated
> by
> bounding spheres, and then try the planes of bounding boxes 
> (and sort by
> which side of the plane faces the light) - that covers 99% of cases.
> 
> Remember - the PS1 has no Z buffer, and so has to sort everything back
> to
> front, all the time. And it's got a rubbish CPU. Doing the 
> sort is not a
> significant load on today's PCs.
> 
> Also remember that you don't have to change the order you draw objects
> in,
> you just have to assign their IDs in a sorted order.
> 
> 
> Tom Forsyth - Muckyfoot bloke and Microsoft MVP.
> 
> This email is the product of your deranged imagination,
> and does not in any way imply existence of the author.
> 
> > -----Original Message-----
> > From: Petr Smilek [mailto:gu...@pr...]
> > Sent: 05 December 2002 12:28
> > To: gda...@li...
> > Subject: [Algorithms] Object-ID based shadow maps aliasing
> > 
> > 
> > Hi !
> > I have problems with object ID shadow maps due to shadow map 
> > aliasing. I don't want objects to selfshadow, each rendered 
> > mesh has unique shadow buffer ID. When
> > I "light-project" shadow buffer to scene, some objects
> > gets "false shadows" projected on it:
> > 
> > http://www.preality.com/shadowmapping/smap1.jpg. 
> > 
> > Is there some elegant way to avoid this problems ? I need to 
> > run it on standard 2 TMUs HW without pixel shaders and I 
> > don't want to perform clusterization of shadow casters - 
> > recievers by rendering into render target texture multiple 
> > times. 
> > 
> > Thanks
> >   Petr
> > 
> > 
> > 
> > 
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > 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:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=6188
> 