RE: [Algorithms] General-purpose shadowbuffer implementation.

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

> but you only need=20
> it for the large outdoor sunlight.

Untrue. You need it any time there is a significant change in the
light<->object distance or the camera<->object distance. If your light =
is
the sun, the first one is constant, and yes - you only _need_ it for =
large
scenes (though it can optimise smaller scenes). But if your lights are
local, you need it a lot.

> I want to avoid rendering multiple shadow map faces per light=20
> source.

But why? It's really not very expensive, it just "feels" like it is. =
There's
three main costs to it:

-Changing render targets

-Rendering shadow casters to multiple targets (only happens to a small
fraction of objects, but it's a cost)

-Rendering with multiple render targets, i.e. a texture switch.


The first one used to be a killer - but it's become a lot cheaper these
days. And if you use a decent wrapper library that allocates a few =
larger
rendertargets and then partitions them into smaller ones (I use a =
quadtree
allocator - very easy to write), you actually don't change rendertarget =
or
texture all that much.

So the real cost is the extra rendering. Two parts to this - fillrate =
and
geometry processing. The idea of choosing your SBs well is to only pick =
them
as big as you have to. So if you do that, you minimise the fillrate. If =
you
could reduce the fillrate even more, you would have picked smaller SBs,
right? If you had used paraboloid maps or something like that, they =
still
need the same texel density. So still the same number of texels, and =
thus
the same fillrate. So the geometry cost - as you point out, the =
alternative
is massive tessellation to cope with the curvature of a parapoloid map. =
Far
cheaper just to render the thing two or three times.

Paraboloids might avoid the seam problems slightly better. But only if =
you
can always use a single one, and I claim that you can't. The problem is =
that
you still haven't solved the duelling frustums problem! So again, you =
either
need the whole thing to have huge resoloution, or you suffer Big Texel
Syndrome on things that are close to the camera.


TomF.


> -----Original Message-----
> From: Christian Sch=FCler=20
> [mailto:gda...@li...] On=20
> Behalf Of Christian Sch=FCler
> Sent: 28 August 2004 03:38
> To: gda...@li...
> Subject: RE: [Algorithms] General-purpose shadowbuffer implementation.
>=20
>=20
>=20
> I believe the cascade approach is the only useful solution=20
> available today that works well in a general case. It comes=20
> with the prize of rendering multiple maps, but you only need=20
> it for the large outdoor sunlight.
>=20
> What gives me more headaches is many small local lights, like=20
> torches on walls for instance.
>=20
> Since they are attached to something, most of them could be=20
> bounded with a light cone of 180=B0, so they are hemispherical.=20
> This would make them suitable for a single pass paraboloid=20
> map. Even slightly larger cones like 200=B0 could be fitted=20
> onto a single paraboloid map. But the geometry of the=20
> buildings would need to be tesselated really high for the=20
> nonlinear projection to work.
>=20
> I want to avoid rendering multiple shadow map faces per light=20
> source. If I go shadow volume, I could have omnidirectional=20
> shadows for local lights in a single pass always. But shadow=20
> volumes would need a completely different pipeline on top of=20
> the existing one.
>=20
> So if anyone knows the Miracle Worker (tm), I'd like to know ...
>=20
>=20
> -----Original Message-----
> From:	gda...@li... on behalf=20
> of Jonathan Blow
> Sent:	Fri 8/27/2004 5:20 PM
> To:	gda...@li...
> Cc:=09
> Subject:	Re: [Algorithms] General-purpose shadowbuffer=20
> implementation.
> Before the TSM paper came out (I think; before I heard of it,=20
> anyway) I=20
> was doing all kinds of things in that area, after being very=20
> frustrated=20
> at PSM.  My general M.O. was to think about the shadow map as being a=20
> surface in world space, and then build an arbitrary transform=20
> by mapping=20
> 4 points in world space to 4 points in projective space.  (Or=20
> 3 points=20
> and a vector, for parallel light sources).  There are a whole=20
> bunch of=20
> strategies you can explore about how to choose the 4 points, which=20
> becomes a generalization of PSM, TSM, etc.  They all suck.
>=20
> -snip
>=20
>=20