Wow, thank you!  That's incredibly helpful, all of you.  Can't thank you enough,
I actually understand it now.  Again, thank you all so much.

Post a reply to this message

On 2023-01-25 12:22 (-4), Alain Martel wrote:
> 
> Any sampling array size between those values will be silently increased
> to the following size of the list. A 4 x 4 adaptive is really 5 x 5, 6 x
> 6 is promoted to 9 x 9 and 10 x 10 become 17 x 17.

Not according to my tests.  The attached images were rendered with
area_illumination to reveal the internal array of lights.

Post a reply to this message

Attachments:
Download 'circular_light-20230126.jpg' (72 KB)

Preview of image 'circular_light-20230126.jpg'

On 1/26/23 14:40, Cousin Ricky wrote:
> On 2023-01-25 12:22 (-4), Alain Martel wrote:
>>
>> Any sampling array size between those values will be silently increased
>> to the following size of the list. A 4 x 4 adaptive is really 5 x 5, 6 x
>> 6 is promoted to 9 x 9 and 10 x 10 become 17 x 17.
> 
> Not according to my tests.  The attached images were rendered with
> area_illumination to reveal the internal array of lights.

Probable complications - as best my glitchy memory serves...  :-)

area_illumination essentially walks through each of the area light 
positions - more or less - as originally specified; tracing each are 
position in turn and coming up with a final, weight adjusted, result. 
Any adaptive bits (for shadow rays only) and circular bits run at each 
of the area light's effectively moving 'center' positions with 
area_illumination on.

The adaptive mechanism being discussed in this thread comes into play 
only during shadow ray tracing.

The circular option itself introduces some bias in the counts and 
position of the area lights as the rectangular specification gets mapped 
to a circular one.

--- Other misc.

There is an open github issue on the circular option occasionally 
introducing visible bias in lighting results.

https://github.com/POV-Ray/povray/issues/222

There is too this open github issue related specifically to 
area_illumination and adaptive/circular shadow calculations not playing 
well together:

https://github.com/POV-Ray/povray/issues/224

I believe these github issues still unsorted in any available POV-Ray or 
branch/patch release.

Bill P.

Post a reply to this message

Le 2023-01-26 à 14:40, Cousin Ricky a écrit :
> On 2023-01-25 12:22 (-4), Alain Martel wrote:
>>
>> Any sampling array size between those values will be silently increased
>> to the following size of the list. A 4 x 4 adaptive is really 5 x 5, 6 x
>> 6 is promoted to 9 x 9 and 10 x 10 become 17 x 17.
> 
> Not according to my tests.  The attached images were rendered with
> area_illumination to reveal the internal array of lights.

So, shining an area_light with adaptive AND area_illumination thru a 
small opening changes how adaptive work. Interesting.

Did you try without area_illumination ?

Post a reply to this message

Cousin Ricky <ric### [at] yahoocom> wrote:
> On 2023-01-25 12:22 (-4), Alain Martel wrote:
> >
> > Any sampling array size between those values will be silently increased
> > to the following size of the list. A 4 x 4 adaptive is really 5 x 5, 6 x
> > 6 is promoted to 9 x 9 and 10 x 10 become 17 x 17.
>
> Not according to my tests.  The attached images were rendered with
> area_illumination to reveal the internal array of lights.

That's a cool render - you always come up with some of the most interesting
ideas, techniques, and methods.

Did you just make an area light that's parallel to the checkered plane and then
point the camera down to look through it and so see the reflection of the light?

Post a reply to this message

On 2023-01-27 10:24 (-4), Alain Martel wrote:
> Le 2023-01-26 à 14:40, Cousin Ricky a écrit :
>> On 2023-01-25 12:22 (-4), Alain Martel wrote:
>>>
>>> Any sampling array size between those values will be silently increased
>>> to the following size of the list. A 4 x 4 adaptive is really 5 x 5, 6 x
>>> 6 is promoted to 9 x 9 and 10 x 10 become 17 x 17.
>>
>> Not according to my tests.  The attached images were rendered with
>> area_illumination to reveal the internal array of lights.
> 
> So, shining an area_light with adaptive AND area_illumination thru a
> small opening changes how adaptive work. Interesting.

There is no change in behavior.  The documentation reads:

  "For example area_light x,y,4,4 specifies a 4 by 4 array of lights. If
  you specify adaptive 3 it would mean that you should start with a 9 by
  9 array. In this case no adaptive sampling is done. The 4 by 4 array
  is used."

There is no mention of any increase in the array size, with or without
area_illumination.  Plus, I examined the source code, and I cannot find
anyplace where the array size is changed after being parsed.

> Did you try without area_illumination ?

The experiment does not work without area_illumination.  The scene file
uses an area light very close to the surface, and no shadows are involved.

Post a reply to this message

On 2023-01-28 11:57 (-4), Bald Eagle wrote:
> 
> Did you just make an area light that's parallel to the checkered plane and then
> point the camera down to look through it and so see the reflection of the light?

Yes.

Post a reply to this message

Le 2023-01-28 à 11:59, Cousin Ricky a écrit :
> On 2023-01-27 10:24 (-4), Alain Martel wrote:
>> Le 2023-01-26 à 14:40, Cousin Ricky a écrit :
>>> On 2023-01-25 12:22 (-4), Alain Martel wrote:
>>>>
>>>> Any sampling array size between those values will be silently increased
>>>> to the following size of the list. A 4 x 4 adaptive is really 5 x 5, 6 x
>>>> 6 is promoted to 9 x 9 and 10 x 10 become 17 x 17.
>>>
>>> Not according to my tests.  The attached images were rendered with
>>> area_illumination to reveal the internal array of lights.
>>
>> So, shining an area_light with adaptive AND area_illumination thru a
>> small opening changes how adaptive work. Interesting.
> 
> There is no change in behavior.  The documentation reads:
> 
>    "For example area_light x,y,4,4 specifies a 4 by 4 array of lights. If
>    you specify adaptive 3 it would mean that you should start with a 9 by
>    9 array. In this case no adaptive sampling is done. The 4 by 4 array
>    is used."
> 
> There is no mention of any increase in the array size, with or without
> area_illumination.  Plus, I examined the source code, and I cannot find
> anyplace where the array size is changed after being parsed.
> 
>> Did you try without area_illumination ?
> 
> The experiment does not work without area_illumination.  The scene file
> uses an area light very close to the surface, and no shadows are involved.
> 
I've done a similar test. In that test, I did not use adaptive nor 
aera_illumination.
In my test, all the spots are sharp, not fuzzy as in your test.

Post a reply to this message

Cousin Ricky <ric### [at] yahoocom> wrote:

> Yes.

Wow.  Much laconic.  Such taciturn.  So not verbose.  Very wow!


+ 1000 POV points

Post a reply to this message

On 1/28/23 12:21, Alain Martel wrote:
> Le 2023-01-28 à 11:59, Cousin Ricky a écrit :
>> On 2023-01-27 10:24 (-4), Alain Martel wrote:
>>> Le 2023-01-26 à 14:40, Cousin Ricky a écrit :
>>>> On 2023-01-25 12:22 (-4), Alain Martel wrote:
>>>>>
>>>>> Any sampling array size between those values will be silently 
>>>>> increased
>>>>> to the following size of the list. A 4 x 4 adaptive is really 5 x 
>>>>> 5, 6 x
>>>>> 6 is promoted to 9 x 9 and 10 x 10 become 17 x 17.
>>>>
>>>> Not according to my tests.  The attached images were rendered with
>>>> area_illumination to reveal the internal array of lights.
>>>
>>> So, shining an area_light with adaptive AND area_illumination thru a
>>> small opening changes how adaptive work. Interesting.
>>
>> There is no change in behavior.  The documentation reads:
>>
>>    "For example area_light x,y,4,4 specifies a 4 by 4 array of lights. If
>>    you specify adaptive 3 it would mean that you should start with a 9 by
>>    9 array. In this case no adaptive sampling is done. The 4 by 4 array
>>    is used."
>>
>> There is no mention of any increase in the array size, with or without
>> area_illumination.  Plus, I examined the source code, and I cannot find
>> anyplace where the array size is changed after being parsed.
>>
>>> Did you try without area_illumination ?
>>
>> The experiment does not work without area_illumination.  The scene file
>> uses an area light very close to the surface, and no shadows are 
>> involved.
>>
> I've done a similar test. In that test, I did not use adaptive nor 
> aera_illumination.
> In my test, all the spots are sharp, not fuzzy as in your test.

Cousin Ricky's set up doesn't cast shadows.

I believe the amount of fuzziness likely comes from the angle of the 
light relative to the plane in Cousin Ricky's set up where the area 
light is very close to the surface of the plane. You get the same sort 
of fuzzy / fading result with a single point source very close to a surface.

How sharp the result depends on stuff... Stuff like the light's fade 
power / distance and the brilliance setting of the finish. An 
interesting experiment would be to add a finish { brilliance 0.1 } to 
the plane and see what happens in a set up like CR's.

---

As for the sampling array sizes... The current actual behavior is 
complicated. Results look to get mapped back to a fixed 'lightGrid' 
based upon the original size specification, but, the way the testing is 
done when deciding whether to recursively call in 
traceAreaLightSubsetShadowRay and whether sub-area positions are already 
calculated will often enough lead to extra work(a). So counts depend on 
what you are counting and the particulars of the scene.

Bill P.

(a) - Our current adaptive set up is used even when we might want to use 
all the area (size1 x size2) sub positions(b). In other words, when not 
using an 'adaptive n' specification(c) or using a relatively high 
minimum adaptive depth, the recursive calls 'could' be avoided 
altogether for better performance. Further, the on the fly adaptive 
calculations for the recursive set up involve floor() and ceil() which 
are expensive. I suspect there's room for some optimization...

(b) - Like any adaptive algorithm, there will be situations where the 
adaptive test and exit stops too early. This the reason we can force a 
minimum number of area sub-positions be used before any adaptive 
consideration. Where we must force a high minimum to avoid artefacts, I 
suspect there is not much (any?) visual value left in the 'adaptive' 
part of the area light feature; A purely 'flat' code approach would 
likely be faster in such cases... ;-)

(c) Internally the adaptive / depth value is set to 100 when no area 
light, adaptive value is used. In such case we are still using the 
recursive, adaptive algorithm to get a 'flat' area light result.

Post a reply to this message