I am working on an expansion for the object interior attenuation which
allows the user to specify an extra keyword 'fade_colour', so that the
attenuation tends to a specific colour, rather than just to black.  A sample
image and explanation of why this is good are posted in p.b.i.
My questions to you are:
Do you care?  (ie would you find this handy?)
Should I expand on this to allow the user to specify different fade rates
for red, green and blue?
Why are filter and transmit values attenuated in the shadow calculation code
(compute_shadow_texture)?
And why not in the visible texture calculation code
(compute_lighted_texture)?

Post a reply to this message

Do I care?? Yes.
Whoa, wavelength capable sort of thing too eh? Um, why not, if you
think you can do it ;)
About the attenuation part in shadow. Probably because it is related
in a way by appearence alone? I have no idea though.
Has Ron P. spoke up about any of this yet? Didn't see him over at the
p.b.i. though it's still early. I'm thinking Super Patch of course....

Bob

Edward C. <edw### [at] hotmailcom> wrote in message
news:37c62c19@news.povray.org...
> I am working on an expansion for the object interior attenuation
which
> allows the user to specify an extra keyword 'fade_colour', so that
the
> attenuation tends to a specific colour, rather than just to black.
A sample
> image and explanation of why this is good are posted in p.b.i.
> My questions to you are:
> Do you care?  (ie would you find this handy?)
> Should I expand on this to allow the user to specify different fade
rates
> for red, green and blue?
> Why are filter and transmit values attenuated in the shadow
calculation code
> (compute_shadow_texture)?
> And why not in the visible texture calculation code
> (compute_lighted_texture)?
>
>

Post a reply to this message

"Edward C." wrote:
> 
> I am working on an expansion for the object interior attenuation which
> allows the user to specify an extra keyword 'fade_colour', so that the
> attenuation tends to a specific colour, rather than just to black.  A sample
> image and explanation of why this is good are posted in p.b.i.
> My questions to you are:
> Do you care?  (ie would you find this handy?)
> Should I expand on this to allow the user to specify different fade rates
> for red, green and blue?
> Why are filter and transmit values attenuated in the shadow calculation code
> (compute_shadow_texture)?
> And why not in the visible texture calculation code
> (compute_lighted_texture)?

Actually, fade_distance and fade_color attenuation is computed in
compute_lighted_texture.  The code looks like this:

    /* Get distance based attenuation. */

    Att = Interior->Old_Refract;

    if ((Interior != NULL) && Interior_In_Ray_Container(Ray, Interior) >= 0)
    {
      if (fabs(Interior->Fade_Distance) > EPSILON)
      {
        Att /= (1.0 + pow(Intersection->Depth / Interior->Fade_Distance,
Interior->Fade_Power));
      }
    }

It is right after the call to Refract().

And, yes, fade_color is a great idea.  I was trying to make realistic colored
glass a few weeks ago and thought about adding this feature myself. 
Unfortunately, I never got around to it.

Possible implementations:
1)  Add a new keyword fade_color and multiply the attenuation by it.
2)  Change fade_distance and fade_power to accept a vector (color) instead
    of a float.  (no need for any extra keywords)

-Nathan

Post a reply to this message

Nathan Kopp wrote:
>Actually, fade_distance and fade_color attenuation is computed in
>compute_lighted_texture.  The code looks like this:
<snip>

I assume you mean fade_power, not fade_colour.  Anyway, I never said it
wasn't, I was just wondering why the FILTER and TRANSMIT values are
attenuated along with the RGB components in compute_shadow_texture, but only
the RGB components are attenuated in compute_shadow texture.  It is
important to me since this behaviour breaks my patch (in some situations you
get almost no colour in the shadow) so I have to disable it.

>Possible implementations:
>1)  Add a new keyword fade_color and multiply the attenuation by it.
>2)  Change fade_distance and fade_power to accept a vector (color) instead
>    of a float.  (no need for any extra keywords)

I went with 1, I don't think I could have made 2 work the way I wanted, but
I might do something like it to enable the user to specify different fade
characteristics for each of the colour components.  I just need to take a
little time to figure out how to accept both the old float arguement and my
new vector arguement for fade_distance and fade_power, so as not to break
old scenes.

Post a reply to this message

"Edward C." wrote:
> 
> Nathan Kopp wrote:
> >Actually, fade_distance and fade_color attenuation is computed in
> >compute_lighted_texture.  The code looks like this:
> <snip>
> 
> I assume you mean fade_power, not fade_colour.  Anyway, I never said it
> wasn't, I was just wondering why the FILTER and TRANSMIT values are
> attenuated along with the RGB components in compute_shadow_texture, but only
> the RGB components are attenuated in compute_shadow texture.  It is
> important to me since this behaviour breaks my patch (in some situations you
> get almost no colour in the shadow) so I have to disable it.
> 
> >Possible implementations:
> >1)  Add a new keyword fade_color and multiply the attenuation by it.
> >2)  Change fade_distance and fade_power to accept a vector (color) instead
> >    of a float.  (no need for any extra keywords)
> 
> I went with 1, I don't think I could have made 2 work the way I wanted, but
> I might do something like it to enable the user to specify different fade
> characteristics for each of the colour components.  I just need to take a
> little time to figure out how to accept both the old float arguement and my
> new vector arguement for fade_distance and fade_power, so as not to break
> old scenes.

Doesn't the POV parser automatically promote scalars to vectors in
Parse_Vector()?
So old scenes will not be broken as long as a vector with identical
components gives the same result as the current scheme.

Cheers, PoD.

Post a reply to this message

PoD wrote in message <37C97BF2.B0E5E9E5@merlin.net.au>...
<snip>
>Doesn't the POV parser automatically promote scalars to vectors in
>Parse_Vector()?
<snip>

Hmmm, so it does, cool.  Sadly though, the changes required to impliment
separate fade and distance keywords would be pretty fundimental, so I think
I'll leave it alone.  For now.

Post a reply to this message

On Sat, 28 Aug 1999 15:29:26 -0500, Bob Hughes wrote:
>Has Ron P. spoke up about any of this yet? Didn't see him over at the
>p.b.i. though it's still early. I'm thinking Super Patch of course....

I mentioned that I thought that was the way attenuation should have
worked from the beginning, but not in this specific discussion.  I think
it's a great idea, and when it's done of course I'll add it to the
superpatch.

Post a reply to this message