First, a caveat. What I am introducing here in this initial post of the Nodes for Dummies thread is not gospel: it is a synopsis - a digestion, if you will - of my understanding of some of the behaviour of Poser material room nodes based on a series of discussions with CobaltDream, who has been instrumental in clearing up a number of burning questions that prevented my understanding much of what was being discussed on the "VSS Skin Test - Opinions" thread on this forum. Since that thread has so many sub-threads that it has become a bit unwieldy, I've decided to start this separate thread so that Those-That-Know can continue their discussions on VSS unmolested. VSS is Versatile Shader System, a Poser material-room tool developed by Bagginsbill to manage material shaders - node sets - across the range of an object's materials. It's a rules-based system, and really quite clever, allowing you to manage quite complex objects with hundreds of materials.

I'll start with a few definitions.
NODES: Poser has several "rooms", one of which is the material room. In the advanced tab area, one can do clever things with object material surfaces using little boxes called nodes, each of which have a special purpose. For the material itself there is always at least on "mother" node called PoserSurface which has a column of boxes and what look like little plug-in points: these are called channels.
This PoserSurface nodes (or node group) has been discussed at length in other places, so we're not going to touch on it here for the time being.
COLOURMAP: In deference to Bagginsbill's preferences, I'm going to refer to the image and the node that stores it as "colourMap", which sets free the word "texture" for other meanings. To create one of these:
New node >
2D Textures >
image_map
...and then in the Image_source box, click on it and with Texture Manager, click on browse and navigate to the image associated with that material. This is the most common use of the material room and if you look up "nodes" in Poser manuals and such, invariably this is what will be thoroughly explained, because this is what is best understood. Nodes as such will be glossed over, and that is the purpose of our discussion her: to promote a better understanding of how that all really works.

What really got me started wanting to learn more about nodes and their behaviour was a desire to do make-up for my characters not using "painted" colourMaps - painting make-up colours on the base colourMap of the face. In the above-mentioned thread, Bill kinda got me started doing make-up using masks and the Blender node in his PR3 skin shader, an elaborate 55+ node skin node set. I quickly found myself becalmed - no wind for my sails - as I had no idea what most of the nodes were doing, a knowledge essential to being able to manipulate them. It was suggested that I do some experiments which I have documented here, here and here.

As you read these pages you can easily discern that I was floundering. I was rowing madly around but with no idea in which direction I was going. I had no point of reference.

At this point, CobaltDream came to the rescue. I feel an intense debt of gratitude to her for shedding light on what those on that thread pretty much held as common knowledge, but which I for some reason was failing to grasp. That gratitude has resulted in an effort to share this knowledge with you in such a way that it is plainly accessible to any and all who really wish to know and to hopefully stimulate some discussion and perhaps even some experiments that will help clarify to our minds what nodes do what and when we'd want to be using them.

To me, colour is just colour. When I refer to colour, I generally think of the colour of an object. An essential part of colour is light: without light there is no colour. In Poser, colours are a combination of three basic colours: red, green and blue. Most paint and image programs such as Photoshop, PSP and the GIMP use this same colour combination thingie as well. The colour standard that we subscribe to - as in, most commonly use - for our monitors and internet and images and all that is called sRGB, thoroughly described here.

So, colour is just that: colour. An image (picture of something) is a combination of a whole bunch of different colours one pixel in size. That's how I think of colours: this way of thinking created one of the biggest obstacles to understanding some of the nodes like math nodes can change a colour.

This next bit is key to understanding nodes that use maths to change colour, so pay close attention.

Colours can be represented as numbers. There are a fair few ways to use numbers to represent colours. This is nothing new to anyone, but I'm mentioning it for the sake of completeness. In Poser we see two numbering systems in action: in nodes, the range a colour can go to is from 0 to 1, 0 being totally black or absence of colour, and 1 being white. Another numbering system goes from 0 to 255, with 255 being all white. You'll see this system when you use the Microsoft colour picker:

Since Poser nodes don't do maths in that 256-base system, the first thing we do with colours represented in the 256-based system is convert them to the decimal system... that is: that numbering system that goes from 0 to 1 I mentioned earlier. The conversion is quite simple: one divides each colour (Red, Green and Blue) value by 255 to get the decimal value.
For instance, for the red colour you see in the image above, you would convert Red, which is 255, to the decimal value by dividing it by 255:
255/255 = 1
So, Red is 1
0/255 = 0, so Green and Blue would both be 0. So, for Poser, the RGB value of 255,0,0 is 1,0,0.

This way, Poser can do maths on this decimal value.

Make sense so far?

For the most part, though, we really don't have to worry about doing any conversions, since Poser handles those conversion maths internally. However, it is important to understand how the decimal numbering system works, since we're planning on changing or affecting colours by doing maths. For instance, when we do maths on a colour, we do it on all three (RGB) simultaneously.

Let's test all this out. Let's say we've got a the colour green, which is 0, 255, 0 in the Microsoft colour picker, or 0, 1, 0 in Poser's decimal system. Let's add Red to it, which is 255, 0, 0 or 1, 0, 0.
    1, 0, 0    or   255,     0, 0
+  0, 1, 0   or        0, 255, 0

   1, 1, 0   or   255, 255, 0
  
or yellow.
So, one can do maths on colours and get meaningful results. We haven't done anything earth-shattering at this point, but we've established a good starting point, I'd say.

Comments by Those-Who-Know are always welcome and indeed, encouraged!

Just in case Those-That-Know come and have a look, these questions may put them off. I hope not, but they are the kinds of questions we Dummies have. Probably the questions that kept me out of the really good schools, too. But heck, I'm gonna ask them. Maybe other readers will be like: "hey, you know, I was wondering that exact same thing!"

One of the first questions I had when I first saw a math node used in the Poser room was: why? What is the purpose of doing math on a colour? Why not just change a colour manually?
We know that adding 1, 0, 0 (Red) and 0, 1, 0 (Green) gives us 1, 1, 0 (Yellow). Is it really all that useful to be able to do it with nodes? That question vividly illustrates the depth of my ignorance of what can be done with nodes, but only because I haven't gotten to a point where I need to be able to manage a colour with a means other than manually.

When I was learning Visual Basic, there was a lag time between noting a function exists and saying: "whoa, that would be perfect here!". It's only as one starts to have specific needs does the strength of nodes become clear.

It has been suggested by Those-That-Know that experimentation in the material room with nodes is a key means of clarifying in the mind what does what and how (and hopefully, one can even postulate some whys). The above-mentioned needs will arise, so experiment we shall.

One of the things that I picked up in my travels of reading posts by Those-That-Know is: the Diffuse_color channel of the PoserSurface node has a heap of stuff going on behind it. Our first experiment is going to illustrate that point.

Let's create a high-resolution sphere from the Poser Primitives collection in Poser. To assign some materials to the top half and the bottom half of the sphere, click on the Grouping tool icon on the Editing Tool bar. This brings up the Grouping Editor dialogue.

What I did to make the top and bottom half of the sphere different materials, I first went into Camera Front View. On the upper left of the dialogue I selected "New Group" and called it "Top". With my mouse, I press down on the left-mouse button and drag diagonally over the top half of the sphere: a rectangle develops covering the visible area (i.e., the area facing you) you are selecting. When I let go, the top half of the sphere is highlighted in red. I click on "Assign Material" under Geometry Functions in that dialogue and type in the name of my new Material: calling it "Top Half". Voila, you've got a new material on the front of the top half of your sphere.

Do the same for the bottom half: I called the group "Bottom" and my material for that group "Bottom Half". I know: highly imaginative. We're going to go into the Material Room now, and select the Sphere Obect, and Top Half material. I've added a spots node and other stuff to the bottom for contrast.

Using the above maths concept, we're going to add Green and Red: 0, 1, 0 + 1, 0, 0 to get 1, 1, 0. We'll use the Color_Math node.

So, create a new Node:
New node >
Math >
color_math

Leave the default for Math_Argument, which simply means "what kind of maths this thingie actually does.
Change the colour of Value_1 to red... make sure it's 255, 0 , 0 in the Colour Picker.
Change the colour of Value_2 to green... make sure it's 0, 255, 0 in the Colour Picker.

Cool. A tool for adding Red to Green.  Our first node! WooHOO. Purpose as yet unknown, but that will eventually become clear. So we plug this into the Diffuse_Color channel of our PoserSurface. And let's render.

That's not yellow.
Read something about the Diffuse_color channel does a fair few things - like, heaps of stuff! Not sure what all it does, but it sure changes the colour a lot.

Also read that if you just want the nodes to control what you're doing, then disable the Diffuse_color channel and plug into the Alternate diffuse channel. Only your nodes will control things. That's what I'm led to believe!

Yep, that's yellow.

The biggest question is going to be: have I come to bogus conclusions about the Diffuse_color channel? is there something it does with the lights in the scene which makes the render come out less yellow?

The Diffuse_Color and Diffuse_Value channels are actually the exposed bits of a built-in Diffuse node.

To understand the PoserSurface, at least as far as these two channels go, then we must understand the Diffuse node.

Are we ready to do that?

Oh yes, Bill. Please do explain.

Under the surface there are a number of maths concepts, right? As in: functions. In both nodes? But more in the Diffuse_color channel? Is that why do they behave differently?

I'm ready too.

Count me in, too!

I'll toss in the link to the sticky  thread called "Material Room, Nodes & Shaders - Tutorials and Discussions (Bookmarks - Updated)"

Material Room, Nodes & Shaders - Tutorials and Discussions (Bookmarks - Updated)

Right. So, one of the conclusions we can draw from that last experiment was that the Alternate_Diffuse channel on the PoserSurface node doesn't do much else than just accept whatever we put into it - in this case: a color_math Add node that adds pure red (1, 0, 0) and pure green (0, 1, 0) to give pure yellow (1, 1, 0). That said, the Diffuse_color channel must be doing something more. What that 'more' is we'll leave to Those-That-Know to enlighten us with.

I've learnt from BagginsBill that in order to let the Alternate_Diffuse channel to have complete control over what gets put onto the material's surface, you're best turning the Diffuse_Color channel off. How, you ask? There are a number of methods, actually - if you stick with us, you'll eventually find out how, and how and when to use one technique versus another - but the simplest is to simply set the Diffuse_Value channel value to 0, which turns that whole channel off. Now, the Alternate_diffuse channel has complete control.

Since my experiments in the PoserSurface node has left me more puzzled than anything about what's really going on under the surface, let's just assume - based on behaviour - that the Alternate_diffuse channel gives us complete control over what we're doing.

Agreed?

Now, we've got this so far:

We now know (or at least we think we know) what the behaviour of the color_math Add node is. That is: what you are seeing and what it is doing is: simply doing the maths I've outlined above. We are adding red and green to give us yellow. We've got a grip on one node.

What happens if we turn the node into a Subtract? What is 0,1,0 minus 1,0,0?

0,1,0?

Red: 0 - 1 = -1 ... does Poser allow negative values?

My experiments show no. It seems that subtracting that value (1) from 0 only leaves 0. Have a look at this image. I'm subtracting red from green. There is no red in green. So, subtracting red from green leaves green. Not some weird shade of green but just green.

This is cool to know. Let's take this one step further. First of all, we're going to get clear in our Dummies minds what "Green" is to Poser. It's 0, 1, 0. We know that? Right? This is an absolute. To Poser, when you say "Green", it thinks 0, 1, 0. We can use that.

That color_math Subtract node is going to come in real handy if we want to take all green out of an image. Let's test it. We're going to subtract green out of yellow. What does that give us? Heck, I don't even need to do a render!

The Color_math node. Does pretty much what it's going to say it does. And at this point, the Alternate_diffuse channel on the PoserSurface node lets us see these effects for ourselves. Why? Bill knows. I'm sure he's preparing a carefully-constructed explanation for us, and for that I'm already considerably in his debt. At this point I'm just elated to have predictable results based on his guidance.  I just know that what he's going to have for us is going to be gold.

Yep, read all those links, hun, but they all left some burning questions, Acadia. Essentially the same questions you had some time back which you might have found were satisfactorily answered with gastronomic metaphors, but being the Dummie I am, I need pretty much the a + b = c type of answer.

Hence the name of this thread.

What we're looking at here is node behaviour with an objective - essentially the same objective you had, incidentally - knowing what to use why and how. Apparently there have been heaps of experiments done by Those-That-Know to validate nodal behaviour. None of this is published anywhere.

So they know, and the rest of us don't.

This is an effort to fill that gap. I'm not just going to do experiments and keep them my little secret. I want ALL Poser users who want to get the noggin around material room nodes to take advantage of my experiments, as pathetic as my experiments might be. Means THEY don't have to do them, right?

Now, if that exercise has been done in any of those links I missed it. Please point it out to me if it has been done, because what I am am undertaking is massive and daunting but it must be done!

Quote - This is an effort to fill that gap. I'm not just going to do experiments and keep them my little secret. I want ALL Poser users who want to get the noggin around material room nodes to take advantage of my experiments, as pathetic as my experiments might be. Means THEY don't have to do them, right?

Now, if that exercise has been done in any of those links I missed it. Please point it out to me if it has been done, because what I am am undertaking is massive and daunting but it must be done!

Robynsveil... I'm completely in agreement with the need for this, and I'm following it. I know a bit about using the advanced material room, but I've always felt I'd like to start again and learn the basics -- the bits that were skipped in my original learning process -- to underpin the tricks and techniques that I've learnt with a thorough understanding of the building blocks. 

So well done you!

Good ON ya, IsaoShi! Thanks for your support. So, do you kinda see where I'm going with this? have you looked at nodes and wondered: "How the heck did they know to put that and that together to get that??"

I want the tools to be accessible. CobaltDream opened the whole "You can do maths on colours" concept. Now, I want to see what can be done.

In reading RuntimeDNA Node Cult threads one gets the impression that numbers greater than 1 are allowed and have meaning, what exactly that means is still very obscure. Only experiments are going to clarify that for all of us, IsaoShi! We each of us need to be doing those experiments and sharing our experiences. And even if we examine the same node and come up with different results and conclusions: it's gold, mate. More than what's out there now. Publish, question, compare, discuss.

The total here is going to be infinitely greater than the sum of its parts.

The fact that this idea is meeting with some enthusiasm has its own merits: means that I'm not the only one who feels a massive hole here!

I am preparing some little demos and a prop for us to share while examining the Diffuse node.

Meanwhile, you just jumped into a very interesting area, i.e. what color is GREEN - RED, i.e. what is RGB(-1, 1, 0)? You concluded it is green, but it isn't.

GREEN - RED is GREEN == false
GREEN - RED looks GREEN == true

I'm going to make a claim that this is a new color for which we have no name. Let's call it X. I will prove it is different from GREEN quite simply by demonstrating that when I manipulate this color as well as the color GREEN in a reproducible way, I end up with different results.

I know this is very much math speak but it is really important. You've already established some muddy thinking, even though you are quite capable of clear and logical thinking. So I insist that I have to teach you to think clearly. Since much of how we think is mediated by the language we use, I will insist on the language of mathematics for this.

So. Consider a math function, f, which has no random factors in it. Such a function is reproducible in all situations. Most of the math we deal with is like this. So the importance of this point is this:

Given two quantities, X and Y, which appear to be the same, if I can demonstrate a reproducible function for which f(X) does not equal f(Y), then I have proved that X does not equal Y.

In math:

f(X) != f(Y) ==> X != Y

the symbol != means "does not equal" and the symbol "==>" here means "implies" or "proves".

Ready? Here's my function:

f(x) = (x + WHITE) / 2

All I'm doing is taking the average of this color and WHITE. WHITE is [1, 1, 1].

Now let's try that with GREEN.

f(GREEN)
{ replace GREEN with its definition, which is the tuple [0, 1, 0] }
= f([0, 1, 0])
{ expand using the definition if our function, f(x) = (x + WHITE) / 2 }
= ([0, 1, 0] + [1, 1, 1]) / 2
{ do the arithmetic, element by element in the tuple }
= [1, 2, 1] / 2
{ notice another example here of a hyper color, the green part is 2 right now}
{ anyway, just divide by two now }
= [.5, 1, .5]

Now we try that with our mystery color, X.
f(X)
= f([-1, 1, 0])
= ([-1, 1, 0] + [1, 1, 1]) / 2
= [0, 2, 1] / 2
= [0, 1, .5]

This is a different outcome, one you can actually see. Therefore, we've proved that GREEN - RED is not the same as GREEN, even though it looks exactly the same when we view it as a color.

I think this is rather an enlightening approach.  We may learn something new along the way.  BTW, I see in your Color_Math node explanation you are using 2 primary  and 1 secondary colors.  Have you experimented with the addition and subtraction of secondaries to see what effects you get.  Also you stated:

*Quote: what "Green" is to Poser. It's 0, 1, 0. We know that? Right? This is an absolute. To Poser, when you say "Green", it thinks 0, 1, 0.

*Is that correct?  I think Poser should interpret that as 0,255,0.  The mathematical expression of a color in it's channel should range between 0 - 255, not an on-off switch integer.

Quote - I think this is rather an enlightening approach.  We may learn something new along the way.  BTW, I see in your Color_Math node explanation you are using 2 primary  and 1 secondary colors.  Have you experimented with the addition and subtraction of secondaries to see what effects you get.  Also you stated:

*Quote: what "Green" is to Poser. It's 0, 1, 0. We know that? Right? This is an absolute. To Poser, when you say "Green", it thinks 0, 1, 0.

*Is that correct?  I think Poser should interpret that as 0,255,0.  The mathematical expression of a color in it's channel should range between 0 - 255, not an on-off switch integer.

When we work with colors the 0 to 1 is the true presentation, but not binary. We mean that it goes from 0 to 1 including everything in between.

The 0 to 255 is just how we represent those colors in 8-bit integers. But Poser internally uses floating point numbers for color, not 8-bit integers.

It is the very last step in rendering to convert the number to 8-bit integer for display on the screen.

BB, thank you for the clarification.  It is looking at it as percentages, 100% true green, 0% none.

I am tiling two colors. One is a Simple Color RGB [188, 188, 188]. The other is a number, .7372. They look the same.

Now we've already learned that looking the same is not proof that they are the same. So you should suspect my proof here.

What could we do to prove these are the same or different, instead of just looking at them?

A similar device can be built for magnifying color differences.

Here is an example that works.

f(a, b): M * Abs(a - b)

where M is our magnification.

So given two numbers or colors, a and b, we subtract one from the other and take the absolute value. This gives us a measure of how different they are. Using a very large M, we can see the difference, expressed as a color.

Here my M is 100. I don't see much in the results, so these two values are very close.

The 8-bit value 188 converted to unit range is 188 / 255 = 0.737254902

I was only using the first four digits before. Now I can't see the difference even with M=10000

In fact, even at M = 1 BILLION you can't see the difference.

Quote - I think this is rather an enlightening approach.  We may learn something new along the way.  BTW, I see in your Color_Math node explanation you are using 2 primary  and 1 secondary colors.  Have you experimented with the addition and subtraction of secondaries to see what effects you get.  Also you stated:

*Quote: what "Green" is to Poser. It's 0, 1, 0. We know that? Right? This is an absolute. To Poser, when you say "Green", it thinks 0, 1, 0.

*Is that correct?  I think Poser should interpret that as 0,255,0.  The mathematical expression of a color in it's channel should range between 0 - 255, not an on-off switch integer.

Happy to be corrected here, but when I look at a node with color input values, the range appears to be 0 to 1 decimal value (I never said integer), where 0 is black, and 1 is white and the rest are decimal values between 0 and 1. Not an on-off switch. So, 255 is seen by Poser as 1? and 128 as .5?

No? Must have misunderstood something.

So we've seen how tiny differences in a color can be detected. We've also seen how we can detect hypo colors - colors that have a component that is less than 0. (Average it with white)

How would you detect a hyper color - a color with a component greater than 1?

(Remember you cannot directly "see" hyper colors - 1 is the brightest your monitor will go.)

There are many ways - I'll wait for any of you to figure one out.

Show me with math, and with nodes.

To produce a hyper color, just add white to any ordinary color that isn't black. For example WHITE [1, 1, 1] + RED [1, 0, 0] = [2, 1, 1]

How would you easily see that is not WHITE? I mean really easily. Like you don't even need any extra nodes once you have the color made with a Color_Math:Add(WHITE, RED).

Just to clarify, once more, since we're cross posting.

The integer 8-bit value 255 means 1. The integer 8-bit value 128 means 128/255. The integer 8-bit value 188 means 188/255.

Use the unit-range representation for learning the math. Do not try to do a lot of math with the 8-bit integer representation. You will only confuse.

For example, when we finally talk about gamma correction, we're going to be using exponentiation and it only works directly on the unit-range representation. Furthermore, the unit-range is the only one used in nodes. Period.

There is also the 16-bit TIFF integer representation, where the maximum value is 65535. We will gain nothing from thinking in 16-bit either.

Think 0 to 1 and everything in between with no specific jumps. In color math, any value is possible, including an increment that is far smaller than 1/255.

By the way, this is all good material in preparation for understanding the Diffuse node. If you have a firm grasp of color arithmetic, i.e. what does +, -, *, and / mean for colors, then you'll be able to follow so much better.

I want you to understand the "difference magnifier" node setup, M * Abs(a-b). It will be very useful in the future.

Using it, I can show you how two different node setups are virtually or actually identical.

Moving a bit fast, here, Bill. I can see your point about having to see things from a mathematical viewpoint, but like most non-math-inclined individuals, find conceptualizing what you are introducing a bit daunting.

Let's go to pane one.

I'm going to try to bring your math jargon down to human-speak so that I can use the concepts you're introducing in a sentence. Is that okay?
Obviously, I've come to an erroneous conclusion based on my observations alone, which serves to support my assertion that those experiments were relatively pointless without some frame of reference: guidelines, what's allowed, what actually happens... that sort of thing. My observations in subtracting red from green giving me green led me to believe that my simple math approach was all that needed to be applied. 0 - 1 = 0. Wrong.

You're introducing this empirical function f.
Function f has no variables (random factors). Since it's all constants, the results are by nature always going to be reproducible. Most of Poser math has this characteristic: it's like function f.

Am I following you so far?

You introduce two variables which do NOT have the same value, and you are going to set about proving that they don't... mathematically. For this you use the function f, which passes (or contains) a parameter... either X or Y. So,

f(X) is not equal to f(Y) which proves that X is not equal to Y.

Now, we introduce WHITE. And, ya lost me. No, I can see the validity, but why WHITE? Nowhere in what I was doing was there any white. So, you obviously understand something about colours in general, some assumption about how to manipulate them and what Poser does to manipulate them, that completely escapes me.

You need to understand that when I do experiments, I'm doing it from a purely visual, non-mathematical basis. I embrace the maths here - don't get me wrong, but really, I'm going to have to do some serious digesting of the concepts that follow before any "experiments" will have any validity.
You do see - might be hard from someone with your background - how the common Poser artist would be completely baffled by nodes, though, don't you? And do you realize that in order to make this all accessible to artist, I'm going to have to take your concepts and turn each one into human-speak so that it makes sense to Those-of-Us-That-don't-Get-It?

That said, I'm keen to get my hands dirty.

Let me have a think on this, and regurgitate, then you can evaluate my interpretation to make sure I got it right. Is that okay by you, Bill?

I will print these out and read them as I get ready for bed... and thank you so much for taking the time. Please be patient with me: I'll get this yet. May take a bit of time, but I'll get it.

I totally get what you're saying. Nevertheless, as long as an artist insists on what she can see, versus what actually is, then this is always going to look like a magic show to her.

The magician knows the truth, the audience does not. The difference lies in what is seen versus unseen.

Well it wasn't WHITE I was introducing. I only said that to appease the "artists who think in colors".

I was using the number 1, not the color white.

WHITE just happens to be the visual interpretation of the number 1.

All I was saying is that you can't see negative numbers. But they are there.  A negative number is very different than 0. Any calculation involving a negative number can reveal that it isn't the same as 0.

But your eyes made you believe they were the same.

Would it be helpful for me to show you a real-life situation where the explicit use of negative colors is really important? Meaning, as an artist who believes -1 is the same as 0, you would never get anywhere. But as a magician fully comfortable with the color -1, you can do magic?

So, negative numbers ARE valid in Poser and in the colour spectrum. Very important to know. A bit of a trial to get the head around, though.... but this puts a completely different spin on things.

Okay, off to bed... hope I can at least find THAT!

And thanks again, Bill.... this IS gold!

And yes, an example of negative numbers (in terms of colours) in real life would be very helpful... thanks!

I want to re-visit your question about "why WHITE - where did that come from".

I defined f(x) like this:

f(x) = (x + 1) / 2

Then I interpreted that visually as the process of averaging the unknown color with white. 

In so doing, I had to divide by 2. What color is 2, is that DOUBLEWHITE? How come you didn't freak out about that part? 

Technically, you should also be demanding to know what color is 2 and how the heck did I know to use that color.

Well it's not a color, and 1 is not a color either. They are numbers. Or in the case of color arithmetic, actually a tuple or vector (3 numbers grouped together in a unit).

I think if we leave off any interpretation of information, everybody is comfortable with the mathematical concept of average, right? Specifically to get the average to two things, you add them together and divide by 2. No problem with that one right?

(a + b) / 2

Well that's all I was doing - just taking the average of two numbers. It just so happens these numbers are being used to interpret colors.

I made this choice because I wanted to take what was hidden and make it revealed to you.

Given that you can only see numbers between 0 and 1, I had to find a function which would produce two different results, but that both results would lie in the visual unit range 0 to 1.

In other words, given my knowledge that you don't accept the math per se, my goal was to find a straightforward manipulation of the two colors such that I'd produce new colors that were not hidden colors, and were visibly different from each other. Thus you would see that you got two different results.

To put it in magical terms, I wanted you to see two "identical" coins (as far as your eyes showed you they were identical) go into a jar, and then come out of the jar different.

So I chose to do (x + 1) / 2. This was intentional and arbitrary. There are an infinite number of other functions that would have achieved my goal. But this was a simple one and also one that had what I hoped was an obvious visual interpretation, i.e. taking the average of two colors, or "blending" paints in 50/50 proportion. What I was trying to reveal was that one of these paints was magical. Even though the two paints looked exactly the same, when I mixed these paints each with white paint, in 50/50 proportion, I ended up with different colors. Magic? Yes, if you don't know what was hidden from you. (The -1 in red.) Not magic at all to the magician, who set the whole trick up.

just a quick mention:

you can't see negatives when they're colors.  but you can when they're affecting something else.

this gets back to what i mentioned about the displacemen map solution.  the point is that you want some of your displacement to go into the figure, not out.  then you need to subtract from the greyscale map the color or value of the color you want to be your state where there's no displacement.  with a color math node, you can actually use your eyedropper to select this color in the little preview of your map.  not a very precise method, but it can come in handy sometimes when you don't need to be precise. 

once you subtract anything greater than 0 from your displacement map, some of it will inset rather than expand. 

and i have to add this:  this is very important if you want to have significant displacement and correct for people using an altered diffuse map for a displacement map instead of something more refined.  because lots of that image will tell the skin to do something you don't want.  most likely expand.  if the values are low, you won't notice the difference, but if for some reason you wanted higher values, you'll puff up your figure.

also, your displacement map can go beyond 1.    so the whiter than white results won't be leveled off.  to level off the results, you should use a clamp node, as described in the Castle Poser tutorial and shown in the Castle Poser example material.

We start on the right with some color map - whatever original texture.

The middle Color_Math:Subtract is finding out how the texture map differs from some reference color. Here I actually sampled a color from the texture itself.

So the subtract is producing positive and negative delta colors (colors that represent the difference between two colors). The more the texture is different from the reference color, the more positive or negative the delta color will be. We cannot "see" the negative delta colors, but they are there, for sure.

The next step, on the lower left, is where I multiply the delta with a factor. If I use a factor less than 1, I decrease the delta color intensity. If I use a factor greater than 1, I increase the delta color intensity.

Finally, in the upper left Color_Math:Add node, I add back the reference color.

When the same color is used in both the subtract and the add, this serves to simply control the intensity of color variation, around that reference color.

However, when I add in a color that is different from the subtracted color, then I can actually shift what color this produces in the final output.

So the grain of the wood is enhanced. But the overall color remains the same because I added back what I subtracted - same color.

Here I used a darker red as the basis. I also set the factor to 1.2. This gives me a nicely stained look.

You can't get this appearance with just multiplication or bias or gain - you have to actually produce negative colors as an intermediate step, using subtract.

The bottom row, the only thing changing is the factor. The subtract and add color are the same.

In the upper row, the add color is different from the subtract color.

The reference color I subtract is brighter than all the colors in the color map. Which means this is producing a field of entirely negative colors. You can't see them. The preview of the subtract node looks uniformly black. But that is just because the values are hidden below 0 where we can't "see" them. But I know they are there, I know what I'm doing with them (multiplying by 1.7), and they sure have an impact when added to the other reddish color.

I could easily make 100 distinctly different wood textures from that one color map. Many people would be willing to pay for these "100 wood textures", and probably they'd never know that it was all the same texture, and one they already had included in Poser.

This is actually fascinating.  There is such potential to diversify your textures using nodes in the Material Room.  A brilliant conservation of both HD space and resources by simply having Poser do most of the work for you rather than wasting precious time colorizing and tinting.

Bill, I clearly misunderstood the intent of introducing that "averaging function" (had a struggle understanding the function itself for a bit), but now it's clear to me that its purpose was to illustrate a key point: negatives and numbers greater than one exist in Poser. That fact is going to be of utmost importance to understand when making materials out of nodes using colour or for that matter doing anything with nodes at all.

I opened this discussion with the strong suspicion that my so-called "observations" were giving me false conclusions. Basing conclusions on what is observed and inferring that "because I can't see a change, therefore no change must be happening" when working in such a math-saturated environment was going to be fraught with error: I sorta figured that. What I needed to have were tools to disprove my first conclusions, which you have provided with your "averaging" function.

In your subsequent posts, I notice your experimentation method produces quicker results than plugging into a PoserSurface Alternate_diffuse channel for purposes of rendering. So, those methods were bogus as well, since a rendered surface is going to be affected by the existing lights, which would affect outcomes too much for there to be a consistent, reproducible result: too many variables.

I'm talking basics, here. Those that say "you need to do experiments" fail to understand that Dummies like me haven't a clue what should and shouldn't be in a lab setting. The reason I plugged into the Alternate_Diffuse channel was because I was of the understanding that it only passed on to PoserSurface what was plugged in, which made it a known entity.

And here in the material room, there were so many unknowns.

So, what do I now understand? Regurgitating:
--Negative numbers exist and must be reckoned with, as well as values greater than one.
--With colour, you deal with a tupple, so any maths you apply is applied to each member of that tupple.
--Minute colour changes can and will have massive impact on surfaces.
--Most importantly, don't rely at all on what you see: trust the maths, get the head around the maths, start with maths... the nodes will grow out of that

How do I use it in a sentence? Know what you want to do and do it mathematically first.

Your wood grain illustration is mouth-watering, Bill. Second-year, stuff, but definitely mouth-watering. So, I look at those nodes and suddenly realize I'm looking at the result of something that was worked out as a math equation before-hand. The maths actually comes first: the nodes create themselves (virtually) based on the math.

Am I getting any closer?

Goooooood morning, RobynsVeil.

Of course it's evening here, and I'm on my 3rd very large vodka gimlet, so I'm in a mood.

Let's do some stuff in real time, across the frickin' globe.

Let me see, I'll read over what you wrote and respond. Then we'll get to work.

Negatives and numbers bigger than 1 exist and are used on purpose in shaders. Correcto.

Tip: When we don't want a calculation to go outside the unit-range we "Clamp" it.

Math:Clamp is what you use.  In my notation,

Clamp(x) is always at least 0 and at most 1, by definition.

Mathematically the following is true:

when 0 <= x <= 1 , Clamp(x) = x
when x < 0, Clamp(x) = 0
when x > 1, Clamp(x) = 1

This is the definition of Clamp.

well...  bagginsbill might totally disagree with me, but i'd say you need both.  bagginsbill is a genius and an expert, but he's said in many places and times that he's not interested in the artistic aspect.  well, there's a reason most professional photographs are heavily postworked, even when they don't look as if they are.

just as a for instance, i was feeling really down about how not glossy my hair shader was in blonde and set out to look for source images.  i deliberately avoided press and magazine pics and tried for images more likely to be raw.  as a result, about the only shiny blondes i found were children.  and even they didn't have hair that shone white unless  the light hitting their skin blew it out.  i found some resources on doing glamor lighting that helped, but in all, the only pictures i found even with dark hair that had the kind of highlights people expect  were all shampoo ads.  which are about as likely to be untouched as photos of ice cream. 

so if i just looked at the math, i could adjust lots of aspects.  but in the end, i have to make stuff to suit the eyes, the same way a cook has to make stuff to suit the palate.  knowing  chemistry won't make you a good cook, but it will help you to make more complex combinations of foods work together.

eyeballing it is still important.  and sometimes you'll make huge changes in the numbers, and it will have a small effect on your picture. make the same changes with different lighting and camera angle, and boom, huge difference. 

the math is important, because you need to know what you're doing to do it again.  but don't lose sight of the effect you want, even if it isn't realistic.

at least in my experience, which has had, admittedly, mixed and slowly improving results.

Good evening, Bill... hope you are enjoying your gimlets. I'm keenly looking forward to this.

BTW, it was suggested I start a blog with this topic as focus - thank you, CobaltDream - good suggestion... and so am installing as we speak. I'd like to publish conclusions and experiments from here in that blog since threads are not very searchable, and this information needs to be in a highly accessible format.

If that's still cool with you, of course.

"because I can't see a change, therefore no change must be happening"

Beautiful. Now that you recognize this fallacy, your eyes will be opened.

*In your subsequent posts, I notice your experimentation method produces quicker results than plugging into a PoserSurface Alternate_diffuse channel for purposes of rendering. So, those methods were bogus as well, since a rendered surface is going to be affected by the existing lights, which would affect outcomes too much for there to be a consistent, reproducible result: too many variables.

*Whoa - too far. First of all, yes it is quick to preview some things directly in the material room on the node, but not every node we use will actually preview at all. For example, Edge_Blend does not preview at all by itself. You will learn over time what you can preview in-node and what you can't.

So some things must be plugged into Alternate_Diffuse and then we can see what it does, but now on the PoserSurface. However, this is on a half-sphere. Even that doesn't always tell us enough information. So I often actually render test props that are specifically designed to reveal information to me.

We're going to be working with such a prop shortly. You will do many Alternate_Diffuse renders to expose information that is hidden by node previews.

We will call these ADR for Alternate_Diffuse Rendering. When you see me talk about an ADR as in "you should ADR that function on a cylinder to see what is happening", you'll know what I'm talking about.

(We're making these names up as we go, but these are not spontaneously made-up techniques. I've been doing these for years. It took me literally thousands of f'ing hours to discover how to reveal the hidden secrets of the nodes.)

I guess I was using visual feedback to prove things. That was error, particularly when maths will prove the opposite to what my impressions were, to be true. However, visual feedback will still be the final factor in art, CobaltDream.

*The reason I plugged into the Alternate_Diffuse channel was because I was of the understanding that it only passed on to PoserSurface what was plugged in, which made it a known entity.

*And that was correct, and you learned that accurately. What you plug into AD goes straight to the render. (Almost, there are exceptions, but we will reveal those later.)

As long as you have no Transparency active, AD is a pass-through to the render.

Note to self: not all methods work for all nodes. Some items will need rendering to reveal what's going on. Gotcha. Thanks.