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

...because now I'm repeating myself.

John Mellerick wrote:
> 
> However, I think they way that Povray goes about creating soft-edged shadows
> is *all wrong*.

Yes, those bastards! They added a feature to the software to create 
soft-edged shadows without the massive overhead of massive point light 
arrays! How dare they?

</sarcasm>

No one's holding a gun to your head and forcing you to use area lights. 
If you dislike them that much, don't use them. You have a perfectly 
servicible light array generator.

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

Your test scenes were LAUGHABLY SIMPLE.. sufficient to demonstrate a 
technique, but not a good demonstration of the effects of light arrays 
on rendering time for realistically complex scenes. The fact that you 
seem to think otherwise shows your inexperience and ignorance.

-Xplo

Post a reply to this message

Pandora wrote:

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

Studying a bit more the source (mind you, just a 10 min inspection, while I
was supposed to work), the game seems to be:
1 - Lighting code shoots a ray toward a light (from point of intersection to
light origin)
2 - If the light is an area light, additional shadow rays are calculated, to
estimate blocking of light
3 - Lighting calculation (i.e. diffuse and specular) are done using the
first ray only

This means that:
Light intensity is modulated according to a (possibly) biased estimate of
blocking
Diffuse and specular components are calculated as if the light is a point
light, hence the artifacts shown in the pictures.

To obtain a more correct area light the angles used in lighting calculation
should vary. More precisely, the elements needed to calculate a point
apparent emission are not limited to the radiance from a light source, but
include also the angle of incidence.
The povray code for *direct* lighting appears to neglect this, which proves
to be a good approximation only for distant sources.

The problem is that simply plugging the code to sample more than a single
ray leads to multiple evaluations of texturing components, which could be
avoided in a more specific code.

Montecarlo ray-tracers are very accurate, but slow, because (a) they shoot a
single ray toward light sources, both for shadow and lighting, and
therefore require *many* samples per pixel, or (b) they shoot a bunch of
rays, repeating texture evaluations per each sample ray.

A possible optimization could be to calculate once per intersection the
texturing components which are indipendent of incoming light direction, but
this rules out optimization of BRDF (may be or not be true...it seems to me
but I have to check this more thorougly...there's a discussion of this
problem in some ancient paper from SIGGRAPH, iirc)

povray area lights are perfectly adequate when used in conjunction with
radiosity and photons, which utilize a different approximations of the
illumination integral.

However, to obtain efficient "true" area light, I suspect we would have to
rewrite the whole lighting code. In the meanwhile, I'll try (this sunday,
if time permits) to plug in the code described in Graphic Gems III
(http://www.acm.org/tog/GraphicsGems/).

I think I'll try both styles (single-sample and multi). Inituitively, they
should yield the same times (roughly), but....

If anyone is willing to discuss this more or to help me, feel free to write
me directly on ale### [at] alphacit

Alex

------------------------------------------------------
Shadow softly and carry a big light, you'll render far
------------------------------------------------------

Post a reply to this message

Xplo Eristotle wrote:
>....because now I'm repeating myself.
>
>John Mellerick wrote:
>>
>> However, I think they way that Povray goes about creating soft-edged shadows
>> is *all wrong*.
>
>Yes, those bastards! They added a feature to the software to create
>soft-edged shadows without the massive overhead of massive point light
>arrays! How dare they?
>
></sarcasm>
>
>No one's holding a gun to your head and forcing you to use area lights.
>If you dislike them that much, don't use them. You have a perfectly
>servicible light array generator.
>
>> 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...
>
>Your test scenes were LAUGHABLY SIMPLE.. sufficient to demonstrate a
>technique, but not a good demonstration of the effects of light arrays
>on rendering time for realistically complex scenes. The fact that you
>seem to think otherwise shows your inexperience and ignorance.
>
>-Xplo
>


Oh! Oh! Calma!

Everybody, let's take a big breath and stop sounding so bitter and harsh.

I only saw discussions get so heated in political forums (tho, sports forums
could be candidates to that, at least in Italy).

These newsgroups at times seem a lesson from Ruffled Feathers 101....

Alex

Post a reply to this message

"Alex" <ale### [at] alphacit> wrote in message
news:web.3d6f2ac71c92063515e7f0160@news.povray.org...
>
> Oh! Oh! Calma!
>
> Everybody, let's take a big breath and stop sounding so bitter and harsh.
>
> I only saw discussions get so heated in political forums (tho, sports forums
> could be candidates to that, at least in Italy).
>
> These newsgroups at times seem a lesson from Ruffled Feathers 101....
>

But he criticised POV! That's fighting talk where I come from...

Seriously, John sort of asked for it - even he admits he didn't read the full
documentation.

What seems a shame is that, written from another perspective - e.g. "Why area
lights are different from a grid of point lights" - would have been a helpful
(and non-contentious) resource....

Post a reply to this message

>
>But he criticised POV! That's fighting talk where I come from...
>

Ruffled Feathers 101: Lesson Two.....

fighting talk? What, we're in a Jihad?

Seriously, tho, POV has a *LOT* of shortcomings, but, hey!, it's free,
developed on a voluntary base, comes with source...

IT DOESN'T HAVE SUBSURFACE-SCATTERING!!! IT DOESN'T SUPPORT THE METROPOLIS
LIGHT TRANSPORT!! IT'S NOT SPECTRAL BASED!!! IT DOESN'T DO SKYDOMES!!!
I WANT BSSRDF! I WANT METROPOLIS! I WANT SPECTRAL! I WANT REAL MOTION BLUR!
I WANT PHISICALLY CORRECT DYNAMICS! CLOTH! FLUIDS!

Now, *that* is fighting talk :)
Alex

Post a reply to this message