"Chris R" <car### [at] comcastnet> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > SO, maybe I'm missing something here, but wouldn't just find/replace material
> > with texture yield a layered texture rather than a material?
> >
> > I'm at work atm, so I don't have POV-Ray to test this with.
> >
> > But if that works, then you can also just have the macro declare a global
> > texture name in the process of making the material, and use that after you
> > invoke the macro.
> >
> > - BE
>
> That makes my developer heart hurt... global side effects in a "function" call
> :-).  Of course, macros aren't really functions in POV, but I treat them that
> way when I write code.
>
> However, I could avoid the parsing problems if I had kept the transformations in
> the macro that creates the material wrapper instead of trying to force them into
> the texture.  That way I don't need a wrapping texture, and maybe just declaring
> a local assignment to the layered texture and returning it would not have caused
> the parsing errors with CRand(0.25).
>
> I will play with that.  The less I muck up the original code the better.
>
> -- Chris -R

#declare _t = material {
   texture {T1}
   CRand(0.25)
....
}

works fine

#declare _t = texture {
   texture {T1}
   CRand(0.25)
....
}

is a syntax error; you can't put a texture{} declaration inside of another
texture declaration, so just replacing material with texture doesn't work.  I
also checked that the declaration of the layered texture using CRand(0.25) that
returns a texture{} block rather than a texture identifier works when enclosed
inside of a material wrapper, but if you just declare a texture idenfier as

#declare _t =
texture {T1}
CRand(0.25)
;

you get the syntax error I mentioned earlier about missing braces.

So, somewhere, the parsing for layered textures inside of a material is
different than the parsing of layered textures when declaring a texture
identifier.

-- Chris -R

Post a reply to this message