Edit a simple material with no nodes.

Put RGB 127, 127, 127 into the Diffuse_Color.

Put RGB 128, 128, 128 into the Specular_Color.

Save this material in your library.

Using a text editor, go find that MT5 file and open it and look inside.

  KdColor 0.498039 0.498039 0.498039 1
  KaColor 0 0 0 0
  KsColor 0.501961 0.501961 0.501961 1

The KdColor is the diffuse color - notice it is not .5.
The KsColor is the specular color - notice it is not .5.

What is .498039? It is 127 / 255
What is .501961? It is 128 / 255

In case anybody wants to play with that little demo material node setup, here's is how I made it using a matmatic script.

s = Surface(RED,.5, 1, 1, .1)

white = SimpleColor(WHITE).labelled("White (255)")
two = Add(2).labelled("The number 2")
wo2 = (white / two).labelled("White / 2")

gray7 = SimpleColor(IColor(127, 127, 127)).labelled("GRAY 127")
gray8 = SimpleColor(IColor(128, 128, 128)).labelled("GRAY 128")

gray = Blend(gray7, gray8, .5).labelled("Blender:GRAY 127.5")

tile = Tile(wo2, 1, gray, 1, Mortar_Thickness=0)

s.Bump = 10*tile
 

Moving a lot slower than you, Bill... quantum slower.

If you recall, my secret little objective to using MatMatic was to see if I can recreate (and thus unleash the mysteries of) that first skin shader that came out with VSS initially. Whilst you think it average, i'm totally blown away by it. So, I'm going to see if I can create that material in MatMatic, thus discovering what works and how.

Well, "discovering" might be a strong, somewhat pretentious term, given my predisposition for arriving at erroneous conclusions, but hey, I do think it's a worthy exercise.

Opened your manual to the Node Reference section. Must just be enormously gratifying that someOne is actually reading that. Noticed that there is no such node as Math_Functions(Add). Just Add. Okay, so I:
def makeSurface():
  s = Surface(1,0,0,0)
  s.Diffuse_Value = Add(0,0)
  return s

Oh hey, this is cool (and somewhat unexpected). The actual value of the Diffuse_Value channel was defined in the
s = Surface(1,0,0,0)
statement, and then, attaching an Add node which does nothing (0 + 0, as in the shader) was accomplished with the
s.Diffuse_Value = Add(0,0)
statement. Remembering, of course, that naming a node creates that node. If a more efficient way doesn't exist (as in what multiply seemed to do further up in a previous example). Cool.

Mind you,
s.Diffuse_Value = .5
will replace what
s = Surface(1,0,0,0)
set.
So, it's about naming a node. Here's what I'm zeroing in on: how these nodes will all connect. Simple connections first. Name a node, and it will create the node, and then connect it to the channel on the other side of the = sign. Or whatever. Gonna have to see how nodes connect to each other!

Open an mt5 file???? as a text file? Sheesh... never thought of that!

Okay, something was not working. I was not surprised.

I'm going about creating this material in MatMatic:


and, quite astonishingly, I've been able to initialize that initial Diffuse_Value of 1 with the
s = Surface(1,0,0,0)
statement. I was even able to set Highlight_Size to .02 with
s.Highlight_Size = .02

But, bump seems to be a different animal. It didn't seem to allow point-anything as a value. Doing a 
s.Bump = .03
did nothing. Nothing at all. So, I felt really thrilled to be able to do:
s.Bump = Sub(ImageMap(""),.5)
and have it create this:

which was pretty close to what I wanted, but I couldn't seem to be able to set the value of the Bump channel for anything in the world. Until I remembered setting values with the multiply. As in:

s.Bump = Sub(ImageMap(""),.5 * .03

And it worked.

Am I even on the right track here? Feels right, but I've been fooled by this before. From a coding standpoint, I'm going to go LONGHAND until I get the whole functionality sorted, then go shorthand.

I might be a bit delusional, but I think I'm getting it?

So far:
def makeSurface():
  s = Surface(1,0,0,0)
  s.Diffuse_Color = WHITE
  s.Specular_Color = WHITE
  s.Highlight_Size = .02
  s.Bump = Sub(ImageMap(Image_Source = "HeaFaceB.jpg", Background = Turbulence(.05,.05,.05,8,0,.5,.15),.5) * .03
  return s

gives me:

...so, oh hey! This is happening. Whether I'm doing it right or not is besides the point. I'm gonna create this material in MatMatic. Pretty sure, at this point.

I've got that bit re-created. Now, for that massive connection to the Alt_Diffuse channel. Might have to create some functions that create some nodes, which I'll create by calling the function???? Can that WORK???!?!?!?

You are definitely on the right track.

You correctly figured out that to set the multiplier value for the bump, you multiply whatever you're plugging in with the multiplier you want. That's all it takes.

s.Bump = .03 * someNodeHere

The reason this did not seem to work:

s.Bump = .03

Is because Bump is a "sleeper" channel. It doesn't wake up unless you plug in a node. Setting it to .03 does indeed set the bump strength, but without a node attached it doesn't show you that. But you did set it to .03. If you were to go into the material after loading it and connect anything to the Bump input, you'd find the .03 is there. This means you changed the default value without actually using it yet.

The "long-hand" way is fine. Over time you will come to find the infix notational shortcuts handy, but it is perfectly adequate to usee the long versions. What I mean is:

Sub(ImageMap(""), .5)

is the same as

ImageMap("") - .5

To then set the bump to that and set the bump scale is:

s.Bump = .03 * (ImageMap("") - .5)

or quite often I say it like this:

bump = ImageMap("") - .5
s.Bump = .03 * bump

Wait I said something not true.

Sub(x, y)

means you are explicitly asking for a Math:Subtract node. But sometimes, a ColorMath should be used, not a Math. If you use the infix notation, matmatic will figure that out for you.

Given x and y are both numbers or nodes that yield numbers or grayscale colors, then

x - y produces a Sub node

However, if either x or y is a color then

x - y produces a ColorSub node.

You seem to have figured out that you have two ways to set a node parameter.

First way is to specify the value when you create the node. (Whether the node is the Surface node or some other node, it works the same way.) Second way is to set it later.

So:

s = Surface(WHITE, .7)

does the same work as

s = Surface()
s.Diffuse_Color = WHITE
s.Diffuse_Value = .7

Also notice that 1 and WHITE are interchangeable here - matmatic knows what you mean. So the same thing is achieved with:

s = Surface(1, .7)

Another thing you're doing, but may not realize why you can...

When you construct a node, I let you specify no arguments if you like. In which case, all the parameters are set to their default values.

s = Surface()

As well, you can set them using positional arguments. The first argument is assumed to be the Diffuse_Color. The second is the Diffuse_Value. The third is the Specular_Color, and so on. These are all documented in the node reference.

s = Surface(GREEN, .7, WHITE, .4, .01)

Now when you have a node, such as the Surface node, that has a jillion parameters, it is not fun to have to say all of them just to set the 11th one. So after using any positional arguments, you can then use named arguments.

s = Surface(GREEN, .7, Bump = .03 * Turbulence())

See how I skipped a bunch of parameters and specified the Bump value by name. In the argument list, once you start using named parameters, you cannot go back to position parameters. All the rest have to be named.

Of course you don't have to set any in the constructor. (The "constructor" is that call you make by naming the node you want. It constructs a node as specified.) Once constructed, the object you get back can be further modified as you've seen.

s = Surface(GREEN, .7)
s.Bump = .03 * Turbulence()

Thank you for elucidating this exercise into shader tree development in Matmatic, Bill. The purpose of this thread is a remedial approach to this subject, and your patient explanations and clarifications are enormously appreciated.

Looks like Nodes for Dummies has become Matmatic for Dummies, but I cannot see much validity in creating nodes of any sort in the mat room - except for the dead-boring standard plug-an-imageMap-node-into-a-diffuse_color-channel approach, which is what the material room appears to be used most for, and all the explanations in the manuals address - unless the maths have been appreciated and are correct. I know you created Matmatic to make building and managing materials easier, Bill, but in my mind making node sets (shader trees) using Matmatic (which forces you to LOOK at the math of what you're concocting) is the only proper way until the underlying maths can be seen just staring at a shader tree itself.

Now, I'm going to make a stab at creating functions based on what I perceive the functional groups are in that shader. IOW, I have this feeling that certain nodes can be kinda grouped together based on what they contribute to the finished shader and how those nodes interrelate. Pretty sure that as I try to do this, their relationship will become clearer and I'll finally get my head around this shader.

Note to self: get Matmatic and start using it.

um, i have to disagree.  there are lots of things i've come across because i've seen them be wrong in the previews.  i might try about 20 different combinations of parameters in different nodes, just tweaking off the previews (yeah, i tweak a lot).  even when i test render, i can adjust off of the previous preview and how it rendered.   if i just used Matmatic, i'd have to wait for a render each time i adjusted my parameters, or at the very least go through several steps just to see the results in the material room.  i'd still be on my first hair shader instead of whatever ungodly number i have now.  conversely, if i tried to base my hair shaders on pure math, i'm pretty sure i wouldn't get even vaguely close to what i wanted (as opposed to now, when i'm in the same neighborhood). because each time i change setting, lighting, character and intent, i find i need to change a lot of settings.   same goes for a lot of the adjustments i put into my version of the PR2 (soon to be PR3) skin shader.  sure, i could just put in numbers, but that wouldn't get me the precise skin attributes i want.  i have to see what i'm doing (how pale or dark, how much sss, what color, where, etc.).  GUIs are a good thing in general.

i'm not saying going the pure math route doesn't have it's place, or that Matmatic isn't a wonderful tool.   but if you got the best results by taking a purely command line approah to art, then there wouldn't be any interfaces on CG software.  professionals use tools with GUIs because it's time efficient and produces good results.  they combine their use with scripts for the same reason.

I do both. I do a lot of experimenting in the material room itself, and I too tweak by looking at the preview.

But, just as an example, I experimented for hours in the material room a couple years ago making my candle shader. I got close but eventually I realized I couldn't get to the right look without the math. At that point, I went into matmatic and produced a totally believable glowing candle material in 20 minutes. As soon as I loaded it, I didn't need to tweak anything. It was right, because the math was right. This was a case where artistic subjectivity was irrelevent. I wasn't trying to produce a look that was imagined. I was trying to produce 100% realism, and that involved matching the laws of physics precisely. Guessing at the solution through experimentation wasn't getting me past 80% realism.

The same was true for accurate reflections. I experimented with edge_blend, bias, and gain, and other stuff for MONTHS. Then I quit horsing around and looked up the equations for Snell's law and the Fresnel effect. After 20 minutes of coding up the math, I instantly had a totally perfect model for reflection. No tweaking.

On the other hand, when I set about to make a shader for leather, there were no equations at hand that I could look up. So I did a lot of experimenting in the material room. However, a combined approach was called for here. I had to "discover" the rules of wrinkles in leather, and expressing them took a lot of nodes. I couldn't have arrived at the solution through staring at the preview or renders alone. It was too much clicking. So I'd try different math formulas in matmatic, and study how they looked in the poser surface preview and with test renders. All three techniques are valuable - guessing and rendering, pure math, and a combination.

Works for me, both of you. I guess what I was referring to, CobaltDream, was my predisposition to primarily trust what I see, above and beyond everything else. This was driven home in the case of hyper-colors, where I was coming up with materials that were going to be bogus, particularly if I tried to mix them with other materials.

On another note, every time I think I might be getting closer to understanding something - like how these dad-blamed nodes interact - working with it knocks my confidence galley-west.

Recreating your VR1 shader tree in Matmatic is a good exercise in learning how things connect and everything, Bill, but I think I'll still have to isolate areas and play with them to see what that particular group of nodes do.

So far, this bit:

**def altDif():
  # Plugs into the Alt_Diffuse
  clrPow = Color_Pow(1,1)
  clrAdd = Color_Add(1,1)
  mthDiv = Div(1,1)
  clrPow.Value_1 = clrAdd
  clrPow.Value_2 = mthDiv
  
  # Plugs into Color_Add
  mthMul = Mul(.7,1)
  setDif = Diffuse(1,.7)
  clrAdd.Value_1 = mthMul * RED
  clrAdd.Value_2 = setDif
  
  #Plugs into Multiply
  setCmp = Comp(0,1,"value")
  mthsSt = SmoothStep(1,0)
  mthMul.Value_1 = mthsSt
  mthMul.Value_2 = setCmp
  
  # Plugs into SmoothStep
  mthSub = Sub(1,1)
  mthsSt.Value_1 = mthSub
  
  #Plug into Subtract
  mthClp = Clamp(2,0)
  mthSub.Value_2 = mthClp
  
  #Plug into Clamp
  mthClp.Value_1 = setCmp
  
  fnlMath = clrPow
  return fnlMath

def makeSurface():
  s = Surface(1,0,0,0)
  s.Diffuse_Color = WHITE
  s.Specular_Color = WHITE
  s.Diffuse_Value = Add(0,0)
  s.Highlight_Size = .02
  s.Bump = Sub(ImageMap(Image_Source = "HeaFaceB.jpg", Background = Turbulence(.05,.05,.05,8,0,.5,.15)),.5) .03
  s.Alternate_Diffuse = altDif()
  return s
 
makeSurface()*

creates this much of that above shader:

which is kinda working backwards to what I want to be achieving, which is sorting out WHY. I know, the code is very pedestrian, but mostly it reflects a lack of understanding about the maths behind this shader. I'd need to first set some base materials, and then use maths (which then create the nodes) to make the shader, as opposed to this
bang... add this
bang... add that
approach.

Never mind. Still worthwhile.

Are you building PR1 or PR2? (You said VR1 here) I thought you liked the PR2 shader?

The way you're going about it obscures everything. Even I can't tell what that says. There's too many steps, so it doesn't flow.

I never do this:

clrPow = Color_Pow(1,1)
  clrAdd = Color_Add(1,1)
  mthDiv = Div(1,1)
  clrPow.Value_1 = clrAdd
  clrPow.Value_2 = mthDiv

You're building up a Pow node, plugging in an Add and a Div, and none of them connect to anything yet. This is impossible to follow. You are indeed reproducing the nodes, but nowhere is the idea being expressed.

Here's the idea.

I'm going to calculate a color doing a bunch of stuff. At the end, I need to gamma correct it. I also need to anti-gamma correct my incoming color map. I'm going to put my gamma factor in a node because it's going to be used in several places. I want to be able to edit it in just one place in the material room.

So first I make a node to hold the gamma value.

gamma = Add(2.2).labelled("Gamma")

Now my incoming texture needs to be anti-gamma corrected. This means that I need to undo the gamma correction of the incoming image, so that it becomes linear.

So I need a place to hold my image:

colorMap = ImageMap().labelled("Color Map")

Now I do the anti-gamma, which is simply to raise the colorMap to the power gamma. In Python, just as we use * to mean multiply, we use ** to mean Power.

linearColorMap = colorMap ** gamma

Now I want to run that into a Diffuse node. But I also want to decrease the diffuse amount in proportion to how much my specular is firing. So first I build my specular.

spec = Blinn(1, .4, .4, .4)

diff = Diffuse(linearColorMap, .7 * (1 - spec))

Now I want to combine the diffuse and the specular, gamma correct the result, and run that into Alternate_Diffuse.

s.Alternate_Diffuse = (diff + spec) ** (1 / gamma)

That's all it takes to produce a basic gamma-correcting shader that obeys the law of conservation of energy.

However, the shader you're looking at (PR1, PR2, or PR3 - whichever) has many more things in it than that, which makes it considerably more complicated. You're biting off the most complicated part, the SSS, with no awareness of what it's trying to do or how, and just assembling the nodes that do it. Worse, you're assembling them in the most obscure way.

I never, ever do this:

div = Div(1, 1)
x = # some calculation
y = # some calculation
div.Value_1 = x
div.Value_2 = y

See how the creation of the div is separated from its actual use? That's confusing. At the time you create it, it's not at all clear what it's going to be for. And you have to read a lot of code to figure out that in the end, x / y is calculated.

Whereas, when I say x / y in the code, that's pretty obvious that it is x / y.

I thought I was clear about my lack of understanding about the shader itself. What you've given in terms of your approach to building a shader is a heck of a lot more than I understood before. All I saw was a mess of nodes, so I figured that if I could recreate nodes in Matmatic, I could make some sense of them.

My exercise has one point: I now know how to create a node using code. Beyond that, I'm as clueless as ever.

I've tried it from spots, I've tried it from the imageMap. I've looked at your stuff, at face_off's, read every thread I could. No aha yet.

Gotta fix dinner. I'll put your last post next to my recipe and see if I can get it to assimilate.

The only reason that I separated the creation of the node from its application was to make an object with properties (whatever the proper term is for Python) so I could reference it again when I needed to, further down. Probably not a valid reason, but I have no idea how to do otherwise.

Starting over again. This doesn't scare me. Nothing does.

In answer to your first question, Bill: PR2.

The reason my so-called code makes no sense to you is because I'm coming at it from the standpoint of: "let's make this set of nodes I see in the shader tree". At the end of the day, that exercise means nothing, because I haven't really built a shader based on maths: I built it on parroting what I see in a shader tree.

Useless.

Back to the drawing board: that method of discovery isn't going to work!

Quote - The only reason that I separated the creation of the node from its application was to make an object with properties (whatever the proper term is for Python) so I could reference it again when I needed to, further down. Probably not a valid reason, but I have no idea how to do otherwise.

That's no problem, I'm just trying to show you the clean, readable way.

For example, if you wanted to calculated a ratio between two things, a and b, and use it later, instead of:

ratio = Div(1, 1)
ratio.Value_1 = a
ratio.Value_2 = b
....
somethingUsing(ratio)

It is clearer if you say:
ratio = Div(a, b)

or even better:
ratio = a/b

just posting to say, totally agreeing.  i'm not trying to say math is irrelevant, just that after you get the basic structure, sometimes it helps to have the preview to decide on things like your parameters for things that aren't really set.  i can have your skin shader, or even my weird version of it, but that doesn't tell me what skin i'd like to duplicate, because that's in my head. especially because textures vary so much, i need to see the effect on them as i'm making my choices.  it's amazing how a small shift in hue or value can make a big difference.

Yes that's the ticket. The VSS PR3 skin shader has a ton of very specific math in it that is not subjective. However, the precise color and amount to use for the SSS is going to depend on the texture you're using and how much baked in SSS is already there. So too will the Tint need tweaking depending on what you're starting with and what you're trying to change it into.

That's why I make the shader node setup in matmatic, and I carefully segregate all the interesting and important parameters on the left side. The nodes on the right side are the math and you have no need to subjectively manipulate those, for the most part. And I do look at the preview for quick feedback on how those parameters are changing the final outcome. I don't plan the values for those parameters in matmatic, but I do plan and implement which values are going to be segregated in matmatic, for tweaking later in the material room.

You're going to get so sick of me, Bill...

Following your example - double-checking to make sure I got it entered right, and commenting to keep it clear to myself what's actually going on here:

def makeSurface():
  s = Surface(1,0,0,0)
  s.Diffuse_Color = WHITE
  s.Specular_Color = WHITE
  
  # keeps diffuse_color from doing anything but just displaying in the pose room
  s.Diffuse_Value = Add(0,0)
  s.Highlight_Size = .02
  s.Bump = Sub(ImageMap(Image_Source = "HeaFaceB.jpg", Background = Turbulence(.05,.05,.05,8,0,.5,.15)),.5) *.03
  
  # --New Stuff! Bill's ....
  # Gamma-correction node
  gamma = Add(2.2).labelled("Gamma")
 
  # Placeholder for colorMap
  colorMap = ImageMap().labelled("Color Map")
 
  # Anti-gamma process
  linearColormap = colorMap ** gamma
 
  # Set up specular node
  spec = Blinn(1,.4,.4,.4)
  
  # Set up the Diffuse node, keep it from exceeding conservation of energy with Specular
  diff = Diffuse(linearColormap, .7 * (1 - spec)
 
 
  s.Alternate_Diffuse = (diff + spec) ** (1/gamma)
  
  return s
 
makeSurface()

I get a syntax error on that s.Alternate_Diffuse = (diff + spec) ** (1/gamma) line. The error reads:

----- MATMATIC COMPILER -----
verbose 1
Processing script C:Program Filese frontierPoser 7RuntimeLibrariesMaterials!RobynsveilScriptsVR2_005.mm1.txt -> material
MATMATIC Script Error: invalid syntax (VR2_005.mm1.txt, line 27)
Traceback (most recent call last):
  File "c:program filescurious labsposer 6runtimepythonmatmaticcompiler.py", line 233, in processScript
  File "C:Program Filese frontierPoser 7RuntimeLibrariesMaterials!RobynsveilScriptsVR2_005.mm1.txt", line 27
     s.Alternate_Diffuse = (diff + spec) ** (1/gamma)
     ^
 SyntaxError: invalid syntax
------ MATMATIC COMPILER DONE -----

I'm at a loss.

Simple, though not obvious.

The error is that you didn't finish the previous line. You're missing a close paren )

Sheesh... thank you, Bill... same thing used to happen to me in FoxPro. I really should know better.

Thanks for that, and for pointing me in the right direction with regards to the shader.

Worked a treat, Bill... thanks.

Now I can see even more clearly how completely erroneous my approach was in terms of sorting out what the shader nodes were doing. Your script cranked out 13 nodes. Trying to go backwards from the shader tree to try to sort out how it was created and why the nodes were there would have been impossible (at least, for me - this was an exercise in futility).

So, back to it. I'll see if I can somehow get spots in there again - I did like that, or perhaps come up with some skin-like texture of my own to somehow insert somewhere. However, it will have to co-exist (as in: values accounted for) with the spec and diffuse values... might make it part  of diffuse... kinda fleshing it out (so to speak).

The simplest way to incorporate some extra pigment, as spots, is to tint the color before connecting it to the diffuse node.

So make a spots, with white in one color and a very pastel color in the other. You could look at the spots node I did in the VSS shader for the values.

spots = Spots(... put your values here)

color = linearColormap * spots
diff = Diffuse(color, ...

At this point, tweaking the shader is the least of my worries. Battling with syntax is.

What have I "learned"?... lights have gone on for a few things:

1. Naming a node function (like say an Add or Blend or ImageMap) in another node function will create that node and form a connection at the point the function was named. For example, in this statement,

s.Bump = Sub(ImageMap(Image_Source = "HeaFaceB.jpg", Background = Turbulence(.05,.05,.05,8,0,.5,.15)),.5) *.03

several nodes are created... a Math_Functions(Subtract) node, a imageMap node and a Turbulence node. There's a connection between the subtract node and the imageMap node because I named it in the Value_1 argument. I wanted a Turbulence node connecting to the Background channel on the imageMap node... the

Background = Turbulence(.05,.05,.05,8,0,.5,.15)),.5)

bit created the node, inserted the values into the channels of the Turbulence node, and formed the connection to the Background channel of the ImageMap node. All of these nodes are connected to the Bump channel on the PoserSurface node. Another thing I noticed was that whilst I was committed to naming each channel I was putting values into when I did start naming, I didn't have to name any I wasn't changing. In other words, in,

ImageMap(Image_Source = "HeaFaceB.jpg", Background = Turbulence(.05,.05,.05,8,0,.5,.15))

all I was changing was the Image_Source and Background channels... didn't have to do anything with any of the others.

Oh, and that .5?
Value_2 in the Subtract node.

And the * .03?
Assigns the desired value in the Bump channel of PoserSurface.

1. When Bill says once you name parameters, you need to keep naming them, he meant it. Not only for the rest of that node function, but for any embedded node functions as well! Found that out through a gazzillion error-compiles.

2. Oh, and I really like the .labelled("MyCoolNode") thingie you can tack on at the end of node definitions.

I do have some questions, but I think I'll have a re-read of the manual before asking them. This is starting to be fun again...

What's that in your point #2? Not sure what you mean by "for any embedded node functions as well". That's not true. If it was, your Turbulence constructor wouldn't have worked, right? Your Turbulence constructor is all positional arguments - nothing named.

Another tidbit: It is perhaps documentary that you say:

ImageMap(Image_Source = "HeadFaceB.jpg", ...)

but it is unnecessary and I don't commonly do that. The first argument to imageMap is the file name, so I always just use:

ImageMap("HeadFaceB.jpg", ...)

Of course, the three dots don't mean you should type three dots - just stands for whatever else you want to say there, or perhaps nothing.

Hate to ask this question, but needs must.

Suppose I want to change the colour of of the Spot_color channel in a Spots node AND attach another node to that channel. First the background stuff:

**# Placeholder for colorMap
  colorMap = ImageMap(Image_Source = "HeaFace.jpg").labelled("Color Map")

Colours to fiddle with

  ltBeige = (.98,.94,.88)
  ltBlue = (.91,.95,.95)

SimpleColor node - constructed here because I'm going to connect it to two places

  baseTone = SimpleColor(Color = ltBlue).labelled("BaseTone")**

This bit:
**
  setSkin = Spots(Base_Color = baseTone,
    Spot_Color = ltBeige,
    Spot_Size = .1,
    Softness = .35,
    Threshold = .7,
    Noise_Type = "Improved").labelled("Complexion") **

makes the nodes and sets the values in the node channels, but this lacks a connection from from the Spot_Color channel to my BaseTone node.
**
  setSkin = Spots(Base_Color = baseTone,
    Spot_Color = baseTone,
    Spot_Size = .1,
    Softness = .35,
    Threshold = .7,
    Noise_Type = "Improved").labelled("Complexion") **

forms the appropriate connections, but the colour in the Spot_Color channel isn't what I want.
**
  setSkin = Spots(Base_Color = baseTone,
    Spot_Color = baseTone * ltBeige,
    Spot_Size = .1,
    Softness = .35,
    Threshold = .7,
    Noise_Type = "Improved").labelled("Complexion")**

forms a multiply node connected to my Spots node with the ltBeige value in Value_1, and connected to my BaseTone - SimpleColor - node with the Value_2 channel.

How do I do both with one Spot_Color = statement?

Quote - What's that in your point #2? Not sure what you mean by "for any embedded node functions as well". That's not true. If it was, your Turbulence constructor wouldn't have worked, right? Your Turbulence constructor is all positional arguments - nothing named.

Another tidbit: It is perhaps documentary that you say:

ImageMap(Image_Source = "HeadFaceB.jpg", ...)

but it is unnecessary ...

On the tidbit: I agree. Not necessary especially once you know the arguments of a given node by heart. Useful for learning purposes, perhaps.

And on your first observation: yes, you do have a point. Not sure now why I thought that... must be an erroneous conclusion based on making more than one change to a problem statement. Thanks for pointing it out.

Ah, you've found one of those cases where the freedom to use any type of object (typeless algorithms) gets you in trouble. You used a data type that wasn't planned for, and it actually worked, but not the way you had expected. But the fact that it worked at all is kind of amazing, if you think about it. That would not have happened in most other languages.

The multiply syntax is the correct one.

Spot_Color = baseTone * ltBeige,

But you got a multiply node, as if matmatic did not detect there was a simpler way. And the reason it didn't detect it is because you did not make ltBeige a Color. You made it a generic Python tuple:

** ltBeige = (.98,.94,.88)**

That looks sort of like a color, but it's not MARKED as a color. It's just 3 numbers. Matmatic did the best it could with that. You said you wanted to multiply that tuple with your baseTone, so it did that. It did not optimize away your multiply, because it wasn't sure it was allowed to.

Matmatic will only make color math optimizations if you work only with numbers, Colors, and Nodes. Instead you involved a tuple - and that confused it.

The correct way to make a Color is:

ltBeige = Color(.98, .94, .88)

If you had made ltBeige point to a color instead of a tuple, all would work as expected.

I noticed another little mistake. I think I forgot to explain this in the manual.

Most Node parameters are colors or numbers. But a few are switches, or pulldowns, and one is a filename.

The only kind that is supposed to take a text string is the filename kind. (ImageMap and Movie)

In your script you wrote:

**Noise_Type = "Improved"
**
That may be working but I doubt it. If it is, it is an accident.

Poser represents the pulldown choices as numbers, not the words you see on the pulldown. I probably should have done the translation for you in matmatic, but that didn't come to mind. So you're supposed to put a number in there. You can figure out the number by using the pulldown in the material room and counting. The first choice is 1. The second choice is 2.

For Noise_Type, the choices are Original and Improved. So to get Improved, you should say
Noise_Type = 2

For checkboxes, the values again are numbers - why I don't know. For true/yes/on use 1. For false/no/off use 0.

I checked the node reference on that Noise_Type parameter.

Poser files claim the legal range of values is 0 to 1 and that's what I copied into the manual. At the time, I thought some of these were bogus, but until I fully understood everything, I just copied the information as given by Poser. However, that is incorrect.

For Noise_Type, the legal values are 1 or 2.

To answer your last point first: you were right... the Noise_Type was still set to Original. So, I've made that change - set it to 2, which worked - and thanks. Made that cardinal error of assuming values: your docs did say the range is number from 0.0 to 1.0, so I should have at least gotten the clue that it wasn't looking for a string. Interesting that it didn't generate an error, but that's a data-type thing, so I guess it wouldn't, hey?
Anyway I've update my copy of your docs (nice thing about html... you can just fix it). BTW, can one assume that to be the case for any of the drop-down selections? Integer 1 to 2 instead of number 0.0 to 1.0?

I've just add that information from your first response to my question - the one about why my multiply-to-enter-colour-value-thingie wasn't working as expected - into the little Nodal Bag of Tricks I'm compiling. I must say: at least you assume nothing: your explanations are clear and complete. And gratifyingly verbose. When I read all this a year from now, it will still make sense.

Once again, thank you, Bill.

Quote - BTW, can one assume that to be the case for any of the drop-down selections? Integer 1 to 2 instead of number 0.0 to 1.0?

Yes all the dropdowns behave that way, as far as i know.

Quote - You can figure out the number by using the pulldown in the material room and counting. The first choice is 1. The second choice is 2.

... and the third choice is 3, and the fourth choice is 4 and so on.

By the way, I found this in the matmatic manual in the Writing Scripts - Basics page.

Quote -
NOTE: I got all these defaults and ranges by tediously creating each type of node in Poser and saving it, then examining what Poser wrote. The ranges don't always make sense. In any case, I have found that Poser doesn't really care if the value is in the legal range or not. But I've decided to document the ranges in case you need to know what Poser thinks about these numbers. Matmatic surely doesn't care. Also, a couple were just wrong. For example, Poser writes that Noise_Type can be from 0 to 2. But 0 isn't legal. So I've changed a few of these where it matters. In this case, Noise_Type=1 means old style noise, and Noise_Type=2 means Improved noise.

That quote was talking about the Clouds node. Other nodes were documented differently. I seem to have missed correcting some of them.

What follows is a rough attempt to follow your instructions, Bill. Still need to do the maths thoroughly... kinda did them, but wasn't sure if I was doing them correctly:

**def makeSurface():
  # Gamma-correction node
  gamma = Add(2.2).labelled("GammaCorrection")
 
  # Placeholder for colorMap
  colorMap = ImageMap().labelled("Color Map")
 
  # Colours to fiddle with
  ltBeige = Color(.98,.94,.88)
  ltBlue = Color(.91,.95,.95)
  
  # Underlying skin tone
  baseTone = SimpleColor(ltBlue * colorMap).labelled("BaseTone")
  
  # Complexion
  setSkin = Spots(
    Base_Color = baseTone,
    Spot_Color = ltBeige * baseTone,
    Spot_Size = .1,
    Softness = .35,
    Threshold = .7,
    Noise_Type = 2).labelled("Complexion")
 
    # Anti-gamma process: felt I had to take the baseTone value out once because it was added
    # into the setSkin twice
  linearColormap = ((colorMap + setSkin) - baseTone) ** gamma
 
  # Set up specular node
  setSpec = Blinn(1,.4,.4,.4)
  
  # Set up the Diffuse node, keep it from exceeding conservation of energy with Specular
  setDiff = Diffuse(linearColormap, .7 * (1 - setSpec))
 
 
  
  # Setting up PoserSurfacce
  s = Surface(1,0,0,0)
  s.Diffuse_Color = colorMap
  s.Specular_Color = WHITE
  
  # keeps diffuse_color from doing anything but just displaying in the pose room
  s.Diffuse_Value = Add(0,0)
  s.Highlight_Size = .02
  s.Bump = Sub(ImageMap(Background = Turbulence(.05,.05,.05,8,0,.5,.15)).labelled("Bump Map"),.5) * .03
  
  s.Alternate_Diffuse = (setDiff + setSpec) ** (1/gamma)
  
  return s
 
makeSurface()
**
Render reveals I'm using a really poor colorMap - seams everywhere!

two lights:
Infinite 1,256,1,1,1,65%, depthmap shadows...  :-P, no ambient occlusion
IBL 1,256,1,1,1,22%, no shadows, nothing else...
and I'll need to do a mask for the freckles and sheesh, all kinds of other stuff too. This is all very rough and I'll be playing much more with it, but I'm so excited about the fact that I've gained some confidence and understanding... mind you, still a huge way to go.

Is this shader valid? Probably not yet...

Here is a side-by-side between VSS PR3 and the shader you made here. Can you tell which is which?

I don't think one is better than the other - they're different, for different effects. The beauty of matmatic  + VSS is you can create and test so much more quickly. Now that you've got the basics down and understand the workflow, you will progress rapidly! I'm very excited for you. I wish we weren't half a day apart in time zones.

Bill, you have no idea how delighted your post made me! Thank you for your validating words.

In past posts, you made a point about having a collection of math formulas - well, that's how I remember it, anyway - to use as a basis for the creation of realistic materials. In the light of what I've been able to assimilate so far, this seems to be the next step for me... that, and a working familiarity of the behaviour of Poser nodes. My impression is that skin shaders are by nature of the material (skin) much more complex than, say, non-organic materials such as gems. However, looking at the leather shader of yours and that silk shader of Stefan Leng makes me realise I have a lot to find out about the properties and behaviour of nodes in order to make appropriate selections in order to get the effect I want. Oh, and math. Yep. Made a collection of math functions you introduced in previous pages... great for checking the validity of a shader and the maths behind it.

After all, you did give me the ingredients for this shader, Bill. I looked at your PR2 shader and your earlier post and suddenly that mess of nodes kinda all went into their functional corners. I saw what you'd done (even though you'd done it manually in the mat room), and to some degree was able to reproduce it in a Matmatic script. Most importantly, NOW I can use that shader with an understanding of what it's doing, because I've finally got a glimmer of understanding about the maths behind it.

Oh, and yes, I did use VSS to distribute the shader to the different material zones... never ceased to amaze me, that tool!

If nothing else has come of this - well, got the shader I wanted, but anyway - I now share your enthusiasm for using natures laws when creating materials.

Thank you so much for your patience and the time you've spent on this, Bill!!!

RobynsVeil: Congratulations, and many thanks for posting the code. Maybe I'm biased, being a programmer and all, but I find this so much easier to understand than Material room diagrams or elaborate prose.

Now, where's the program that analyzes shader trees and translates them into Matmatic scripts? :biggrin:

hehehehe

No such program. I tried that, odf - working backwards - but that mess of nodes only made sense once I started applying the maths in formulas in the script and saw what nodes were generated. You do gain a very good understanding of nodal function by writing these scripts... shader tree node assembly kinda becomes a product rather than a process.

So, the maths behind the material is everything... the shader tree is just something that comes of it. Yeah, you can tweak it from there, but you want to be careful.

OK, now that the first rush of success is behind you, we have a little work to do.

Did you know that part of the color math you wrote cancels itself out?

I'm assuming that you intend for baseTone to be a tinted version of the color map, and that by adjusting that color, you can adjust the overall tone of the skin.

But let's look at the math.

baseTone = SimpleColor(ltBlue * colorMap)

Simplifying (because the SimpleColor node doesn't change anything) we see this is:

baseTone = ltBlue * colorMap

Now let's look at your Spots node. Some pixels will be Base_Color and some will be Spot_Color. Let's look at these one at a time.

For the pixels that are Base_Color, (via the spots node) you're setting:

setSkin = Base_Color = baseTone = ltBlue * colorMap

With me? For those pixels, all four of those are the same.

Then you do:

linearColorMap = ((colorMap + setSkin) - baseTone) ** gamma

But given the above equality that's the same as:

linearColorMap = ((colorMap + baseTone) - baseTone) ** gamma

Which reduces to:

linearColorMap = (colorMap) ** gamma

Hmmm. The baseTone doesn't do anything on those pixels.

It does do something on the Spot_Color, but I'd not call it a predictable effect. We could run through the math, but it's not really worth it.

Aren't you trying to tint the colorMap altogether, using ltBlue into the baseTone? And then you want to run that through the spots, so that all the skin is colored by baseTone, and some of it is colored by the spots color? If so this is much clearer:

linearColor = Spots(baseTone, ltBeige * baseTone, ...) ** gamma

See that? I feed the original baseTone and the product of ltBeige times baseTone (that's tinting it) into the Spots. The result is either baseTone (ltBlue * colorMap) or a tinted baseTone (ltBeige * ltBlue * colorMap). In other words, the base color is tinted, and the spot color is double tinted.

So, do away with the SImpleColor node, and do tinting in the Spots node?

No you don't want to do away with the SimpleColor node. That's what let's you change the tone in one place.

The issue is that the math you did at the end cancelled out the SimpleColor node. Not that I want to get rid of it, but rather I want to make it do something.

The math you did here:

((colorMap + setSkin) - baseTone

Cancelled the SimpleColor node's effect away.

You just want to use setSkin - that's the final color after all the tinting is done.

You do not want to undo the tinting by add the color map and subtracting the baseTone. All that does is remove the baseTone and add back the colorMap, thus making the whole baseTone thing do nothing.

Imagine a food recipe.

Take some chocolate. Mett it, blend with lemon and honey. Then remove the chocolate_lemon_honey blend from your mouth and add chocolate.

That's the same as "eat chocolate".

Tell you what was going on in my pea-brain, Bill... once again, I was going by visual feedback, and drawing conclusions from there, instead of looking at the maths and basing design on that.
That:

linearColorMap = ((colorMap + baseTone) - baseTone) ** gamma

equation was based on the assumption that I was creating a hyperColor because of the node set - Spots and SimpleColor - I'd made: it caused a visible bloom before I inserted the "- baseTone". So, removing it in the above equation got rid of the bloom, but didn't really give me what I I was after.

You did the tinting in an equation after the spots node was set, didn't you? In that linearColor equation. So I can affect colours for the Base_Color and Spot_Color channel after I've constructed the node - only thing, it'll affect all channels with a colour, right. This is cool....

Well remember there's multiple places to do the tinting.

(Tinting is just multiplying with a pastel color.)

You can do it like this:

Spots(tint * originalColor, tint * originalColor * anotherTint)

or

tint * originalColor * Spots(WHITE, anotherTint)

or this is how I usually write it.

color = originalColor
color *= tint
color *= Spots(WHITE, anotherTint)
color *= ANodeThatTintsForVeins(...)
color *= ANodeThatTintsForMoles(...)
color *= ANodeThatTintsForPimples(...)

See? Each tinting layers onto the previous one. And if I want to remove one of them by commenting it out, then I just have one line to comment out. The chain of evolving color is kept in the color variable.

Anyplace you don't want it to tint, such as the base of the spots effect, you just use WHITE, or the number 1, because that is white. When you mutliply with WHITE, it does nothing. In other words, WHITE cannot tint something.

Quote - You did the tinting in an equation after the spots node was set, didn't you

Yes and if you were trying to copy me, you did the wrong operation. You did addition (+). I did multiplication (*). Tinting is multiplication, not addition.

You're right, by doing addition you produced a hyper-color. But the correction did not require a further subtraction. The correction is to do the right math in the first place.

Tinting (multiplication by a proper color) cannot produce a hyper-color or a hypo-color, unless you're starting with one of those in the first place.

So, is my lighting off because of the gamma correction, then, or there is something still wrong with my maths? Because the bloom is back when I take that - baseTone statement out. Obvious used the wrong solution for the bloom problem...

Used the revised shader on the face only: same lights and everything.

Staring at the code...

Oh.
The linearColor equation. Duh!
Singing "I'm an idiot and that's okay!"... Lumberjack song....

Fixed it. Works.

Sheesh!