I was looking at using the Dakota Red Granite macro from Thomas de Groot in a
scene that I am working on and found that it generates a material{}.  I had been
under the mistaken notion that you couldn't layer materials, until I read the
details on what they are, which made me happy.

But I started wondering how all of the components of a layered material actually
work and couldn't find a concise explanation.

The pigment part of the texture in a material makes sense to me, and I
understand that the filter/transmit values determine how to mix the texture
starting from the bottom to the top layer.  The other parts are not so clear to
me.

Normals:  Do upper layers add or replace the normal in the lower layer(s)?  It
doesn't seem that pigment transparency would have any effect on mixing the
normals from the various layers.

Finish: Same question, does it add or replace the finish from the lower layers?
If it replaces, does it only replace the elements of the finish not declared in
lower layers, or does it replace the entire finish?  I am pretty sure pigment
transparency doesn't affect this either, or else the standard layering tactic to
make the top layer a completely transparent pigment with the finish you want
wouldn't work.

Interior: This is what just recently occurred to me, and I have no idea what
happens here.  Again, do subsequent interior statements replace prior ones, or
just add what wasn't previously declared?

For most of my interiors I am only concerned with ior, so replacement makes
sense, but what about interior fading and media?

-- Chris R

Post a reply to this message

"Chris R" <car### [at] comcastnet> wrote:
> I was looking at using the Dakota Red Granite macro from Thomas de Groot in a
> scene that I am working on and found that it generates a material{}.  I had been
> under the mistaken notion that you couldn't layer materials, until I read the
> details on what they are, which made me happy.
>
> But I started wondering how all of the components of a layered material actually
> work and couldn't find a concise explanation.
>
> The pigment part of the texture in a material makes sense to me, and I
> understand that the filter/transmit values determine how to mix the texture
> starting from the bottom to the top layer.  The other parts are not so clear to
> me.
>
> Normals:  Do upper layers add or replace the normal in the lower layer(s)?  It
> doesn't seem that pigment transparency would have any effect on mixing the
> normals from the various layers.
>
> Finish: Same question, does it add or replace the finish from the lower layers?
> If it replaces, does it only replace the elements of the finish not declared in
> lower layers, or does it replace the entire finish?  I am pretty sure pigment
> transparency doesn't affect this either, or else the standard layering tactic to
> make the top layer a completely transparent pigment with the finish you want
> wouldn't work.
>
> Interior: This is what just recently occurred to me, and I have no idea what
> happens here.  Again, do subsequent interior statements replace prior ones, or
> just add what wasn't previously declared?
>
> For most of my interiors I am only concerned with ior, so replacement makes
> sense, but what about interior fading and media?
>
> -- Chris R

I started doing some experiments to try and determine empirically how the
layering works.  I did not devise anything yet to test what layered interior
statements do; I focused on the textures part first.

As expected, and explained in documentation, the pigment{} portions of layered
textures are blended together based on filter/transmit settings of the layers
above the base layer.

Normals, also seem to be blended, and it appears the pigment
transparency/filtering is used to determine how to blend them.  I'm not sure how
the implementation works, but possibly the normal is applied to the pigment
first, and then the layers are blended together?

Finish: this is the hairiest one to figure out.
Specular seems to be additive.  I created a solid pigment layer with specular
1.0 and default for everything else.  I created a completely transparent pigment
layer with specular 1.0 and everything else default.  The specular highlight on
the layered object was twice as bright as the highlight on the base-only object.
 It's a little hard to tell what's happening when you have a partially
transparent layer.

I think roughness is somehow combined, but it isn't additive.  Not sure how its
done.

Diffuse seems to be a blend based on the transparency of the upper pigment, but
again, it is a little hard to determine what its doing with my small
experiments.

Reflection seems to be the most confusing.  If the lower layer has no
reflection, and the upper layer has reflection, the whole object has the upper
layer reflection, regardless of the pigment filter/transmit of the upper layer.

However, I did some experiments where the base layer had a reflection of 1, and
the upper layer had a reflection of 0.  In this case, the parts of the base
layer that show through the pigment filter/transmit have reflection, but the
parts of the upper layer that are visible have no reflection.

I haven't looked into things like metallic, crand, etc.

-- Chris R

Post a reply to this message

"Chris R" <car### [at] comcastnet> wrote:
> I was looking at using the Dakota Red Granite macro from Thomas de Groot in a
> scene that I am working on and found that it generates a material{}.  I had been
> under the mistaken notion that you couldn't layer materials, until I read the
> details on what they are, which made me happy.
>
> But I started wondering how all of the components of a layered material actually
> work and couldn't find a concise explanation.
>
> The pigment part of the texture in a material makes sense to me, and I
> understand that the filter/transmit values determine how to mix the texture
> starting from the bottom to the top layer.  The other parts are not so clear to
> me.
>
> Normals:  Do upper layers add or replace the normal in the lower layer(s)?  It
> doesn't seem that pigment transparency would have any effect on mixing the
> normals from the various layers.
>
> Finish: Same question, does it add or replace the finish from the lower layers?
> If it replaces, does it only replace the elements of the finish not declared in
> lower layers, or does it replace the entire finish?  I am pretty sure pigment
> transparency doesn't affect this either, or else the standard layering tactic to
> make the top layer a completely transparent pigment with the finish you want
> wouldn't work.
>
> Interior: This is what just recently occurred to me, and I have no idea what
> happens here.  Again, do subsequent interior statements replace prior ones, or
> just add what wasn't previously declared?
>
> For most of my interiors I am only concerned with ior, so replacement makes
> sense, but what about interior fading and media?
>
> -- Chris R

One note that is causing an issue at the moment:  An identifier for a material{}
cannot be used in a texture_map, and as is well-documented, material_map is not
the same thing at all.

So if, for example, there is a library macro (such as DakotaRedGranite) that
returns a material, rather than a texture, it cannot be used in a patterned
texture.

In my particular use case, I was hoping to have an object that is partially
polished, and partially unpolished, as if the polish had worn away in some
places, but there is no way to "unpack" the texture from the material, so I will
have to take the macro code and modify it to return a texture instead of a
material if I want to do this.

-- Chris R

Post a reply to this message

Op 28-3-2024 om 18:55 schreef Chris R:
> [snip]
> 
> In my particular use case, I was hoping to have an object that is partially
> polished, and partially unpolished, as if the polish had worn away in some
> places, but there is no way to "unpack" the texture from the material, so I will
> have to take the macro code and modify it to return a texture instead of a
> material if I want to do this.
> 
> 
It has been a long time since I last looked at the granite code... Your 
analysis is right I guess, your questions are sensible, but I do not 
have the necessary insight into  the particular/individual 
working/interactions of all the elements in POV-Ray to answer them 
properly. As you may perhaps remember, the project initiated from an 
individual need at the time, and - as happens often - inflated and 
became more complex as work progressed. Your particular wish was not 
considered or thought of then, I am afraid.

I guess you will have to do as you suggest above. I don't know what 
would be the most sensible approach. Probably to pull the code apart and 
re-assemble it as two separate textures, or as one texture macro with a 
polished/dull switch. The material envelop can always be added later if 
necessary.

If I get a smart idea I shall come back. Time and energy are rather at a 
low level though... :-(

-- 
Thomas

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 28-3-2024 om 18:55 schreef Chris R:
> > [snip]
> >
> > In my particular use case, I was hoping to have an object that is partially
> > polished, and partially unpolished, as if the polish had worn away in some
> > places, but there is no way to "unpack" the texture from the material, so I will
> > have to take the macro code and modify it to return a texture instead of a
> > material if I want to do this.
> >
> >
> It has been a long time since I last looked at the granite code... Your
> analysis is right I guess, your questions are sensible, but I do not
> have the necessary insight into  the particular/individual
> working/interactions of all the elements in POV-Ray to answer them
> properly. As you may perhaps remember, the project initiated from an
> individual need at the time, and - as happens often - inflated and
> became more complex as work progressed. Your particular wish was not
> considered or thought of then, I am afraid.
>
> I guess you will have to do as you suggest above. I don't know what
> would be the most sensible approach. Probably to pull the code apart and
> re-assemble it as two separate textures, or as one texture macro with a
> polished/dull switch. The material envelop can always be added later if
> necessary.
>
> If I get a smart idea I shall come back. Time and energy are rather at a
> low level though... :-(
>
> --
> Thomas
I took a crack at breaking it into two macros.  The bulk is your original macro,
renamed, but instead of declaring a material at the end of it that encloses all
of the textures with an interior, I just returned the layered texture.  I then
added a new version of DakotaRedGranite that declares a material with the
texture returned by the new macro and an interior { ior 1.6 }.  That way if I
want the original behavior, I still just call your macro name.  If I need to
include the texture in a pattern, I call just the texture version of it.

There were a few other tweaks due to some parser errors that I still don't quite
understand, but I got it to work.

-- Chris R

Post a reply to this message

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

> There were a few other tweaks due to some parser errors that I still don't quite
> understand, but I got it to work.

Well post the errors and we'll see what we can do.

Also would be nice to post what you've currently got, so others can use it as a
texture, but also see if they can fix any problems that you've found.

- BE

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Chris R" <car### [at] comcastnet> wrote:
>
> > There were a few other tweaks due to some parser errors that I still don't quite
> > understand, but I got it to work.
>
> Well post the errors and we'll see what we can do.
>
> Also would be nice to post what you've currently got, so others can use it as a
> texture, but also see if they can fix any problems that you've found.
>
> - BE

I will start with the parsing errors I ran into with my initial transformation.

Here is the tail end of the original DakotaRedGranite macro that declares the
material and returns it:

#declare M_DakotaRed =
material {
  interior {ior 1.6}
  #if (Pol) //polished
    #if (Typ=1)
      texture {T1_DakotaRedPol}
    #else
      texture {T1_DakotaRedPol}
      texture {T2_DakotaRedPol}
    #end  //Typ
  #else //frosted
    #if (Typ=1)
      texture {T1_DakotaRedFro}
      Crand(0.25)
    #else
      texture {T1_DakotaRedFro}
      texture {T2_DakotaRedFro}
      Crand(0.25)
    #end  //Typ
  #end  //Pol
  scale M_scale
  rotate M_rotat
  translate M_trans
} //material

M_DakotaRed

I did a test with Type=1 and Pol=off and calling the macro was successful.

Here was my first attempt at having it return just the texture part:

    #local _t_dakota_red_tmp    =
  #if (Pol) //polished
    #if (Typ=1)
      texture {T1_DakotaRedPol}
    #else
      texture {T1_DakotaRedPol}
      texture {T2_DakotaRedPol}
    #end  //Typ
  #else //frosted
    #if (Typ=1)
      texture {T1_DakotaRedFro}
/*Line 658 */  CRand(0.25) //texture { _t_crand }
    #else
      texture {T1_DakotaRedFro}
      texture {T2_DakotaRedFro}
      CRand(0.25) //texture { _t_crand }
    #end  //Typ
  #end  //Pol

    #declare T_DakotaRed    = texture {
        _t_dakota_red_tmp
          scale M_scale
          rotate M_rotat
          translate M_trans
    }
    ;

    T_DakotaRed
}

#macro DakotaRedGranite(CSC, Pol, Typ, Pat1, Pat2, Blend, SS)
    #local _m   = material {
/*Line 681*/        texture { DakotaRedGranite_texture(CSC, Pol, Typ, Pat1,
Pat2, Blend, SS) }
        interior { ior 1.6 }
    }

    _m
#end

The two step declaration of the final texture is required since there is no
other way to apply the scale/rotate/translate transformation to a layered
texture.

The error I get using the same Typ and Pol parameters is:
Line 681: Possible Parse Error: Unmatched {
Line 658: Parse Error: No matching }, undeclared identifier instead

To fix these errors in my final version, I change the CRand(Intensity) to return
a texture identifier instead of a texture, then right before the #local
_t_dakota_red_tmp line, I do:

#local _t_crand = texture { Crand(0.25) }

and then replace each of the CRand(0.25) invocations in the _t_dakota_red_tmp
declaration to texture { _t_crand } instead.

Once I do that the two parse errors go away and everything works correctly.

I have attached my version of the file as well.

-- Chris R

Post a reply to this message

Attachments:
Download 'dakota_red_granite.inc.txt' (24 KB)

I likely won't be able to look at this today - have work, errands, and
snow"storm" on the way (hopefully the LAST one of the year.
But after that, hopefully I'll have some time to whisk through it and see what I
can puzzle out.

- BE

Post a reply to this message

Op 1-4-2024 om 19:20 schreef Chris R:
> I will start with the parsing errors I ran into with my initial transformation.
> 
First comment:
I think that the necessity to explicitly /declare/ the texture of the 
Crand() macro comes from the fact that the material{} envelop has been 
dropped. So, it seems that in order to enable the layered texture built, 
the Crand() macro needs to be put /inside/ a texture declaration, as you 
did.

Second comment:
Your macro version works fine but you can simplify the output in the 
following way. Instead of:

> #macro DakotaRedGranite(CSC, Pol, Typ, Pat1, Pat2, Blend, SS)
>      #local _m   = material {
>          texture { DakotaRedGranite_texture(CSC, Pol, Typ, Pat1,
> Pat2, Blend, SS) }
>          interior { ior 1.6 }
>      }
> 
>      _m
> #end
> 
you can simply write:

#macro DakotaRedGranite(CSC, Pol, Typ, Pat1, Pat2, Blend, SS)
         texture { DakotaRedGranite_texture(CSC, Pol, Typ, Pat1, Pat2, 
Blend, SS) }
#end

And then apply the macro in a scene, in the following way if you 
need/want to wrap the texture in a material{} declaration:

// sample sphere
sphere { <0,0,0>, 1.00
   material {
     DakotaRedGranite (CSC, Pol, Typ, Pat1, Pat2, Blend, SS)
     interior { ior 1.6 }
   }
   scale<1,1,1>  rotate<0,0,0>  translate<0,1.35,0>
}  // end of sphere -----------------------------------

The macro returns a texture{} which can be then be used as such in any 
scene.

Bill will note other issues or improvements I am sure. ;-)

-- 
Thomas

Post a reply to this message

Attachments:
Download 'chrisr_test.png' (197 KB)

Preview of image 'chrisr_test.png'

Op 2-4-2024 om 17:28 schreef Thomas de Groot:
> you can simply write:
> 
> #macro DakotaRedGranite(CSC, Pol, Typ, Pat1, Pat2, Blend, SS)
>          texture { DakotaRedGranite_texture(CSC, Pol, Typ, Pat1, Pat2, 
> Blend, SS) }
> #end
> 
NOTE==> even better: you can completely skip this particular macro 
definition!

> And then apply the macro in a scene, in the following way if you 
> need/want to wrap the texture in a material{} declaration:
> 

// sample sphere
sphere { <0,0,0>, 1.00

   material {
     texture { DakotaRedGranite_texture (CSC, Pol, Typ, Pat1, Pat2, 
Blend, SS) }
     interior { ior 1.6 }
   }

   scale<1,1,1>  rotate<0,0,0>  translate<0,1.35,0>
}  // end of sphere -----------------------------------

As your granite macro version generates a texture{}, it can be used as 
such in a scene.


> Bill will note other issues or improvements I am sure. ;-)

[ still valid ;-)  ]

-- 
Thomas

Post a reply to this message