Ah - that's a rebelmommy shader. It's a variant of the V4 shader face_off made for DAZ, which is a variant of one of my earlier subsurface scattering shaders. (Running a Diffuse node into a Color_Map node that has some red in the low bands.)

I don't use that anymore.

So guess what - you did it right. The AO wants to modulate the Diffuse_Value and the way you're doing it, it does.

However, I'm not sure that you've got what you really want, which gets to your question about what is color math.

When data is passed between nodes, that data is either a color or a number. A color is actually 3 numbers. Borrowing a term from physics, these three numbers represent a vector in color space.  Basically, each value in the vector represents a different dimension. For colors, the dimensions mean red, green, and blue. So a color vector has three elements.

Color math is Poser-speak for vector arithmetic.

Have you every heard of vector arithmetic? It's really quite simple. Basically, arithmetic operations are performed on corresponding elements.

Consider two colors (vectors) A and B. A has three elements - let's call them Ar, Ag, and Ab.(r=red, g=green, b=blue).  The vector might be written like this: [Ar, Ag, Ab].  B also has three elements, Br, Bg, Bb. So the value of B is [Br, Bg, Bb].

What is A + B? Using Color_Math:Add (vector addition) the answer is

[Ar+Br, Ag+Bg, Ab+Bb]

Just add the individual corresponding elements, and make a new vector with those sums.

Similarly, for A - B we use Color_Math:Sub (vector subtraction, or difference) the answer is
[Ar-Br, Ag-Bg, Ab-Bb]

Vector's have two kinds of products (multiplication) in physics, but we mostly only care about one of them, called the dot product. (It's called that because we write a dot between A and B in mathematics.) I can't write a dot in this forum, so I'll use * instead.

So for A * B we use Color_Math:Mul  and the answer is
[ArBr, AgBg, Ab*Bb]

Basically Color_Math does exactly what Math does, but it does it for 3 elements in a vector, in parallel.

Extra credit: What is the color math equivalent of 0 - i.e. X * 0 = 0 for all X? What is the ZERO vector or color?

It is BLACK, [0, 0, 0]. X * BLACK = BLACK, regardless of what color X is.

How about the color math equivalent of 1 - i.e. X * 1 = X for all X?

It is WHITE, [1, 1, 1]. X * WHITE = X, regardless of what color X is.

Now you see all those parameters on the nodes? Some have a number, and some have a color. That is the multiplier when you plug another node in there. If you see a number, it Math:multiplies with a number, and the result is a number. When you see a color, it Color_Math:multiplies with a color, and the result is a color.

Now you know why all those parameters have white in them so often. It's because we just want to use the value that's coming in. When we want to use an incoming color as is, we multiply with white.

What if you plug a color into a number parameter? Poser reduces the incoming color to a number, by averaging the three elements. So the color [x, y, z] is first converted to the number (x + y + z) / 3. Then it does the multiply.

What if you plug a number into a color parameter? Poser promotes the number to a vector, by cloning the value 3 times. So the number x becomes the color [x, x, x].

So what happens if I do [a, b, c] * x? First x gets promoted to a vector, [x, x, x]. Then we vector multiply and get [a * x, b * x, c * x]. Clear?

It is important to realize that the elements of a vector do not have to stay in the range 0 to 1. They can be any value, positive or negative, just like numbers can. We frequently take advantage of this during shader calculations. In the end, Poser can only render a color element from 0 to 1, but along the way it can hold other values before reaching the renderer.

Now, let's look at what you've done there. You have a Spots node. It's producing a color (a vector), based on a pattern, controlled by those two brown colors you entered in it. That's going into the Color_Math:Mul on Input_1. Because Input_1 is white, the exact spot color is being used unchanged.

You have an AO node. That produces a number between 0 and 1. You're running that into the Color_Math:Mul on Input_2. Because Input_2 is a color, the AO node is being converted to a vector. No big deal. Then it is multiplied with WHITE - resulting in no change.

The spot color is being darkened by the AO number in the multiply. That's cool. AO mostly produces a 1, resulting in no darkening. Only when something is nearby does it produce a lower value.

But ... then you do something wierd. You plug that color into Diffuse_Value. ?! Diffuse_Value is a number parameter, not a color parameter. So you're losing the actual color, and using the average value of the brown elements as a number. This is strange. It darkens the whole thing all the time.

Is that what you wanted? To darken the texture?

What are you trying to do with the spots? Make little brown spots? OK then. You should do this differently.

Plug the color image map into both color parameters on the spots node. Set one of them to white. (No change.) Set the other one to a very light brown. This will make the spots node produce a copy of the color map, except where a spot is supposed to be, which will be a darker, browner, copy of the color map. Plug the spots node into Diffuse_Color (! color value goes to a color input !)

Then the AO node should go straight into the Diffuse_Value. (! number value goes to a number input !).

After that, you won't need the Color_Math:Mul node at all.

---

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)