Good job!

Yes, that's a super color (or what I earlier called a hyper-color). The resulting color is Color(.5, 1.5, .5) - thus it's a hyper-color.

In Poser (internally) and matmatic, RGB intensities are always represented as unit range, i.e. fractions or multiples of 1. Remember there are two common systems for color element intensity. One is the 8-bit integer format 0 to 255. The other is the unit range format, which is a floating point number from 0 to 1.

The Poser user interface is showing you colors translated into the 8-bit representation, but that's just an approximation. The correct and precise true valule is actually a floating point number.

Using the 8-bit system, it is impossible to represent the true value known as mid-gray, or .5. The reason is the value needed is half of the maximum value. The maximum value is 255. What is half of 255? Is it 127? Nope. It is 127.5!

So Poser is lying to you. The mid-gray you see is actually .5 expressed as a decimal fraction of the unit maximum. When it shows you 127,127,127 it is not the truth. The truth is 127.5, 127.5, 127.5, but it can't show you that because the integer representation is, well, an integer.

Furthermore, a hyper-color intensity (a value greater than 1) cannot be represented in the 0 to 255 range either. Do not try to read out such values in the material room - you can't. You can't see them either. They show up all random and funky. Just trust that they are there when you use them in the script.

Now back to the script.

You made a node with this: SimpleColor(GREEN)

You then added a node and a number with this: SimpleColor(GREEN) + .5

Matmatic noticed that you were using a node that returns a color. It saw that you were trying to add a number to a color. The rule there is to promote the number to a color first. So the .5 becomes Color(.5, .5, .5). To add colors where at least one comes from a node, it must use another node; a Color_Math node. So that's what you got. Matmatic called it a Color_Add because it is helpful like that. ;-)

The first argument is your SimpleColor node, so it just connected that to Value_1. Now why did it put white in there? Because the parameter color gets multiplied with the plugged-in value. All I want is the original value, so the way to do that is to multiply with 1. The color equivalent to 1 is white. Voila. The value to be added was your .5, but I need the color version of that, which is Color(.5, .5, .5).  In 8-bit form that would be 127.5, but 127-and-a-half is not allowed in that format, so the RGB readout says 127. No big deal. The real value is .5

So the net is you have WHITE * SimpleColor(GREEN) + Color(.5, .5, .5) which is equivalent to what you said, but expressed correctly using poser material room nodes.

Now you may be curious as to why there are two nodes at all. The reason is because you explicitly asked for a node when you said SimpleColor(GREEN) instead of just saying GREEN. The usual reason for this sort of thing is because you may be trying to separate the GREEN into a single node, so the user can further edit the resulting nodes easily. That SimpleColor(GREEN) might be connected to several other things later, so matmatic leaves the node as a node.

If, instead, you had said GREEN + .5, then matmatic would have immediately reduced that to Color(.5, 1.5, .5) all by itself. Anywhere you used that, it would be just a color, not a node.

However, the Alternate_Diffuse channel does not activate with just a color in it. There has to be a node plugged in to make it wake up. So that's why you want to use a node here, even if the value is a constant. Usually we only use nodes for things that change, and just use a plain color for things that stay the same everywhere. But, again, Alternate_Diffuse MUST have something plugged in to wake it up.

Notice how the Alternate_Specular channel is "sleeping". It shows a dot with a question mark in it. That means it's the sort of channel that requires a node to activate. There really is a color there, but it isn't active yet - not until you plug something in.

Now back to a previous test case: SimpleColor(GREEN) * .5

Matmatic is very smart. It tries to find simpler ways to do things. You asked for multiplication of a node with a number. So first, it promoted the number, .5, to a color, Color(.5, .5, .5). Then it noticed that you were plugging that product into a color channel. Since the color channel Alternate_Diffuse has a color multiplier in it, there are two ways to accomplish this goal. One way would be to create a Color_Math:Multiply node to combine the SimpleColor(GREEN) * Color(.5, .5, .5) and then connect that to Alternate_Diffuse with a WHITE value in the channel color. But the channel color value is multiplied with whatever is connected. So why bother with another multiply node, when there's already a multiplication with a constant involved in the channel itself? So that's what matmatic did. That is why you saw RGB 127, 127, 127 in the Alternate_Diffuse channel color. It was saving one node. (Remember, the real color intensity there is 127.5, not 127, but you can't read that out using the Poser GUI.)

So when you said +, you got an Add node because there was no cheaper way to do it. But when you said *, you did not get a Multiply node, because there was a cheaper way to do it.

---

Renderosity forum reply notifications are wonky. If I read a follow-up in a thread, but I don't myself reply, then notifications no longer happen AT ALL on that thread. So if I seem to be ignoring a question, that's why. (Updated September 23, 2019)