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

Hey,

Doh! This should be fixed now.

I apologise that there have been so many problems with the page. PHP I can
do. Simple HTML? Apparently not ;)


John

Post a reply to this message

Hey,

>   I can agree that they are not like the real thing, but I can't agree
> about the documentation. What the documentation states is what POV-Ray
> does. Exactly. And you know it, isn't? Why you stopped quoting section
> 6.5.7.5 when it comes to explain just these things you claim it does not
> explain?

To be totally honest, I stopped reading the docs when I got to the point
about area lights being a grid of point lights. Then I went off to Warp's
site to confirm that he said the same thing (it had been a few days since I
had read it). And I launched off into my tests. I have since had explained
to me about how the area_lights in Povray only affect the shadows, and have
found the bit in the docs that cover it - embarrassingly, right after where
I
stopped reading ;) So that kind of nullifies Test One in my article.

However, I still think that it's kind of hacky for the arealights to behave
in one way in relation to their shadows, and another way for their
illumination. Shadows are only a side effect of the absence of light; the
soft shadows should be a side effect of the fact that an arealights
illumination doesn't come from a point. Povray totally breaks this
conception with what I consider to be a hacky lightsource. I personally
would much prefer to spend whatever extra time would be needed for a more
accurate source of *illumination* that also happened to give soft shadows by
their very nature.

>   As others pointed, we all have tried this sooner or later.. and sonner
or
> later we all realized it is too slow.

Well, actually, when I was testing my truAreaLight when I was developing it,
I did a 640x480 rendering of a Cornell box with a concrete texture. In it
were two of my truAreaLights, each with 300 point lights (600 total), that
mesh of the warrioress Athena that has been doing the rounds (I think it was
made by a company called De Esponsa or something) which is an 11mb include,
so I can only guess it contains *a lot* of triangles, as well as a shiny red
sphere. Both the sphere and the Athena model had variably reflective
surfaces, and both occupied quite a bit of image-space, so a good bit of the
render time was on them. Added to that the fact that the scene was rendered
with fairly high quality radiosity (count 200, error_bound 0.5,
recursion_limit 3, low_error_factor .5, minimum_reuse 0) and command line
settings of "+r9 +a0.0" meant a fairly heavy-duty render. On a 600mhz P3,
which is hardly a top of the line PC these days, which was being used for
other tasks as well, the scene rendered in 61 hours 18 minutes   8.0 seconds
(including parse time); just over two and a half days. Personally I think
that was quite fast, considering the circumstances.

Now, maybe you think that's really slow. However, considering the quality of
the final image (which I can post with stats if you want), I think that was
fairly quick. Maybe processor speeds have just caught up with the method?


John

Post a reply to this message

Hi,

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

As I've been coming to understand over the last 24 hours, the point of
area_lights in Povray, and seeming the reason they were included as they
are, is simply to cast soft-edged shadows. And it's obvious as to why we'd
want soft edged shadows available as a feature - they are all around us in
the real world, there are very few lightsources that I can think of that
could even remotely be considered point light sources.

However, I think they way that Povray goes about creating soft-edged shadows
is *all wrong*. It would appear that the area_lights were written purely for
the shadows, and let the illumination be damned. However, I find this
incredibly counterintuitive. Shadows only exist because of an absence of
light; shadows are only a secondary effect, not the primary one. In my
opinion, it is the special type of *illumination* that should set
area_lights apart from other lights in Povray, with the fact that they cast
illumination from their entire surface area (Povray's implementation of
area_lights doesn't bother with this - they only affect the diffuse and
other aspects of the scene as if they were a point source). The soft edged
shadows should only be a naturally occuring secondary consequence of the
settings that the user applies to the size of the area_light lightsource.
Povray at the moment works mostly like the reverse of this - the user sets
up settings to get the shadows to look and behave a certain way, and the
illumination is only a secondary concern. That is what I think makes
Povray's area_lights a cheap hack.

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

Have a look at my reply to Jaime Vives Piqueres above - I describe (in too
much detail to repost here) a very intensive test scene I did with my point
light array macro, with fairly high radiosity settings, very high quality
antialiasing on an average machine that I was using during the day, and the
scene finished fairly quickly, much quicker then I would have expected,
considering what Warp said on his webpage about how slow the "array of point
lights" method was.

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

Again, have a look at my reply to Ben Birdsey near the top of the thread, I
posted the settings used for the arealight in that test. Also, the source
code download for my article should be fixed now if you want to download the
whole scene yourself.


John

Post a reply to this message

Hi,

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

I know, I just called it truAreaLight as a name. I realise that a "true"
area light is a very complex thing to simulate in a raytracer, and that
you'd probably have to implement some kind of Monte Carlo engine to do
forwards-raytracing or something equally nasty. My grid of point lights was
just an implementation of what I thought the Povray area light was under the
hood.

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

As I have subsequently found out, and that nullifies Test One in my article.
I still don't think it's right, but it at least explains why I got the
results I did.

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

As I just said in my reply to Jamie, "Shadows are only a side effect of the
absence of light; the soft shadows should be a side effect of the fact that
an arealights illumination doesn't come from a point". I believe that the
very fact that there is a disparity between the illumination model that
Povray uses for its arealight and the model it uses to calculate shadows for
the area light totallys break any kind of intuitive concept about how
illumination works. Povray arealights were designed to give soft shadows; I
believe that the illumination that arealights give off was only a distant
secondary concern. That is why I think that Povray arealights are a cheap
hack; it is the special *illumination* property of an arealight that should
be what makes it different from point light sources - the soft shadows
should just be a natural side effect of the used defined properties for the
arealight's source.

I consider the fact that Povray works the exact opposite way to this, in
which the user sets up properties to affect how the *shadows* work (seeing
as no setting apart from colour and falloff and so on will affect the
illumination), to be a defect. Therefore, seeing as adaptive is just an
extra step in this process, it is part of the defect. Do you understand what
I mean?

I'm sorry if I sound so negative, but I just think that arealights in Povray
are just plain *wrong*. It would be great if they could be updated for 4.0
;)


John

Post a reply to this message

Hey Greg,

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

I havn't tried rendering them seperately yet - I'll do some renders this
weekend when I have some free time, and I'll post the results here.


John

Post a reply to this message