Re: [Algorithms] lights/shadows rendering architecture

[Aras P. <ne...@gm...>]

> 1) 1 light =3D 1 pass :
> <...>
> 2) 1 pass =3D n lights (n being fixed):

I think 1st option is and will be the most popular for quite some
time. 2nd one has it's benefits but also a lot more of housekeeping,
memory usage and shader trickery (especially if you start packing
separate shadowmaps into color channels of a single texture).

Measuring performance in "render passes" isn't very descriptive
though. On the PC, the number of drawcalls (or less likely,
rendertarget switches) will probably be the limiting factor. The
drawcalls are mostly reduced by clever culling (frustum, occlusion,
light range culling, light scissoring for small lights) and that's
pretty orthogonal to shadowing algorithm choise.

> 4) deffered rendering:

Like Ignacio said, it's becomming an attractive option once you start
doing funky material/surface related things per pixel. Right now you
plan to do parallax mapping, which isn't expensive, but already is a
step in the "funky things" direction - in a traditional renderer you
have to do it in every light pass.

> 4) deffered rendering:
>         - writing shaders might be trickier

...or not. You're separating the local illumination and surface stuff
from the shadowing stuff, so at least the number of shader
combinations is reduced.

> 4) deffered rendering:
>         - does it scales easily to translucent materials ?

No :(

> How do you guys handle the lights and these typical problems ? What would=
 be
> a reasonable number of lights casting shadows ?

Depends a lot on, well, various things. Add lights while the framerate
is still ok :)

--=20
Aras 'NeARAZ' Pranckevicius
http://nesnausk.org/nearaz | http://nearaz.blogspot.com