Re: [Algorithms] lights/shadows rendering architecture

[David W. <da...@pl...>]

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

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

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

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

-- David


Ignacio Casta=F1o wrote:

>One pass per light will probably stay around for some time. However, des=
pite
>its drawbacks deferred shading is probably going to become a very attrac=
tive
>alternative.
>
>Specially as soon as you are able to factor expensive per light computio=
ns
>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 o=
nly
>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 f=
or
>>bump mapping/virtual displacement maps) end fully dynamic shadows on ev=
ery
>>geometry (supposedly using shadow maps). I target SM 3.0.
>>
>>I can see several ways of doing the whole lighting/shadowing but I woul=
d
>>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 ex=
tra
>>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 fragme=
nts
>>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 sha=
dow
>>map for a light and then apply it in screen space. I repeat that for al=
l
>>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 shado=
wed
>>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 wou=
ld
>>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 Practi=
ces
>Agile & Plan-Driven Development * Managing Projects & Teams * Testing & =
QA
>Security * Process Improvement & Measurement * http://www.sqe.com/bsce5s=
f
>_______________________________________________
>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
>