RE: [Algorithms] Current state of shadow maps?

[Tom F. <tom...@ee...>]

Interestingly:

>Stencil volumes win the indoor/urban, night scenarios=20
>(think doom3, or neverwinter nights for the record)
>- shadows from vegetation can be neglected.
>- many omnidirectional light sources, or lightsources with
> large frustra, for which shadowbuffer is unoptimal (too many render
targets)
>- most light sources have small screen space extent=20
>and world extent, so stencil is not expensive

...actually describes your average StarTopia scene moderately well :-)
http://www.eelpi.gotdns.org/startopia/startopia_pictures.html

(yes, I will get the demo version done soon, I promise!)



The army-with-lots-of-short-range-torches example is an interesting one =
for
shadowbuffers. When the range of a light is small compared to the view
frustum (as will be the case with >90% of the torches), then my scheme =
will
just reduce to essentially a cube map per light. Actually, it gets =
slightly
better - if there's nothing above the torch in range of it (likely), =
then
that face never gets created, and also the face view angles can be =
opened up
to about 120 degrees and still remain efficient - this typically means =
you
lose another face and only need four frustums per light rather a =
cube-map's
six.


Here's some really really rough back-of-the-envelope figures to compare =
the
two. Warning - lots of assumptions ahead!

Assume the shadowbuffers are the type that only write to a Z/stencil
surface, not a colour buffer as well. Remember that my scheme allocates
shadowbuffer texels so that you get 1 texel per screen pixel for the =
area it
covers, if you turn the detail to "max", i.e. pixel-perfect.

Let's also assume that each light's radius sphere covers 10k pixels (a
100x100 pixel area - not unreasonable). Also approximate the =
shadowbuffer
coverage - in practice many pixels in that area won't have receivers, =
and
many others will have multiple receivers. Let's call it even for the =
sake of
argument. Also assume that in any rendering pass, all the pixels get =
tested,
and half get rejected because of overdraw (an entire scene will have =
more
overdraw, but my experience is that shadowbuffer/volume shadows, because =
of
their limited range, get lower overdraw, and 2x is reasonable).

Shadowbuffers:

Per light, rendering shadowbuffers: 10,000 Z tests + 5,000 Z writes =3D =
15k
reads/writes.

Per light, rendering actual scene: 10,000 shadowbuffer reads.

Total =3D 25k reads/writes.


Volume shadows:

Per light, rendering volumes (remembering that volumes have two sides!):
2*10,000 Z tests + 2*5,000 Z writes =3D 30k reads/writes.

Per light, rendering actual scene: the stencil tests come free with the =
Z
reads. No extra cost.

Total =3D 30k reads/writes.


So in terms of fillrate, it's pretty close - shadowbuffering slightly =
ahead,
but I made a lot of assumptions. But shadowbuffering has some big aces =
up
its sleeve:

The first is that I said the quality slider was on "best" - one texel =
per
screen pixel. But you can turn that down - you can easily halve it =
without
any quality loss. In fact, if you have a soft-edged shadow shader, you
_want_ to turn it down lots! So that dramatically reduces the fillrate
required for shadowbuffers.

The second is that you can render a single receiver with multiple
shadowbuffers in one pass - because you're just sampling a texture and =
doing
a comparison. So you can do more than one of these per shader. Let's say =
you
can do two - that's totally realistic for PS2.0 hardware. So you've now
halved the number of passes you do when rendering the scene (I didn't =
list
those reads/writes in the above). This can't be done with volume shadows
(that I know of) - it can only reject the pixel or accept it, it can't
half-shade it. That's a huge win!


Also, the process of extruding volume shadows is far more expensive than =
the
equivalent shadowbuffer thing, which is just rendering the object from a
different POV. I believe most people using VS-driven extrusion find that
they are frequently limited by triangle throughput rather than fillrate. =
And
people using CPU-driven extrusion wish they were doing VS-driven =
extrusion
:-)



TomF.



> -----Original Message-----
> From: gda...@li...=20
> [mailto:gda...@li...] On=20
> Behalf Of Megan Fox
> Sent: 08 September 2005 13:07
> To: gda...@li...
> Subject: Re: [Algorithms] Current state of shadow maps?
>=20
>=20
> Well, let's take the army with torches but apply stencil shadows
> instead (and let's say they're on a field of battle, a heightmap) -
> how is that still not a nightmare scenario?
>=20
> With shadow buffers (using Tom's method), you'd end up:
>=20
> - Creating a lot of frustrums, but not necessarily 1 per reciever per
> light - it's very likely you could merge quite a few of those
> frustrums together, given an army is usually walking in close
> formation
>=20
> With stencil, you'd end up:
>=20
> - Casting your extrusions back for every light/occluder pair.  You
> can't really merge (I don't think?), so that's "it."
>=20
>=20
> Especially after using Tom's handy-dandy frustum merge-o-matic method,
> it seems like the two methods would be comperable - mind, both would
> probably keel over and die in a slurry of render passes (and in both
> cases, you'd probably enable your "oh god we're in trouble start
> merging nearby lights into single lights" optimization code), but it
> seems like neither does terribly well.
>=20
>=20
> I'd thought the "big" win scenario for stencil over buffers was more
> scenes with few occluders and many recievers (that is, your average
> FPS environment)?
>=20
> > Stencil volumes win the indoor/urban, night scenarios=20
> (think doom3, or neverwinter nights for the record)
> > - shadows from vegetation can be neglected.
> > - many omnidirectional light sources, or lightsources with=20
> large frustra, for which shadowbuffer is unoptimal (too many=20
> render targets)
> > - most light sources have small screen space extent and=20
> world extent, so stencil is not expensive
> >=20
> >=20
> > However shadowbuffers have other qualities that make them=20
> attractive (image based, soft edges), so it would be=20
> desireable to use them for all purposes. It's just a pity=20
> that they are so unfeasible for omni lights (I imagine an=20
> army with torches here ...).
>=20
>=20
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development=20
> Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams *=20
> Testing & QA
> Security * Process Improvement & Measurement *=20
> http://www.sqe.com/bsce5sf
>=20
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_ida88
>=20