First, here's bad news:

We have a bug in photons { pass_through }.

The current implementation mechanism is (and apparently has always been) 
causing an "amplification" effect on photons. See 
http://bugs.povray.org/task/93 for an example scene.

Then, there's good news:

I located the error.

There is a piece of code in PhotonTrace::ComputeLightedTexture that 
causes pass_through objects to *both* let the photon pass unaffected 
*and* have a clone of it pass trough it with all effects - transmit & 
filter attenuation, reflection & refraction - the whole smash.

Duh!

Question is, how to fix this thing? Do we just want to suppress 
reflection & refraction but do transmit & filter attenuation? That would 
be my favorite, though according to the documentation only media-based 
attenuation should occur.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> First, here's bad news:
>
> We have a bug in photons { pass_through }.
>
> The current implementation mechanism is (and apparently has always been)
> causing an "amplification" effect on photons. See
> http://bugs.povray.org/task/93 for an example scene.
>
> Then, there's good news:
>
> I located the error.
>
> There is a piece of code in PhotonTrace::ComputeLightedTexture that
> causes pass_through objects to *both* let the photon pass unaffected
> *and* have a clone of it pass trough it with all effects - transmit &
> filter attenuation, reflection & refraction - the whole smash.
>
> Duh!
>
> Question is, how to fix this thing? Do we just want to suppress
> reflection & refraction but do transmit & filter attenuation? That would
> be my favorite, though according to the documentation only media-based
> attenuation should occur.

I suspect people may have been using this for an artistic effect to date, so I'm
in favor of throwing an optional parameter to pass_through:

Omitted/"double": Current effect.
"transmit"/"filter": Proposed effect; suppresses only reflection/refraction.
"media": Suppresses all non-media attenuation.

At least, if doing it this way wouldn't make things more complicated than it's
worth.

Post a reply to this message

> First, here's bad news:
>
> We have a bug in photons { pass_through }.
>
> The current implementation mechanism is (and apparently has always been)
> causing an "amplification" effect on photons. See
> http://bugs.povray.org/task/93 for an example scene.
>
> Then, there's good news:
>
> I located the error.
>
> There is a piece of code in PhotonTrace::ComputeLightedTexture that
> causes pass_through objects to *both* let the photon pass unaffected
> *and* have a clone of it pass trough it with all effects - transmit &
> filter attenuation, reflection & refraction - the whole smash.
>
> Duh!
>
> Question is, how to fix this thing? Do we just want to suppress
> reflection & refraction but do transmit & filter attenuation? That would
> be my favorite, though according to the documentation only media-based
> attenuation should occur.

When I add pass_through, I expect the object to have no effect on the 
photons, but I like your suggestion of allowing filter and transmit to 
affect the result.

With your suggestion, if there is something looking like a stained 
glass, or similar, in the way of the incoming light, you'll get all the 
effect of it, without having to compute photons for areas that only get 
affected by that filtering object.

If you go that way, the documentations will have to be changed to match 
that behaviour.



Alain

Post a reply to this message

Am 02.04.2010 23:54, schrieb MDenham:

> I suspect people may have been using this for an artistic effect to date, so I'm
> in favor of throwing an optional parameter to pass_through:

No, it's definitely broken. If backward compatibility is really a 
concern, the policy would be to fall back to the current behavior when 
#version 3.6 (or earlier) is specified, while providing no way of 
"resurrecting" this bug for non-legacy scenes. This way, some versions 
later the bug can be fully removed from the code.

Post a reply to this message

Am 03.04.2010 00:11, schrieb Alain:

> With your suggestion, if there is something looking like a stained
> glass, or similar, in the way of the incoming light, you'll get all the
> effect of it, without having to compute photons for areas that only get
> affected by that filtering object.

Yup, that's exactly why I favor it. I think it is a good deal more 
useful than just making it fully neutral to photons altogether - and if 
that functionality should still be desired, I'd personally prefer the 
keyword to fit into the "no_something" group, i.e. "no_photons".

> If you go that way, the documentations will have to be changed to match
> that behaviour.

Definitely so. But I'd even volunteer to change it if that helps my 
cause :-P

Post a reply to this message

Alain <aze### [at] qwertyorg> wrote:
> When I add pass_through, I expect the object to have no effect on the 
> photons

  If I understand correctly, the object's *surface* has no effect on the
photons when 'pass_through' is specified, but if the object has media and
the photons are set up to interact with it, then they will become visible
in the media.

  Well, at least that's how it works in the simple media tutorial I wrote
for the docs. However, I have later noticed that photons often behave
inconsistently with regard to this.

  It's also confusing. Maybe a clearer syntax for different interactions
should be devised.

-- 
                                                          - Warp

Post a reply to this message

clipka wrote:

> and if  that functionality should still be desired, I'd personally prefer 
> the  keyword to fit into the "no_something" group, i.e. "no_photons".

I think pass_through was originally intended to be the photon
equivalent of "no_shadow" (considering the latter automatically
avtivates the first). If you think of this in the sense of light
(fakedly) passing through a solid (non-transparent) object it
certainly makes sense that transmit was ignored.

My guess would be that removing the undocumented clone photon
would have less impact on existing scenes than changing the
documented shadowing behavior.

But if it is changed as you suggested here, then I'd vote for
having "no_photons" as a replacement. Also, "pass_through" should
then be decoupled from "no_shadow" as they will no longer be
closely related. And I don't think "no_shadow" should imply
"no_photons" either, that just creates confusion.

BTW, another confusing aspect of pass_through is that it only
has an effect prior to hitting the photon target. At least for
a new no_photons keyword I'd suggest to make no distinction
there if technically possible.

Post a reply to this message

Am 05.04.2010 18:35, schrieb Christian Froeschlin:

> BTW, another confusing aspect of pass_through is that it only
> has an effect prior to hitting the photon target. At least for
> a new no_photons keyword I'd suggest to make no distinction
> there if technically possible.

It definitely is possible.

Post a reply to this message