hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> ...
> One thing that I did was have it generate ALL the possible permutations of light
> source and object, and I would suggest that part of the distribution be a scene
> that renders all the permutations.  That ought to put an end to any questions
> about how povray actually operates.

yes agree, a simple, "good" .pov/.ini combo which generates a corresponding set
of images would be very useful to have.  (if we had one "in hand", we could
start "badgering" Chris :-))


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
>
> How do you fancy "having a go" at turning the "Perfect Mirror" thread into
> a "FAQ" item ?  (or a draft for an added "Tip" based on your observations ?)
>

12/18/25

Sorry for the delay in responding...real-life and holiday chores took over.

Perhaps a combination of FAQ and B.E.'s all-inclusive test-scene idea would be
the best approach to a better understanding of the current photons behavior; I
will try to put together a draft FAQ (or addition to 'photon tips and tricks')
after the New Year...once I get a clear scenario in my head of how best to
approach it.

Meanwhile, I continued testing in v3.8 beta 1-- and came across some
*really* odd behavior of photons interacting with objects (which proved to be
TEMPORARY, I am happy to say.)

Essentially, the parse time for my earlier test scene here wildly increased-- by
about 15X-- when I simply added an additional box object to the scene, on the
left side of my  light_source, and with no photons block in that object (thus
as a photon 'collector', the default behavior.) But such a gigantic parse-time
increase  made no sense whatsoever, and  I spent the better part of *three days*
trying to understand why it was occurring and how to eliminate it, running test
after test. (Adding a photon block with 'collect OFF' solved it..but that should
not have made such a big difference.)

Near the end of this testing process, I decided to shut down v3.8 and run the
scene in v3.7 instead, to compare results: NO odd behavior there, which was a
good sign. So I brought it back to 3.8... and the problem had suddenly
DISAPPEARED! I could not even reproduce it by fiddling with photon settings.

(At some point prior to my v3.7 test, I *might* have shut down my computer--
which I do on occasion, when I know I will be away from it for hours..but I
don't remember if or when.)  So did shutting it down 'fix' something in the
Windows registry? And/or did running 3.7 correct some temporary glitch in the
3.8 code? Or did Microsoft sneak-in a 'silent' Windows update while I wasn't
looking, breaking (OR fixing) something?

Or was it just 'gremlins and goblins' playing with me?? I think that's the
likely answer.  :-o

So my new and painfully-learned philosophy concerning the current 3.8 betas (1,
and most likely 2 as well) is this:

When unexpected  and unexplainable scene behavior suddenly occurs that makes no
sense, first RESTART the computer (or just POV-ray?) and test again!

Now that all is well, I continue testing photons...   :-)

Post a reply to this message

hi,

"Kenneth" <kdw### [at] gmailcom> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > How do you fancy "having a go" at turning the "Perfect Mirror" thread into
> > a "FAQ" item ?  (or a draft for an added "Tip" based on your observations ?)
>
> Sorry for the delay in responding...real-life and holiday chores took over.
> Perhaps a combination of FAQ and B.E.'s all-inclusive test-scene idea would be
> the best approach to a better understanding of the current photons behavior; I
> will try to put together a draft FAQ (or addition to 'photon tips and tricks')
> after the New Year...once I get a clear scenario in my head of how best to
> approach it.

thank you very much.  on "second thought" :-), or perhaps as a wiki "How To"
item ?  (more "elbow room")


> Meanwhile, I continued testing in v3.8 beta 1-- and came across some
> *really* odd behavior of photons interacting with objects (which proved to be
> TEMPORARY, I am happy to say.)
> ...
> Near the end of this testing process, I decided to shut down v3.8 and run the
> scene in v3.7 instead, to compare results: NO odd behavior there, which was a
> good sign. So I brought it back to 3.8... and the problem had suddenly
> DISAPPEARED! I could not even reproduce it by fiddling with photon settings.
> ...
> Or was it just 'gremlins and goblins' playing with me?? I think that's the
> likely answer.  :-o

agree, they (machines) can have "a mind of their own", it seems at times.


regards, jr.

Post a reply to this message

Alain Martel <kua### [at] videotronca> wrote:
> >
> > BTW:
> > I think that the docs'  'target' default of 1.0 [the numerical multiplier]
> > also needs a small clarification (...) The 1.0 value also works when
> > 'count' is used [instead of 'spacing'] but incrementally changing the float
> > value has no effect.
> >
>
> The value after target has an effect on the density of the photons for
> the target object.
>
> Even when using count, target 0.5 should cause that object to receive 4
> times as many photons compared to target 1/on/true. When using count,
> this only has an effect when there are at least two target objects.
>

My original tests used only one 'target' object, so I tested again using two,
and you're right: A changed multiplier value does work now (for both targets),
even when 'count' is used in the global photons block. This little 'switch' in
behavior is undocumented, as far as I can tell.

However: Given two (or more) 'target' objects in a scene, the photon behavior
for each can be unexpectedly different, depending on whether 'count' vs.
'spacing' is used:

A) With 'count':
     If two targets both use a value of 1.0 (or simply 'on'), the 'count' of
     photons is *split up evenly* between the two; each target gets half the
     count. But if one target uses 1.0 and the other 0.2, the 0.2 target *robs*
     photons from the 1.0 target, with the resulting visual caustic effect on
     surfaces looking different from each one. But the total photon
    'count' remains the same.

B) With 'spacing':
     Each target is *independent*-- they each respond to their individual
     spacing-multiplier values, no 'robbing' of photons...which means the total
     NUMBER of photons can increase, to suit the situation. This would
     produce a more logical and visually realistic result than 'count'.

Some of these behavioral differences are undocumented as well, or at least not
clearly.

Post a reply to this message

On 1/2/26 20:44, Kenneth wrote:
> My original tests used only one 'target' object, so I tested again using two,
> and you're right: A changed multiplier value does work now (for both targets),
> even when 'count' is used in the global photons block. This little 'switch' in
> behavior is undocumented, as far as I can tell.
> 
> However: Given two (or more) 'target' objects in a scene, the photon behavior
> for each can be unexpectedly different, depending on whether 'count' vs.
> 'spacing' is used:
> 
> A) With 'count':
>       If two targets both use a value of 1.0 (or simply 'on'), the 'count' of
>       photons is*split up evenly* between the two; each target gets half the
>       count. But if one target uses 1.0 and the other 0.2, the 0.2 target*robs*
>       photons from the 1.0 target, with the resulting visual caustic effect on
>       surfaces looking different from each one. But the total photon
>      'count' remains the same.
> 
> B) With 'spacing':
>       Each target is*independent*-- they each respond to their individual
>       spacing-multiplier values, no 'robbing' of photons...which means the total
>       NUMBER of photons can increase, to suit the situation. This would
>       produce a more logical and visually realistic result than 'count'.

Re: (A) Interesting & news to me. I thought the count applied 
independently to each target. Thanks for digging into the behavior!

Bill P.

Post a reply to this message

Le 2026-01-03 à 11:15, William F Pokorny a écrit :
> On 1/2/26 20:44, Kenneth wrote:
>> My original tests used only one 'target' object, so I tested again 
>> using two,
>> and you're right: A changed multiplier value does work now (for both 
>> targets),
>> even when 'count' is used in the global photons block. This little 
>> 'switch' in
>> behavior is undocumented, as far as I can tell.
>>
>> However: Given two (or more) 'target' objects in a scene, the photon 
>> behavior
>> for each can be unexpectedly different, depending on whether 'count' vs.
>> 'spacing' is used:
>>
>> A) With 'count':
>>       If two targets both use a value of 1.0 (or simply 'on'), the 
>> 'count' of
>>       photons is*split up evenly* between the two; each target gets 
>> half the
>>       count. But if one target uses 1.0 and the other 0.2, the 0.2 
>> target*robs*
>>       photons from the 1.0 target, with the resulting visual caustic 
>> effect on
>>       surfaces looking different from each one. But the total photon
>>      'count' remains the same.
>>
>> B) With 'spacing':
>>       Each target is*independent*-- they each respond to their individual
>>       spacing-multiplier values, no 'robbing' of photons...which means 
>> the total
>>       NUMBER of photons can increase, to suit the situation. This would
>>       produce a more logical and visually realistic result than 'count'.
> 
> Re: (A) Interesting & news to me. I thought the count applied 
> independently to each target. Thanks for digging into the behavior!
> 
> Bill P.

When you use count, the count value is the total number of photons to be 
shot, distributed between all targets and all lights. The area, or 
angular size, of the targets also play a role. A big target will tend to 
get more photons than a small target next to it.

The photon shooting always try to keep the photon density constant 
between all targets.

count 1 000 000
two lights and two targets of roughly the same size, and each light will 
shoot about 250 000 photons at each target.

Have three targets, and you shoot about 166 666 photons per light at 
each target.

Post a reply to this message

On 1/3/26 13:41, Alain Martel wrote:
> When you use count, the count value is the total number of photons to be 
> shot, distributed between all targets and all lights. The area, or 
> angular size, of the targets also play a role. A big target will tend to 
> get more photons than a small target next to it.
> 
> The photon shooting always try to keep the photon density constant 
> between all targets.
> 
> count 1 000 000
> two lights and two targets of roughly the same size, and each light will 
> shoot about 250 000 photons at each target.
> 
> Have three targets, and you shoot about 166 666 photons per light at 
> each target.

Thank you, Alain. More I didn't know! :-)

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 1/2/26 20:44, Kenneth wrote:
> >
> > However: Given two (or more) 'target' objects in a scene, the photon behavior
> > for each can be unexpectedly different, depending on whether 'count' vs.
> > 'spacing' is used:
> >
> > A) With 'count':
> > [snip]
> >
> > B) With 'spacing':
> > [snip]

>
> Re: (A) Interesting & news to me. I thought the count applied
> independently to each target. Thanks for digging into the behavior!
>

It was also a new discovery for me...as were Alain's comments when using
*multiple* lights and photon targets. In most of my old photon scenes, I used
'count' out of simplicity-- totally unaware of its various 'if/then/else'
results.

I'm beginning to think that 'count' should be deprecated going forward(!), since
'spacing' easily produces **expected** results, especially with the useful
numerical multiplier for a 'target'.

-------------
BTW (and a bit off-topic):
Just out of curiosity, I tried adding the typical no_shadow and no_image flags
to my photon 'target' object, to see what would happen...and either flag
*eliminated* the caustics on my 'collector' object's surface (in both v3.7 and
3.8). That does not *seem* to be an expected result to me-- based on what those
flags are usually supposed to do-- but I'm still trying to wrap my brain around
the logic it. IF those flags are operating correctly in this case, are photons
'shadow-based' in some way? That is, should photon caustics be regarded as
light/SHADOW effects?

But what definitely seems strange is that adding no_shadow to my *collector*
object eliminated the caustics too.  My understanding of
no_shadow is that it's only supposed to eliminate shadows that are cast *from*
an object (my collector in this case) onto other objects.

Whether or not this is the designed/expected behavior of the two flags when
photons are used, the practical result is that those objects will exhibit
unexpected absence-of-photon effects in a scene (given that 'collect ON' is the
default for all objects when a global photons block is present).  And the use of
no_shadow and no_image for scene 'workarounds' will not work without eliminating
the caustics as well.

Post a reply to this message

Le 2026-01-05 à 09:46, Kenneth a écrit :
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> On 1/2/26 20:44, Kenneth wrote:
>>>
>>> However: Given two (or more) 'target' objects in a scene, the photon behavior
>>> for each can be unexpectedly different, depending on whether 'count' vs.
>>> 'spacing' is used:
>>>
>>> A) With 'count':
>>> [snip]
>>>
>>> B) With 'spacing':
>>> [snip]
> 
>>
>> Re: (A) Interesting & news to me. I thought the count applied
>> independently to each target. Thanks for digging into the behavior!
>>
> 
> It was also a new discovery for me...as were Alain's comments when using
> *multiple* lights and photon targets. In most of my old photon scenes, I used
> 'count' out of simplicity-- totally unaware of its various 'if/then/else'
> results.
> 
> I'm beginning to think that 'count' should be deprecated going forward(!), since
> 'spacing' easily produces **expected** results, especially with the useful
> numerical multiplier for a 'target'.
> 
> -------------
> BTW (and a bit off-topic):
> Just out of curiosity, I tried adding the typical no_shadow and no_image flags
> to my photon 'target' object, to see what would happen...and either flag
> *eliminated* the caustics on my 'collector' object's surface (in both v3.7 and
> 3.8). That does not *seem* to be an expected result to me-- based on what those
> flags are usually supposed to do-- but I'm still trying to wrap my brain around
> the logic it. IF those flags are operating correctly in this case, are photons
> 'shadow-based' in some way? That is, should photon caustics be regarded as
> light/SHADOW effects?
> 
> But what definitely seems strange is that adding no_shadow to my *collector*
> object eliminated the caustics too.  My understanding of
> no_shadow is that it's only supposed to eliminate shadows that are cast *from*
> an object (my collector in this case) onto other objects.
> 
> Whether or not this is the designed/expected behavior of the two flags when
> photons are used, the practical result is that those objects will exhibit
> unexpected absence-of-photon effects in a scene (given that 'collect ON' is the
> default for all objects when a global photons block is present).  And the use of
> no_shadow and no_image for scene 'workarounds' will not work without eliminating
> the caustics as well.
> 
> 
> 
> 
Then, we must remember that shadowless lights never case photons.

 From your test, it seems that disabling shadows also disable photons.

Post a reply to this message

On 2026-01-05 10:46, Kenneth wrote:
> 
> It was also a new discovery for me...as were Alain's comments when using
> *multiple* lights and photon targets. In most of my old photon scenes, I used
> 'count' out of simplicity-- totally unaware of its various 'if/then/else'
> results.
> 
> I'm beginning to think that 'count' should be deprecated going forward(!), since
> 'spacing' easily produces **expected** results, especially with the useful
> numerical multiplier for a 'target'.

The last time I used 'count' was around 20 years ago, back when I was
using a 1996 vintage laptop.  When I bought a new laptop in 2006, I
found new freedom with lots of RAM, and have been using only 'spacing'
for new scenes ever since.

Post a reply to this message