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

[Sorry for my silence here, I got side-tracked with just having some fun with
other POV-ray scenes. But I continued testing photon behavior...a tedious
process comparing one feature against another in refraction vs. reflection
set-ups, and in both v3.7 vs 3.8 beta 1...then trying to make sense of it
all...]

>
> [Kenneth wrote]
> 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...
>
> But what definitely seems strange is that adding no_shadow to my *collector*
> object eliminated the caustics too [on it own surface].

With further testing, the no_shadow behavior does make sense now, at least
regarding photon 'collectors'. In my original test scene, I neglected to add a
2nd collector behind the 1st one, to see the effect of this flag. Adding it to
the 1st collector makes it 'transparent' to the PHOTON-light effects, so that
they 'pass through' and show up on the 2nd collector surface instead. (And
the docs do say that "no_shadow automatically turns on pass_through"... which I
neglected to read.) The only 'seemingly' weird thing is that this behavior is
unlike *direct* light from the light source, which still shows up on the 1st
collector as expected-- whereas the photon caustics do not. It's as if the
caustics are 'a different and separate kind of light'.

But NO_IMAGE for a 'collector' might not be working as intended: For REFRACTION
caustics, the object does become invisible, but the photon light will pass
through it to a 2nd collector-- identical to no_shadow -- which seems to be
different as to how no_image works in other circumstances: that is, the object
still exists but only its *appearance* is turned off (and *should* block the
photon light). So no_image apparently invokes no_shadow as well.

But for REFLECTION caustics, no_image works 'as expected'-- the photon light
*is* blocked.  So currently, no shadow works in a different way for reflected
vs. refracted caustics.

-----
After testing this stuff, I wanted to see how the *actual*
photons{pass_through on/off}  feature worked, as I have never used it before.

The way I understand the v3.8 docs at '3.4.3.4.4 Shooting Photons at an
Object', pass_through ON can be applied to an object that sits *between* a
photon-enabled light_source and a photon 'target'-- so that the 'photon light'
can go through that intervening object as if it was not there, instead of being
blocked by it.

But in v 3.7 and the current 3.8 betas, this does not work for a totally opaque
object; it needs *some* transparency (either f or t) which is not mentioned in
the docs...although, the limited notes there seem to imply a particular photon
*refraction* set-up with a transparent media container and photon-enabled
media(?)....implying transparency for that container object, so that
pass_through will let the photon light bypass the container and interact with
the media itself. But there is no mention of opacity...so I guess we are
supposed to assume that the intervening object needs to have at least some
transparency.

The only way to get photon-enabled light to pass through an opaque object is to
use no_shadow...which automatically turns on pass_through as well.
HOWEVER,  there is a caveat here concerning no_shadow:
an optional pass_through OFF should then work, but does not. According to the
docs for 'pass_through':

"If you use the no_shadow keyword, the object will be tagged as pass_through
automatically. You can then turn off pass_through if necessary by simply using
photons { pass_through off }."

------------
BTW:
I was able to reproduce the unexpected slow-down of photon rendering that I
mentioned earlier...or some variation of it...caused in some way by *multiple*
collector objects in a scene producing photon 'shadows'. Both 3.7 and 3.8 beta
1 show this.

I have included an additional and rather specialized test scene (reflection-only
this time, but refraction shows the same behavior): a light_source, a reflection
'target', and two 'collector' objects. One collector sits above the other, to
produce some photon 'shadowing' on the lower one. The best way to witness the
effect is with Work_Threads=1, to slow down the render.

The render  becomes sluggish in the photon *shadow* area on the lower collector,
whereas the un-shadowed areas render very quickly.  This behavior seems odd to
me, since the shadow has no photon caustics. I do realize that shadow
calculations have to be performed there, but...so slowly?  I don't know what
this implies when a scene has *many* collector objects, each casting its own
shadow onto others.  (Of course, fast multi-threaded machines tend to mask this
effect, but it's still there.)

To see an even worse and 'different'(?) example, use no_shadow for the upper
collector box. In this case, the box itself renders **very** slowly. That's
quite strange.

The only way to prevent these slow-downs is with 'collect off' in either one of
my collector objects.

Post a reply to this message

Attachments:
Download 'photon_reflection_test_scene_kw.pov.txt' (4 KB)

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> But for REFLECTION caustics, no_image works 'as expected'-- the photon light
> *is* blocked.  So currently, no shadow works in a different way for reflected
> vs. refracted caustics.
>

That has a small but confusing typo, sorry:

But for REFLECTION caustics, no_image works 'as expected'-- the photon light
*is* blocked.  So currently, no_IMAGE works in a different way for reflected
vs. refracted caustics.

Post a reply to this message