Dave Dunn <poi### [at] aolcom> wrote:
> I was under the impression that he had adaptive supersampling (and probably
> jitter) turned off

  No, the problem is exactly the opposite: He had adaptive supersampling
turned on, but with a too low value, which results in artifacts in the
extreme cases shown in the page.
  IMO it's very unfair to compare shadows resulting from an area_light with
a too low adaptive value with the ones resulting from an explicit grid of
point lights. In order to make the comparison fairly, the adaptive value
has to the raised as high that no artifacts are seen.

  The real advantage of an area_light over an explicit grid of point
lights is that you can have *lots* of lights in the area_light without
the rendering slowing down unacceptably. For example you could have 30x30
lights in your area_light, and with the proper adaptive setting the rendering
time would be still acceptable. With an explicit grid of 30x30 point lights
you'd better have a couple of weeks to wait for your rendering to finish.

  The only defect of area_light is that it only affects shadow testing and
nothing more. This means that diffuse and specular lighting will still be
the one of a point light. (I'm not saying this is a good thing; it's just
the way it's currently implemented.)
  It might be possible to take into account the area_light settings when
calculating diffuse and specular lighting. Perhaps someone will try a
patch in the near future?

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message
news:3d6e221f@news.povray.org...
> Ben Birdsey <cla### [at] mailcom> wrote:
> > Why not add these kind of features to the area lights?
>
>   Which features?
>


    Everything that Johns article talks about other than shadow artifacts!
As they are area_lights are not area _lights_ they're area _shadow
casters_...

--
Pandora/Scott Hill/[::O:M:C::]Scorpion
Software Engineer.
http://www.pandora-software.com

Post a reply to this message

Warp wrote:
> 
> [...]
> 
>   The only defect of area_light is that it only affects shadow testing and
> nothing more. This means that diffuse and specular lighting will still be
> the one of a point light. (I'm not saying this is a good thing; it's just
> the way it's currently implemented.)
>   It might be possible to take into account the area_light settings when
> calculating diffuse and specular lighting. Perhaps someone will try a
> patch in the near future?

In any case an area light only affecting shadows like now should still be
possible since this is exactly what's often wanted and everything further
would just unnecessarily slow down things in those situations.

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 13 Aug. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

Pandora <pan### [at] pandora-softwarecom> wrote:
>     I think there is a need in POV for a more realistically modelled 'area
> light' (for the want of a better term) and John's Photon Challenge images
> neatly demonstrate why

  Uh? Photon mapping is more efficient with area_lights because you have
better control on how many photons are shot from it. Also AFAIK the photons
are shot randomly from the entire surface of the area light, not from the
individual point lights in it, thus getting actually a better result than
with a grid of point lights.
  Any artifact you may see is produced simply because too few photons are
shot, which is remedied by fine-tuning the photon mapping parameters.

  By the way, I added an entry about area lights to the povQ&T page.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

"Pandora" <pan### [at] pandora-softwarecom> wrote in message
news:3d6e26cb@news.povray.org...
> "Warp" <war### [at] tagpovrayorg> wrote in message
> news:3d6e221f@news.povray.org...
> > Ben Birdsey <cla### [at] mailcom> wrote:
> > > Why not add these kind of features to the area lights?
> >
> >   Which features?
> >
>
>     Everything that Johns article talks about other than shadow artifacts!


    And maybe photons - a quick test seems to suggest that area_lights and
photons do indeed appear to give pretty good results - though I'm not 100%
sure about the physical 'correctness' of the model...

--
Pandora/Scott Hill/[::O:M:C::]Scorpion
Software Engineer.
http://www.pandora-software.com

Post a reply to this message

Warp wrote:
>  The only defect of area_light is that it only affects shadow testing and
>nothing more. This means that diffuse and specular lighting will still be
>the one of a point light. (I'm not saying this is a good thing; it's just
>the way it's currently implemented.)
>  It might be possible to take into account the area_light settings when
>calculating diffuse and specular lighting. Perhaps someone will try a
>patch in the near future?

I would love to give a try...
All that I miss is couple of hints.

Follow me a bit and tell me if I'm heading wrong:

1. Povray shoots a single ray toward an area light to determine light color
(emission?) and multiple rays to determine blocking?

If I'm correct, this means that povray attenuates the color of the light
multiplying it by the blocking factor?
 Something like:
L = Lmax x (fraction of area light blocked)

this also means that only one light vector is taken into account when
calculating the lighting at the surface?

Browsing the sources seems to support this theory....
If I'm correct, the Diffuse function gets called in order to gather light
from sources, it calls do_light, which calls block_area_light.
block_area_light calculates the shadow fraction, using multiple rays.
However Diffuse_One_Light (called from Diffuse) uses the original light
vector only.

It seems to me that two avenues are open:
1. Use a single-ray to sample both color and shadow, leading to the need of
many pixel samples
2. Use a specialized version of Diffuse_One_Light which uses each one of the
shadow rays to calculate lighting

Comments?

Post a reply to this message

Just how much slower is your alternative?  How about if you post the render
times for all your examples?

Post a reply to this message

"Alex" <ale### [at] alphacit> wrote in message
news:web.3d6e4624170d095415e7f0160@news.povray.org...
> If I'm correct, the Diffuse function gets called in order to gather light
> from sources, it calls do_light, which calls block_area_light.
> block_area_light calculates the shadow fraction, using multiple rays.
> However Diffuse_One_Light (called from Diffuse) uses the original light
> vector only.
>
> It seems to me that two avenues are open:
> 1. Use a single-ray to sample both color and shadow, leading to the need
of
> many pixel samples
> 2. Use a specialized version of Diffuse_One_Light which uses each one of
the
> shadow rays to calculate lighting
>


    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 ?

--
Pandora/Scott Hill/[::O:M:C::]Scorpion
Software Engineer.
http://www.pandora-software.com

Post a reply to this message

Greg M. Johnson <gregj:-)565### [at] aolcom> wrote:
> Just how much slower is your alternative?  How about if you post the render
> times for all your examples?

  Here are some render times:
http://www.students.tut.fi/~warp/povQandT/misconceptions.html#arealightconfusion

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message
news:3d6e63af@news.povray.org...
>   Here are some render times:
>
http://www.students.tut.fi/~warp/povQandT/misconceptions.html#arealightconfu
sion
>
> 1 minute 8 seconds to render. [versus]
> ...only 7 seconds to render.
>

My "last place"- winning  IRTC anim two rounds ago used my own homemade area
lights.  It took something like four minutes per frame to render IIRC. I had
no time to add any additional scenes or fix old problems.

Post a reply to this message