Does anyone know if filtering in layered textures is broken in 3.1e Win?
When I layer a red texture over a grey and white checker texture, adjusting
the filter of the red colour seems to do exactly the same thing as adjusting
the transmit does - at a value of 0.0 I get flat red, at 0.5 I get dark and
light pink and at 1.0 I get grey and white.  I thought it should give red
and dark red at 1.0, or am I mistaken?

Post a reply to this message

The filter in layered textures does not work properly in the official
version of POV-Ray(filter is treated as transmit in layered textures).
Nathan Kopp's UVPov has this problem fixed.

Post a reply to this message

You can't really call call it a bug in the official version because it is
documented.  On the other hand, I personally think my changes make sense.
Note that if you use UVPov, you'll have to change all of the default includes
(like "woods.inc") to show rgbt instead of rgbf.

-Nathan


Chris Huff wrote:
> 
> The filter in layered textures does not work properly in the official
> version of POV-Ray(filter is treated as transmit in layered textures).
> Nathan Kopp's UVPov has this problem fixed.

Post a reply to this message

>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.
And a question to the POV-Team: What is your position on this issue - are
there plans to change?
I'm reluctant to move to unofficial versions (for no good reason - I am a
fool, I don't want to use lots of different versions, and I probably
couldn't choose between UV and Super, plus I figure the official release
will catch up eventually), so how can I apply varnish in the current
official implimentation?

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.

  I believe what he means by documented it that is currently works exactly
as the docs say it should. This conflicts with the way the Nathan thinks
it should work.

-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

Ok, that is true, how about "mis-feature"?
Although it would break some scenes, I will bet most people used
transmit instead of filter, and POV-Ray should really allow filter in
layered textures(and treat it as filter).
The scenes it breaks would be very easy to fix, just replace filter with
transmit.(or rgbf with rgbt)

Post a reply to this message

Except for the 'rgbft <1,1,1,1,1>' it would be simple, sure. That and
the fact that textures are possibly made to look right while creating
the layered texture itself and not always built up from previously
declared ones.


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, and POV-Ray should really allow filter in
> layered textures(and treat it as filter).
> The scenes it breaks would be very easy to fix, just replace filter with
> transmit.(or rgbf with rgbt)

-- 
 omniVERSE: beyond the universe
  http://members.aol.com/inversez/homepage.htm
 mailto://inversez@aol.com?Subject=PoV-News

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, and POV-Ray should really allow filter in
> layered textures(and treat it as filter).
> The scenes it breaks would be very easy to fix, just replace filter with
> transmit.(or rgbf with rgbt)

...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. 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.    
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.

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

-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

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