POV-Ray : Newsgroups : povray.general : Article: Povray's Arealights - Cheap Hack or Not? : Re: Article: Povray's Arealights - Cheap Hack or Not? Server Time
6 Aug 2024 00:16:37 EDT (-0400)
  Re: Article: Povray's Arealights - Cheap Hack or Not?  
From: Alex
Date: 30 Aug 2002 04:15:06
Message: <web.3d6f2875170d095415e7f0160@news.povray.org>
Pandora wrote:

>
>
>    Well, without knowing the source, or anything about the algorithms used,
>one would assume that using the general algorithm of block_area_light in
>Diffuse_One_Light would be the ideal solution - is this your option 2, or a
>further option 3 ?
>    Then, I would assume, all other lighting related effects would
>automatically utilise the area_light options and optimisations (e.g.
>adaptive sampling) that are present for shadow calculations, yes ?
>

Studying a bit more the source (mind you, just a 10 min inspection, while I
was supposed to work), the game seems to be:
1 - Lighting code shoots a ray toward a light (from point of intersection to
light origin)
2 - If the light is an area light, additional shadow rays are calculated, to
estimate blocking of light
3 - Lighting calculation (i.e. diffuse and specular) are done using the
first ray only

This means that:
Light intensity is modulated according to a (possibly) biased estimate of
blocking
Diffuse and specular components are calculated as if the light is a point
light, hence the artifacts shown in the pictures.

To obtain a more correct area light the angles used in lighting calculation
should vary. More precisely, the elements needed to calculate a point
apparent emission are not limited to the radiance from a light source, but
include also the angle of incidence.
The povray code for *direct* lighting appears to neglect this, which proves
to be a good approximation only for distant sources.

The problem is that simply plugging the code to sample more than a single
ray leads to multiple evaluations of texturing components, which could be
avoided in a more specific code.

Montecarlo ray-tracers are very accurate, but slow, because (a) they shoot a
single ray toward light sources, both for shadow and lighting, and
therefore require *many* samples per pixel, or (b) they shoot a bunch of
rays, repeating texture evaluations per each sample ray.

A possible optimization could be to calculate once per intersection the
texturing components which are indipendent of incoming light direction, but
this rules out optimization of BRDF (may be or not be true...it seems to me
but I have to check this more thorougly...there's a discussion of this
problem in some ancient paper from SIGGRAPH, iirc)

povray area lights are perfectly adequate when used in conjunction with
radiosity and photons, which utilize a different approximations of the
illumination integral.

However, to obtain efficient "true" area light, I suspect we would have to
rewrite the whole lighting code. In the meanwhile, I'll try (this sunday,
if time permits) to plug in the code described in Graphic Gems III
(http://www.acm.org/tog/GraphicsGems/).

I think I'll try both styles (single-sample and multi). Inituitively, they
should yield the same times (roughly), but....

If anyone is willing to discuss this more or to help me, feel free to write
me directly on ale### [at] alphacit

Alex

------------------------------------------------------
Shadow softly and carry a big light, you'll render far
------------------------------------------------------


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.