When I was making my irtc animation entry, povray told me this:

error: Cannot layer over a patterned texture.

  Why not?

  It was good that I was applying the texture to a plane. I had to do it with
several planes one over another. If it was a more complex object, it would
have been impossible.

  An example scene which demonstrates this:

camera { location -z*4 look_at 0 angle 35 }
light_source { <100,200,-300> 1 }
#declare Text1=
  texture
  { wood texture_map
    { [0 pigment { rgb z }]
      [1 pigment { rgb 1 }]
    }
  }
#declare Text2=
  texture { pigment { marble color_map { [0 rgbf 1][1 rgb 1] } } }
sphere
{ 0,1
  texture { Text1 scale .2 }
  texture { Text2 scale .5 }
}

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

I have run into this problem before, I don't see why this limitation
exists. Maybe another project for me to work on. :-)

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

On 23 Nov 1999 11:29:02 -0500, Nieminen Juha
<war### [at] punarastascstutfi> wrote:

>  When I was making my irtc animation entry, povray told me this:
>
>error: Cannot layer over a patterned texture.
>
>  Why not?

I have run into the same problem more than once in the past and have
always achieved good results by nesting the patterned texture into the
one I couldn't layer, more precisely supplementing all clear parts
with the aforementioned patterned texture. Personally I don't see it
as a bug but rather a limitation in POV (it does give a proper error
message :) ) but have no answer as to why such a limitation exists. I
will approach the Team with this question and see if they have an
answer.


Peter Popov
ICQ: 15002700

Post a reply to this message

Great, hope they see a better way for doing that.  I don't like having to
work around it, I build up a bunch of layers instead, guess something like
Peter does.  Must be something in the layering routine like a wrapper not
being accessible within another, don't you think?

Bob

Peter Popov <pet### [at] usanet> wrote in message
news:rwQ7OMjikoNkC6VwSG3nRL6+NmDp@4ax.com...
> On 23 Nov 1999 11:29:02 -0500, Nieminen Juha
> <war### [at] punarastascstutfi> wrote:
>
> >  When I was making my irtc animation entry, povray told me this:
> >
> >error: Cannot layer over a patterned texture.
> >
> >  Why not?
>
> I have run into the same problem more than once in the past and have
> always achieved good results by nesting the patterned texture into the
> one I couldn't layer, more precisely supplementing all clear parts
> with the aforementioned patterned texture. Personally I don't see it
> as a bug but rather a limitation in POV (it does give a proper error
> message :) ) but have no answer as to why such a limitation exists. I
> will approach the Team with this question and see if they have an
> answer.
>
>
> Peter Popov
> ICQ: 15002700

Post a reply to this message

Peter Popov <pet### [at] usanet> wrote:
: more precisely supplementing all clear parts
: with the aforementioned patterned texture.

  Well, this was what I first did (before trying layering), but there seems
to be a problem with scaling the granite pattern (at least when used as a
normal pattern). The problem was that I wanted to scale up the texture
pattern without scaling up the underlying textures. What I tried was to
first scale down the textures and then scaling up the texture pattern. It
broke the granite normal (I have to post a separated article about this).
  Since it didn't work, I tried layering the textures instead, with known
results...

  I ended up using a separate plane for each layer. Slows down rendering...

-- 
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 Juha wrote:
> 
>   When I was making my irtc animation entry, povray told me this:
> 
> error: Cannot layer over a patterned texture.
> 
>   Why not?

Why ?
  Why not simply declare your first texture as a color map instead of a
texture map. I tried it and it worked and I see no advantage in doing it
differently.

It's been like this since v3.0 came out.

-- 
Ken Tyler -  1200+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

Ken <tyl### [at] pacbellnet> wrote:
:   Why not simply declare your first texture as a color map instead of a
: texture map.

  I need the normals and finishes too, not only the colors. Ground and forest
look very dumb without normal modifiers... :)

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

On 23 Nov 1999 11:29:02 -0500, Nieminen Juha wrote:
>  When I was making my irtc animation entry, povray told me this:
>
>error: Cannot layer over a patterned texture.
>
>  Why not?

This appears to be due to a bit of weird design in the renderer.  When it
evaluates a texture, it first finds out which two textures it needs to 
interpolate between (assuming there is a texture map).  Then, it evaluates
each of those textures as a "plain" (i.e. nonlayered) texture.  Finally,
it interpolates the resulting color.

Unfortunately, the routine that evaluates a "plain" texture is also the
routine that handles reflection, refraction, and lighting calculations.
There might be a perfectly valid reason why this is, but I haven't given
it enough thought to say for sure.  

In any case, the upshot is that the texture-evaluation functions, including 
the one to handle texture maps, return three-component colors (having 
already computed the results of any filtering or transmission.)  Since the 
plain-texture evaluation routine needs a five-component color to do its job, 
it can't call the texture_map evaluation routine.  One could change the 
texture_map routine to return five-component colors, but then it would 
require the plain routine to return five-component colors, and you'd have to
move the reflection, transmission, and lighting code into a wrapper outside 
of those routines.  In addition to colors, you'd also have to pass back 
normals and finish info from both routines.

I'm guessing that whoever wrote texture_maps reasoned that all that was too 
much work for a feature (layering texture_maps) that people would probably 
use rarely, if at all, and besides, you're supposed to be able to work 
around it.

By the way, one side-effect of this is that POV seems to trace too many rays 
for some scenes.  The following scene traces three rays per pixel (one eye 
ray plus one transmitted ray for each of the plain textures in the 
interpolation.)  I suppose you could call that a bug.

camera { location -5*z look_at 0 }

plane {
  -z, 0 
  texture {
    gradient x texture_map {
     [0 pigment {color rgbt 1}]
     [1 pigment {color rgbt 1}]
    }       
    translate .5*x scale 500
  }
}

Another side-effect is that the following two textures are not the same, even 
though it seems they should be (that is, a texture_map of two normals is not 
the same as a normal_map of the same two normals):

  texture {
    pigment {
      color rgb 1
    }     
    finish {reflection 1} 
    normal {
      gradient x 
      normal_map {
        [ 0 marble 50 scale .01 ]
        [ 1 marble 50 scale .01 rotate 90*z ]
      }
      translate -.5*x
      scale 50
    }
  }
  

  texture {
    gradient x 
    texture_map {
      [0 pigment {
           color rgb 1
         }     
         finish {reflection 1} 
         normal {marble 50 scale .01}
      ]
      [1 pigment {
           color rgb 1
         }     
         finish {reflection 1} 
         normal {marble 50 scale .01 rotate 90*z}
      ]
    }
    translate -.5*x
    scale 50
  }

-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message

Here's another scene that shows a side-effect of the problem (or
whatever it is) I mentioned in the previous post:

camera { location -5*z look_at 0 }
plane { -z,-10 pigment {color rgb 1} finish {ambient 1}}

box {
  <-1,-1,-.01>, <1,0,.01>

  texture {  
    gradient x 
    texture_map {
      [0 pigment {color rgbt <1,0,0,1>}finish {ambient 1}]
      [1 pigment {color rgbt <0,1,0,0>}finish {ambient 1}]
    }
  }
}      

box {
  <-1,0,-.01>, <1,1,.01>
  texture {  
    pigment {
      gradient x 
      pigment_map {
        [0 color rgbt <1,0,0,1>]
        [1 color rgbt <0,1,0,0>]
      }
    }
    finish {ambient 1}
  }
}      

-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message

Ron Parker <ron### [at] povrayorg> wrote:

  Thanks for the explanation.

: I'm guessing that whoever wrote texture_maps reasoned that all that was too 
: much work for a feature (layering texture_maps) that people would probably 
: use rarely, if at all, and besides, you're supposed to be able to work 
: around it.

  Yes, the work-around would be using a patterned texture (of patterned
textures) instead of layering. However, it doesn't work if you have normals
and you have to scale the outmost pattern (without scaling the subtextures)
due to the normal scaling bug.
  The need for layered patterned textures will disappear immediately after
the normal scaling bug is fixed... :)

  I don't know what is happening with those normals. The idea is the
following:
  Make a texture with a normal modifier.
  Scale this texture (or only the normal) by the inverse of the value you
want to scale the whole patterned texture. For example if you want the
patterned texture to be 10 times larger (without scaling the subtextures),
then scale this texture by 1/10.
  Add this texture as one component of the patterned texture.
  Now scale the patterned texture by that 10.
  The result _should_ be that the original texture has not changed. Instead,
the normals of the original texture are really weird.
  The resulting normal modifier is not the original normal modifier 10 times
deeper. Dividing the 'amount' value of the normal pattern by 10 doesn't solve
the problem. Something else is happening.

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