If an existing layered texture uses filter, it will look the same using
transmit. The conversion is not that hard, and I personally would like
to be able to have filtering layers.
This is a problem with the language, if I tell it to use filter, it uses
transmit. It should do what I tell it, or at least issue a warning that
it can't.

Maybe instead of changing the behavior, we should make a new way of
specifying transparency. Keep the existing method the way it is, but add
a transparence {} to the pigment statement.
transparence {
    additive AMOUNT
    multiplicative AMOUNT
    function {blah()}//an isosurface patch type function
}
This would keep compatibility with current scenes, but make it much more
flexible.

Post a reply to this message

>I vote NO, NO, and NO ! Leave it alone and go pick on something else that
needs
>it.


Are you saying we don't need to have filtering texture layers?  I do!  As
for complex textures using both filter and transmit under the current
implimentation - from what I've seen, POV simply adds the filter value to
the transmit value, and until I get pointed to specific documentation
stating otherwise, I can hardly see how this would be such a problem to
convert.  Someone could even write a very basic conversion utility which
could easily fix 95% of all textures.

Post a reply to this message

Perhaps they should add a keyword to the global_settings block:

global_settings { filtered_layered_textures on }

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Nieminen Mika wrote:
> 
>   Perhaps they should add a keyword to the global_settings block:
> 
> global_settings { filtered_layered_textures on }
> 
> --
> main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
> ):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

And/or use the old method when version <= 3.1

Cheers, PoD.

Post a reply to this message

"Edward C." wrote:
> 
> >You can't really call call it a bug in the official version because it is
> >documented.
> 
> Can you point me to where it is documented?  I've looked, but cannot find it
> anywhere.

Actually, I think you may be right.  I just checked the documentation, and
it says (under Layered Textures):
"The color of underlying layers is filtered by upper layers but the results do
not look exactly like a series of transparent surfaces. If you had a stack of
surfaces with the textures applied to each, the light would be filtered twice:
once on the way in as the lower layers are illuminated by filtered light and
once on the way out. Layered textures do not filter the illumination on the way
in. Other parts of the lighting calculations work differently as well. The
results look great and allow for fantastic looking textures but they are simply
different from multiple surfaces. See stones.inc in the standard include files
directory for some magnificent layered textures."

Notice that it does say "filtered", not "transmitted".  So there is a
difference between what the docs say and what the program does.

I personally think that this should be 'fixed' in POV 4.0 so that it does
work 'correctly'.  Yes, this will break scenes, but not to the extent that
most people would expect.  The fact that POV treats filter like transmit
right now means that users are probably not mixing little bits of filter
and transmit, at least not with layered textures (and layered textures is
the only thing affected).  So, people probably used either filter or
transmit and never noticed that they looked te same.  Or if they used
both they add together.

So rgbft<1,1,1,1,1> would turn into rgbt<1,1,1,2> with the new system (add
the filter and transmit)... but only in a layer, of course. Now, I'm not
sure if UVPov currently allows transmit over 1.0 (I think it does), but
some official standard that makes sense could be adopted.

-Nathan

Post a reply to this message

Chris Huff wrote:
> 
> Ok, that is true, how about "mis-feature"?
> Although it would break some scenes, I will bet most people used
> transmit instead of filter

You are probably correct.  Although textures created before the days of the
transmit keyword (POV 3.0, if I remember correctly), such as woods.inc and
stones.inc use rgbf heavily in layers, anyone who has created a texture
with the intent to transmit probably did use transmit.  Or, they intended
to filter, got transmit, and didn't notice that it was incorrect.

-Nathan

Post a reply to this message

Bob Hughes wrote:
> 
> Except for the 'rgbft <1,1,1,1,1>' it would be simple, sure.

In this case you'd just use rgbt<1,1,1,2>

Post a reply to this message

Ken wrote:
> 
> ...would break SOME scenes ??????
> 
>   The scenes it would break would number in the tens of thousands when
> multiplied by the total number of Pov users and should not be considered
> lightly. There are some of us out here that create very complicated textures
> using very large color maps and many layers. It would not be a trivial task
> to ensure that the adaptation would work correctly.

It might be possible to leave it to the system to do the conversion instead
of forcing the user... built in backwards compatibility... see my reply to
Nieminen's post.

> Add to this that some of
> these advanced textures are designed with varying amounts of both transmit
> and filter values. This would add greatly to the complexity of the
> conversion.     

Actually, varying amounts of both transmit and filter in a layer would just
be added together and placed in the transmit channel.  In fact, doing that
with POV should even work.

> Additionally
> there some among us, me for example, that are tracaholics that
> would have to convert literally hundreds of files to comply to this proposed
> change and would not take such a change laying down. It has been hard enough
> going through and just adding all of those pesky darn semicolons and you are
> proposing something that would create much more work than that.

Point taken.

-Nathan

Post a reply to this message

Nieminen Mika wrote:
> 
>   Perhaps they should add a keyword to the global_settings block:
> 
> global_settings { filtered_layered_textures on }
> 

This is probably the best solution... I'll try to implement it in UVPov
when I get a chance.

-Nathan

Post a reply to this message

Nathan Kopp wrote in message <3786D2A9.772FC4C4@Kopp.com>...
>
>"Edward C." wrote:
>>
>> >You can't really call call it a bug in the official version because it
is
>> >documented.
>>
>> Can you point me to where it is documented?  I've looked, but cannot find
it
>> anywhere.
>I personally think that this should be 'fixed' in POV 4.0 so that it does
>work 'correctly'.  Yes, this will break scenes, but not to the extent that
>most people would expect

Or, the documentation could be fixed :-)

Mark

Post a reply to this message