Besides the things people have already commented, two points:

  Your "true" area light is not a true area light. It's a grid of point
lights, which is a completely different thing.

  There *is* a major difference between area_lights and grids of point
lights: The area_light calculations are done *only* for shadow testing.
Nothing else. For any other purpose an area_light is a point light and
nothing more. (I'm not saying that this is a good thing; I'm just stating
the fact.)
  (Ok, photons is another place where area_light makes a difference if
configured to do so, but that's another different issue.)

  By the way, I don't like your attitude at pointing at area_light "defects"
which are simply caused because you used an adaptive value which was too low
or too low dimensions. The documentation is quite clear about this: It
explains in full detail what does 'adaptive' do and what happens if it's too
low.
  Since that is an artifact which is to be expected from a too low adaptive
value and this is clearly explained in the documentation along with a simple
solution (ie. use a larger adaptive value and if that's not enough, increase
the dimensions of the area light), it's unfair that you speak of it as if it
was a defect.

-- 
#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

John Mellerick wrote:
 >
> Hi all,
> 
> Not sure if this is the right group for it (maybe advanced users would be
> better). I've just written an article about Povray's arealights, based on
> some tests I've conducted recently, and unfortunatly I have to say it isn't
> glowing with praise for them.

As I understand it, POV's area lights pretty much are crude hacks. Their 
*only* purpose is to create soft shadows, not to accurately simulate 
flat-panel lighting or arrays of point lights.. and because they only 
calculate shadows, they can do so much faster than a real light array 
while using less memory. Even today this is valuable; in the past it 
would have been necessary.

In regards to Christoph's "theoretical" comment, I suspect he means to 
say that having over a hundred point lights for every light in a scene 
may be practical for simple test scenes, but would make rendering for 
many real scenes unacceptably slow. I have often found the same to be 
true of high radiosity settings.

I do find the "stadium lighting" effect on the half-marble strange, 
though. Are you sure you're using the area light properly?

-Xplo

Post a reply to this message

I just wanted to say a quick word or two in defence of John and his
article.

    I can remember when I first discovered POVs area-lights and being hugely
disappointed by the results. I wanted a fluorescent strip light in my scene,
I quickly dug into the docs and found the funky area_light thing, tried it,
and it just didn't look right - I had the strip light close to a wall and
spotted the same 'the light seems to be coming from the center of the strip,
not all along it' effect.
    Ok, I later read the documentation in more depth and realised that
area_lights were never designed for the effect that I wanted and in the end
I produced something similar to John's 'truAreaLight' solution.
    But my initial reaction on reading the docs was exactly the same a
John's - 'these area_light things just don't behave realistically' - and the
very fact that Warps misconceptions page needs a section on area lights
(though, I note it insists that the results you get from an area light are
'practically identical' to an array of point lights) shows that we're not
the only two people to have had misconceptions about what area_lights are
meant to do and how they are meant to behave.

    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 - so what if it renders more slowly - people are
going to quickly learn that 'truAreaLights' (to use John's nomenclature)
kill render time, just as we all quickly came to understand that
antialiasing produces a big hit on render time - when it does produce more
realistic lighting effects ?

    Everything in POV is to some degree optional, and to some degree affects
render time, and it is up to us to decide where and when we choose to use
each feature to achieve the results we desire. I do not see why there would
be any problem in implementing an optional, more realistic, model of 'area
lights' in POV - there clearly is a need for it - and it could, I would have
thought, also benefit from optimisations and techniques that the 'create an
array point lights' solution can not.

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

Post a reply to this message

Pandora 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 -

I was under the impression that he had adaptive supersampling (and probably
jitter) turned off , and the POV area_lights were probably not being used to
their best potential. I think everyone, at one time or another, has tried to
make their own version of a "real area light." My best attempt involved not a
grid but a randomized 3D cluster (using #while), and the shadows were nice and
creamy etc., and, of course, took forever.  But everyone realizes sooner or
later that area_lights are there for basically one reason - to provide soft
shadows in a reasonable amount of time, and I think, when properly used, they do
a great job.

Post a reply to this message

"Dave Dunn" <poi### [at] aolcom> wrote in message
news:3D6D7167.EA598FCF@aol.com...
> Pandora 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 -
>
> ....everyone realizes sooner or
> later that area_lights are there for basically one reason - to provide
soft
> shadows in a reasonable amount of time, and I think, when properly used,
they do
> a great job.
>


    Sure, I'm not criticising POVs area_light performance in terms of what
they were designed to achieve. However they don't achieve, what on the
surface, and on a quick read of the area_light docs, it would appear they
might. Correctly used, they're great at producing efficient soft shadowing,
but that's all they're good for. But, now we have things like photons and
dispersion, and to some degree before these things were available in the
standard POV distribution (for example, in the case of specular highlights)
I
do believe there is a need for a more realistic 'area light' light source
form that does behave in the way one might assume from a quick read of the
area_light documentation.

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

Post a reply to this message

Micha -

I'll bet you're right.  I tried to trace out the area light code in
lighting.cpp, but it's a total mess!  If you're right, I think it should
probably be fixed in the next implementation of POV!

- Ben

Post a reply to this message

Warp -

Why not add these kind of features to the area lights?

- Ben

Post a reply to this message

Christoph Hormann wrote:

[lots]

Keep in minds that the following point may be moot...I haven't studied the
sources....

try {

Having spent most of my copious free time reading CG articles, dissecting
sources, coding some of mine and in general listening to any sources of
information, I feel that I have more of an adeguate understanding of ray
tracing to post the following question?:

1. How does Povray samples area lights?

Granted, Povray is no MC raytracer, but the problem should be similar.

2. Shouldn't it sample the solid angle subtended by the area light?

IIRC, illumination from an area light should be (in Kajiya's notation):
             /                                                dA'cos t'
L(x, psi) =  | g(x, x') rho(x, psi, psi') L(x' psi') cos(t) * --------
             / x' on S                                        ||x'-x||^2

where:
g is the blocking function, psi is the viewing vector, psi' the illumination
vector, rho is the BRDF L is the luminance function, t is the angle between
psi' and surface's normal at x, t' is the angle between psi' and x' and dA'
is the differential area of x'

3. How does Povray approximates this integral?

There is an interesting article in Graphics Gems III (ancient in terms of CG
time) which gives an unbiased probability function for a MC integration,
which should be applicable to distribution ray tracers.

4. Who is the author of the lighting code?

I would love an article from the guy (or guys) detailing the structure of
Povray's lighting engine and I daresay I'd buy a book on the innards of
Povray 3.5, which would make a splendid coursebook in CG.

I never had time to properly study Povray's sources and I'd love to plug in
some CG algorithms I've been reading in these years.

What I miss is an HOWTO (linux-style), detailing the functional units in
Povray.

Maybe...a book, or, better yet, an eBook.
}
catch(flames)
{
  // Exception dumb handler
  // Here we deal with people who can't stand a flame-bait

  // done.
}

Enough ranting...

Seriously, though: why not an eBook about Povray source?
The POV Team could write it (using docbook perhaps) and sell it through the
Povray site, making us tinkerer happy twice (we get to fully understand the
code and we *also* get to finance Povray development)
10$ or 20$ might be a reasonable price and without printing and distribution
costs, most of it would benefit the Povray team.

Just a thought,
Alex

Post a reply to this message

On Thu, 29 Aug 2002 03:58:37 EDT, "Alex" <ale### [at] alphacit> wrote:
> I never had time to properly study Povray's sources and I'd love to plug in
> some CG algorithms I've been reading in these years.

Like for example what ?

Many of algorithms can be implemented via SDL. Have you already tried this
way?

ABX

Post a reply to this message

ABX wrote:
>On Thu, 29 Aug 2002 03:58:37 EDT, "Alex" <ale### [at] alphacit> wrote:
>> I never had time to properly study Povray's sources and I'd love to plug in
>> some CG algorithms I've been reading in these years.
>
>Like for example what ?
>
>Many of algorithms can be implemented via SDL. Have you already tried this
>way?
>
>ABX
>



If you manage to implement this in SDL, I'd like to worship you as a new
Coding Deity

Alex 'No-offense-meant' Morelli
Pov & peace

Post a reply to this message