RE: [Algorithms] lights/shadows rendering architecture

[<cas...@ya...>]

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ño
cas...@ya...


Marc Fascia <mf...@fr...> wrote:
> Hello, 
> 
> 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 = 1 pass : 
> 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 = 2n+1 render passes
> 
> 2) 1 pass = 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  = n+1 render passes
> 	- shaders are less scalable
> 	- need memory to store n shadowmaps
> 	
> 3) 1 pass = 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 
> 	- 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



	
	
		
______________________________________________ 
Renovamos el Correo Yahoo! 
Nuevos servicios, más seguridad 
http://correo.yahoo.es