Hi Ben,

> light_source {
>     <?, ?, ?>
>     color ?
>     area_light <?, ?, ?>, <?, ?, ?>, 2, 2
> }
>
> which would just put a pointlight at each corner of the rectangle and
> give you exactly the results you are showing.

Well, actually I *did* use the 8, 16 settings! Here's the code, copy and
pasted right out of the .pov file:

  light_source
  {
    0*x                 // light's position (translated below)
    color <1.0, 1.0, 1.0>*1.7       // light's color
    area_light
    <2, 0, 0> <0, 4, 0> // lights spread out across this distance (x * z)
    8, 16                // total number of lights in grid (4x*4z = 16
lights)
    adaptive 0          // 0,1,2,3...
    #if (letPovrayCheat = true)
      adaptive 5
    #end
    translate <-2, 0, -2>   // <x y z> position of light
  }

Ignore the comments, I never botherd updating them from the Povray defaults.
As you can see, for the first test the Povray area light *did* have 8x16
lights.


John

Post a reply to this message

Hey Christoph,

> You seem to have put quite some work into that, but you don't seem to know
> very much about the technical aspects of soft shadows in a raytracer in
> general and about the POV-Ray area_light function in particular.

That's true, I have never tried coding a raytracer before (but next year in
college there is a module in computer graphics where I will - looking
forward to it ;)), so I don't have any technical programming knowledge of
how Povray specifically works, or how other raytracers work. I'm just basing
my test visually, on the images I get out of Povray.

> I addition your text does not seem to spend a single word on speed
> issues.

Mostly true. I never say which is faster (Povray's arealight is faster), but
I do say about the macro I wrote "The more lights, the smoother the shadows
you'll get out of the macro, but it will take longer to parse and render,
and it will use up more memory". Not great. In the next update on the
article, I'll include a more detailed comparison of the speed of the two
types of lights (I don't have the renderstats for the scenes any more).

> My suggestion before jumping to quick conclusions would be to:
> - read the relevant sections of the POV-Ray documentation again, a lot of
> the things you write indicate you did not really understand what
> area_lights are about.

Good idea - there probably is something basic I'm missing ;) I'm a little
hazy on the way adaptive works exactly, but seeing as it was disabled for
the main test on the page, I didn't think it mattered. Also, I'm sure my
upcoming module in CG will help out in this regard.

> - read something about the techniques of soft shadows in raytracing in
> general, you seem to think the POV-Team does not know how to implement a
> good area light function...

As I said in the article, I know it's hard to code, and I have not a bad
word to say against the PovTeam. It's just that the behaviour of the
arealight in Povray from what I have seen in my tests seems to deviate
wildly from both reality and from what the documentation would suggest. The
simple macro I coded gave about 98% of the results I was expecting, while
the Povray arealight broke down for every test. Also, as I said in the
article, it's all just my oppinion ;)

> - use POV-Ray more intensively to get a feeling for the necessities when
> really using the program and not just doing theoretical tests.

There is nothing too theoretical about the tests. The Illumination Footprint
would come into effect if you were trying to simulate flat-paneled lighting
near walls. The other two tests come into play if you are trying to simulate
reflective or refractive objects in your scenes. These all seem like fairly
normal applications of a raytracer to me.

> BTW, most of the images are broken because of spaces in the file names.

Yeah, sorry about that, it should be fixed now. It was working for me with
my browser, so I just assumed - oops! All the spaces have been removed. I'd
be interested if you gave the page another look...

Thanks for reading!


John

Post a reply to this message

Hi Micha,

> My first guess is that POV-Ray always uses the same light direction
(namely
> the vector from lightsource "main" location to the hitpoint) for the
> calculation of the lighting (diffuse, phong, etc.). Or it does this
> calculation only once (with a light source intensity calculated from all
> the shadow rays shot for each sub-light of the area_light). This would
> explain pritty much all of your effects.

That might be it - however, without looking at the source code, I guess I
won't know for sure. I'm kinda busy with work and getting ready for college
in a few weeks at the moment, so hopefully I'll get a chance to look through
it soon.

>Also, if the light source is
> relativly far away from the illuminated objects it will not make a big
> difference as the vector only changes a bit.

Agreed. However in my test scenes, the lights were only a few units away
from the objects at most, so they should have recieved plenty of
illumination. The Povray arealight seemed to leave the sides of the spheres
in the dark, even with very long lights (see the extra 'cat's-eye' test near
the bottom).


John

Post a reply to this message

Hi Thorsten,

> You would have gained more by reading the documentation first and to try
to
> understand it rather than building a wrong mental model of how POV-Ray
works
> to then develop a model how it should work that misses most important
> points.

I did read the documentation, and it seemed to suggest to me that the
arealight was, at base, just a rectangular array of point light sources. I
understand (I think) how the adaptive and jitter keywords change the simple
rectangular arrangement of lights, but these were disabled for my main
tests, and so shouldn't have had any effect over the basic grid of lights.

>While different shapes for area light sources are nice, that is the
> only thing your SDL code provides.

Maybe you misunderstand - my macro lightsource wasn't designed to be better
than the Povray area light, and it wasn't designed as a replacement, it was
merely designed to replicate what the docs seem to say the area light does.
I didn't use the third dimension in my tests, and I only coded it in so I
could play around with it myself.

> However, as most of the image and SDL links are broken it is hard to say
> more in detail...

Yeah, sorry about that, the page was working fine in my browser so I assumed
it worked for everyone. So I've updated the page by removing the spaces from
all the image and linked file names. I'd be greatful if you'd have a look at
it again.

All the best,


John

Post a reply to this message

In article <3d6d46dd@news.povray.org> , "John Mellerick" 
<joh### [at] maildcuie> wrote:

> Yeah, sorry about that, the page was working fine in my browser so I assumed
> it worked for everyone. So I've updated the page by removing the spaces from
> all the image and linked file names. I'd be greatful if you'd have a look at
> it again.

The images work, but the scene files don't yet.

    Thorsten

Post a reply to this message

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