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.

You can read the article here:
http://www.redbrick.dcu.ie/~element/areaLights/

It's a bit image heavy, so watch your connection ;)

Let me know what you think, either by replying here or posting to my comment
system (the link is at the bottom of the article).

All the best,


John Mellerick
------------------------------------
http://www.redbrick.dcu.ie/~element/
ele### [at] redbrickdcuie

Post a reply to this message

John -

It seems that you have made a mistake in comparing the POVs area light
to your truAreaLight.  To compare the two in your first example, you
should have declared the area light as

light_source {
    <?, ?, ?>
    color ?
    area_light <?, ?, ?>, <?, ?, ?>, 8, 16
}

This should mimic the density of light sources that you're using in your
tru implementation of area lights.

However, it looks like you actually used 

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.

Why don't you re-render the images with the 8, 16 settings and see if
there's a difference??  I'd be interested to see the results.

- Ben

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.
> 
> You can read the article here:
> http://www.redbrick.dcu.ie/~element/areaLights/
> 
> [...]

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.

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

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.
- 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...
- try some other raytracers for comparison and see if they supply more
realistic functions.
- use POV-Ray more intensively to get a feeling for the necessities when
really using the program and not just doing theoretical tests.

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

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

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


-- 
http://objects.povworld.org - the POV-Ray Objects Collection

Post a reply to this message

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

> Let me know what you think, either by replying here or posting to my comment
> system (the link is at the bottom of the article).

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.  While different shapes for area light sources are nice, that is the
only thing your SDL code provides.

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

    Thorsten

Post a reply to this message

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