RE: [Algorithms] lights/shadows rendering architecture

[John P. <jp...@br...>]

1 pass per light is the only way to do true shadowing (AFAIK).  You can =
draw
shadow maps or volumes in a darker color after the scene is rendered, =
but
you lose the ability to filter specular in the shadows, and you also get
double-dark shadows if you're using individual maps.

We do 1-pass per light, and there is a shader for each light type =
(projected
local directional, infinite, point, etc).  We do a pre-pass to see which
lights are visible in the frame, then turn the other ones off.  The =
objects
keep track of which lights effect them, then add themselves to the
appropriate light's tree each frame.

>> The trick is to be flexible about how geometric informaiton is =
associated
with different things in your engine
This is a great statement, David.  It's just not very easy to do.

________________________________________
From: gda...@li...
[mailto:gda...@li...] On Behalf Of =
David
Whatley
Sent: Wednesday, August 17, 2005 12:07 PM
To: gda...@li...
Subject: Re: [Algorithms] lights/shadows rendering architecture

I find that the issue really revolves around another variable: scene
complexity.=A0 The more complex the scene is to render, the less lights =
and
shadows you can get away with.

Complexity is more than just polycount, it is how the polygons are
organized.=A0 For example, in HJ, we have a huge requirement that the =
world be
made up of interlocking assets.=A0 The desingers build the world for =
parts,
like lego blocks (only they come in shapes like corridors, valleys, etc.
already).=A0 These assets are considered, for partical reasons, =
constantly in
flux so there is no level pre-proecssing done (so far).=A0 The problem =
with
this is that the scenes are not as batch friendly and culling is =
per-asset
(and per-mesh) rather than a nice BSP tree or what have you (though the
assets are in a tree).=A0 This requirement gives us tremendous =
advantages in
building vast amounts of hand-crafted physical space for our MMO, plus
giving designers a lot of creativity that doesn't require as much of an
artist's eye as otherwise (like using a Quake-style editor).

If you have complex lighting, then your game better like breaking areas =
into
small connected spaces where you usually see no more than one to three =
at a
time.=A0 Think Doom 3.=A0 If you have wide open areas (I'm talking real =
ones,
not facades that just give the illusion) then you can get into some =
crazy
complexity with lighting and shadows.

We use 1 pass per light (the direcitonal being one of them).=A0 One =
trick you
can do is... figure out the exact polys that a non-moving light touches =
and
store it with the light as a seperate set of material/mesh pairs.=A0 The =
trick
is to be flexible about how geometric informaiton is associated with
different things in your engine.=A0 The typical scene graph is too weak =
for
optimal rendering.

-- David


Ignacio Casta=F1o wrote:=20
One pass per light will probably stay around for some time. However, =
despite
its drawbacks deferred shading is probably going to become a very =
attractive
alternative.

Specially as soon as you are able to factor expensive per light =
computions
and do them only once. That's the case of per pixel displacement =
mapping,
that require many texture samples per pixel. With deferred shading you =
only
have to do those computations once per pixel and not once per light =
pass.

The main drawback is that you have to do your own antialiasing and that =
it
requires a lot of memory to store the render the render targets.

Stalker used deferred shading and I think there was about it in GPU Gems =
2,
that described the pros and cons in more detail.

--
Ignacio Casta=F1o
cas...@ya...


Marc Fascia <mf...@fr...> wrote:
 =20
Hello,=20

I'm currently implementing a demo of some common-place features of =
next-gen
rendering engines and I hesitate on the lighting architecture of the
renderer. The main features would be hdr rendering, normal maps (used =
for
bump mapping/virtual displacement maps) end fully dynamic shadows on =
every
geometry (supposedly using shadow maps). I target SM 3.0.

I can see several ways of doing the whole lighting/shadowing but I would
appreciate your feedback on these options :

1) 1 light =3D 1 pass :=20
Render first the scene on the Z buffer only, then additevely render the
scene again for each light. If the light casts shadows, this adds an =
extra
render pass to generate its shadow map.
	+ the shadowing occurs early in the pipeline. This way you can avoid
some artifacts, for example mis-rendering specular highlights on =
fragments
that are shadowed.
	+ possible to render projectors in the same pass
	+ scalability : the shaders are simple to write as they manage only
1 light
	- big number of render passes. For n lights casting shadows, i need
1(zbuf) + 2n =3D 2n+1 render passes

2) 1 pass =3D n lights (n being fixed) :
This is a variation of the 1) technique. Shaders are written to treat a =
fix
number of lights + their shadow maps/projectors
	+ allows to limit the number of rendering passes. Total number :
n(shadowmaps) + 1  =3D n+1 render passes
	- shaders are less scalable
	- need memory to store n shadowmaps
=09
3) 1 pass =3D n lights, shadow mapping done in scrreen space at the end
This is a variation of 2). After the rendereing is done, i render a =
shadow
map for a light and then apply it in screen space. I repeat that for all
lights. This also requires n+1 render passes.
	+ limit the total ram needed to store shadow maps as they are
applied one after another
	- shadowing is done at the end of the lighting equation. This will
introduce some artefacts(we ideally need to know if a fragment is =
shadowed
before doing diffuse + specuar calculations)

4) deffered rendering :
	+ lighting has a constant cost
	+ shadowing can occur in screenspace without previously mentionned
artefacts
	- need memory for the MRTs=20
	- writing shaders might be trickier
	- need to break the lighting equation in 2 stages
	- does it scales easily to translucent materials ?

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

Many many thanks in advance.

-Marc Fascia
   =20



=09
=09
	=09
______________________________________________=20
Renovamos el Correo Yahoo!=20
Nuevos servicios, m=E1s seguridad=20
http://correo.yahoo.es


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle =
Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & =
QA
Security * Process Improvement & Measurement * =
http://www.sqe.com/bsce5sf
_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188
 =20