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

Post a reply to this message

"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

Post a reply to this message

"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

"Chris R" <car### [at] comcastnet> wrote:

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

remove the texture {} wrapper

https://wiki.povray.org/content/Reference:Layered_Textures

You make a copy of the macro, and have a parallel macro with a slightly
different name to make a texture rather than a material.   Then your developer
heart will avoid any mRNA induced myocarditis.  :)

Once you declare the texture, then I think you can use that in a final texture
definition with any other modifiers.  It seems to be just a matter of
hierarchies and syntax at this point.

And I can tell you from experience that that "just" can drive you crazy.

- BE

Post a reply to this message

Op 3-4-2024 om 23:25 schreef Bald Eagle:
> "Chris R" <car### [at] comcastnet> wrote:
> 
>> So, somewhere, the parsing for layered textures inside of a material is
>> different than the parsing of layered textures when declaring a texture
>> identifier.
> 
> remove the texture {} wrapper
> 
> https://wiki.povray.org/content/Reference:Layered_Textures
> 
> You make a copy of the macro, and have a parallel macro with a slightly
> different name to make a texture rather than a material.   Then your developer
> heart will avoid any mRNA induced myocarditis.  :)
> 
> Once you declare the texture, then I think you can use that in a final texture
> definition with any other modifiers.  It seems to be just a matter of
> hierarchies and syntax at this point.
> 
> And I can tell you from experience that that "just" can drive you crazy.
> 
> - BE
> 
Hmmm... doesn't seem to be as /simple/ as that... Have you tried this? I 
am getting nowhere [drives me crazy indeed]

-- 
Thomas

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 3-4-2024 om 23:25 schreef Bald Eagle:
> > "Chris R" <car### [at] comcastnet> wrote:
> >
> >> So, somewhere, the parsing for layered textures inside of a material is
> >> different than the parsing of layered textures when declaring a texture
> >> identifier.
> >
> > remove the texture {} wrapper
> >
> > https://wiki.povray.org/content/Reference:Layered_Textures
> >
> > You make a copy of the macro, and have a parallel macro with a slightly
> > different name to make a texture rather than a material.   Then your developer
> > heart will avoid any mRNA induced myocarditis.  :)
> >
> > Once you declare the texture, then I think you can use that in a final texture
> > definition with any other modifiers.  It seems to be just a matter of
> > hierarchies and syntax at this point.
> >
> > And I can tell you from experience that that "just" can drive you crazy.
> >
> > - BE
> >
> Hmmm... doesn't seem to be as /simple/ as that... Have you tried this? I
> am getting nowhere [drives me crazy indeed]
>
> --
> Thomas

A few posts back in this thread I posted my solution as an attachment.
Essentially I did the following:

1. Modify the CRand macro:
#macro CRand(Intensity)
   #local _t = texture { ... }
   _t
#end

2. Rename the DakotaRedGranite(...) macro to DakotaRedGranite_texture(...)
3. At the end of the macro I did the following:
   #local _t_crand = texture { CRand(0.25) }
   #local _t_result =
   #if (Pol)
   ...
   #else
      #if (Type=1)
         texture {T1_DakotaRedFro}
         texture {_t_crand}
      #else
         texture {T1_DakotaRedFro}
         texture {T2_DakotaRedFro}
         texture {_t_crand}
      #end

   #end

   _t_result

4. Create a new macro named DakotaRedGranite(...)
#macro DakotaRedGranite(...)
   #local _m = material {
      texture { DakotaRedGranite_texture(...) }
      interior { ior 1.6 }
      scale M_scale
      rotate M_rotate
      translate M_trans
   }

   _m
#end

That all seems to parse correctly and works.

-- Chris R

Post a reply to this message

Op 4-4-2024 om 14:59 schreef Chris R:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> Op 3-4-2024 om 23:25 schreef Bald Eagle:
>>> "Chris R" <car### [at] comcastnet> wrote:
>>>
>>>> So, somewhere, the parsing for layered textures inside of a material is
>>>> different than the parsing of layered textures when declaring a texture
>>>> identifier.
>>>
>>> remove the texture {} wrapper
>>>
>>> https://wiki.povray.org/content/Reference:Layered_Textures
>>>
>>> You make a copy of the macro, and have a parallel macro with a slightly
>>> different name to make a texture rather than a material.   Then your developer
>>> heart will avoid any mRNA induced myocarditis.  :)
>>>
>>> Once you declare the texture, then I think you can use that in a final texture
>>> definition with any other modifiers.  It seems to be just a matter of
>>> hierarchies and syntax at this point.
>>>
>>> And I can tell you from experience that that "just" can drive you crazy.
>>>
>>> - BE
>>>
>> Hmmm... doesn't seem to be as /simple/ as that... Have you tried this? I
>> am getting nowhere [drives me crazy indeed]
>>
>> --
>> Thomas
> 
> A few posts back in this thread I posted my solution as an attachment.
> Essentially I did the following:
> 
> 1. Modify the CRand macro:
> #macro CRand(Intensity)
>     #local _t = texture { ... }
>     _t
> #end
> 
> 2. Rename the DakotaRedGranite(...) macro to DakotaRedGranite_texture(...)
> 3. At the end of the macro I did the following:
>     #local _t_crand = texture { CRand(0.25) }
>     #local _t_result =
>     #if (Pol)
>     ...
>     #else
>        #if (Type=1)
>           texture {T1_DakotaRedFro}
>           texture {_t_crand}
>        #else
>           texture {T1_DakotaRedFro}
>           texture {T2_DakotaRedFro}
>           texture {_t_crand}
>        #end
> 
>     #end
> 
>     _t_result
> 
> 4. Create a new macro named DakotaRedGranite(...)
> #macro DakotaRedGranite(...)
>     #local _m = material {
>        texture { DakotaRedGranite_texture(...) }
>        interior { ior 1.6 }
>        scale M_scale
>        rotate M_rotate
>        translate M_trans
>     }
> 
>     _m
> #end
> 
> That all seems to parse correctly and works.
> 
> -- Chris R
> 

Indeed. And I gave a few ideas for slight improvements on that, a couple 
of days ago. Did you see those?

I am probably wrong, but I thought BE was referring to something else...

-- 
Thomas

Post a reply to this message

Le 2024-04-03 à 10:12, Bald Eagle a écrit :
> 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
> 

Essentially, a material is just a wrapper for a texture plus an 
interior. So, if there is no interior, a material is effectively another 
name for a texture.

Post a reply to this message

Op 04/04/2024 om 18:12 schreef Alain Martel:
> 
> Essentially, a material is just a wrapper for a texture plus an 
> interior. So, if there is no interior, a material is effectively another 
> name for a texture.

Yes, that is what I have always assumed. So, if something (a simple 
macro) did work fine inside the original - material-based - granite 
macro, and it does not when the material wrap is taken away, this could 
mean that the original code worked fine... for the wrong reasons!

I have to think about this a bit more and explore deeper. I am not 
satisfied yet...

Anyway, if the code generated by Chris R works fine, there is no reason 
to avoid its use indeed, but it revealed something imho.

-- 
Thomas

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:

> Hmmm... doesn't seem to be as /simple/ as that... Have you tried this? I
> am getting nowhere [drives me crazy indeed]

OK, I think you misunderstood what needed to be done.

Change the outside material {} wrapper to texture {}
REMOVE all of the texture {} statements inside, leaving only the texture names.

That all works - the only thing I couldn't get to work is the Crand, because the
#local/#declare thing in macros is still messed up.



#version 3.8;
global_settings {assumed_gamma 1}

camera {
 location <0, 0, -5>
 right x*image_width/image_height
 up y
 look_at <0, 0, 0>
 rotate y*clock*360
}

sky_sphere {pigment {rgb 1}}

light_source {<100, 100, -500> rgb 1}

#include "Granite_Texture.mcr"

#declare Tex = Granite_21 ()

sphere {0, 1 texture {Tex}}

Post a reply to this message

Attachments:
Download 'granite_texture.mcr.txt' (22 KB)