I think that I am getting the hang of using Ambient Occlusion, but 1 question remains.

Many of the new "shaded" texture sets use the diffuse input Channel, my question is which blending or math node should I use to bring the AO node and the existing texture nodes into the diffuse input channel together, so that the existing node is not altered in function and the AO node works to it's fullest.

Hope someone can help

and thanks in advance
MARK

You can do this, if I'm not mistaken, using a Blender node to blend the AO and the texture.

You want to control the brightness of the diffuse light by multiplying it with the ambient occlusion.

There are two ways.

One is to use a Color_Math node, both values white, set to Multiply. Connect Input_1 to the original shader tree that goes into Alternate_Diffuse. Connect Input_2 to the AO node. Connect the Color_Math:Multiply to Alternate_Diffuse. However, this may not be the "best" way, if the shader also calculations reflections, refractions, or specular highlights. Ambient occlusion should not darken these calculations. It should only affect diffuse lighting.

The other is to go through the shader and find where its using a diffuse lighting node, such as Diffuse, Clay, Skin, Velvet, etc. Then just plug the AO node into that lighting node, using whatever input channel controls the brightness. For Diffuse, that would be Diffuse_Value. The AO node is at the bottom.

The attached screen shot is of one of my complex skin shaders that goes into Alternate_Diffuse. I grabbed this from another thread and it has many annotations that are not relevent here. The one you care about is #6. That is where my AO node is plugged in.

See?  That's why I'm not the shader guru!  LOL!  Thanks, BB.

I think that I understand what you mean, please look at the attached screen shot and check me. 

Now another question, what is the difference between a math node and a color math node.  I played around a little more after I logged that post last night and used a Multiply node (NOT color multiply) and got a nice but very subtle effect. not sure what the difference is between the two.

Thanks for your help, and I look forward to your reply.

Mark

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.