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