Paolo asked me an interesting question today. It's this:

How does Alternate_Diffuse actually work? How is it related to Diffuse_Color at the top of the Poser Surface node?

I gave an answer in writing, but I think a demo is in order.

The Diffuse_Color and Diffuse_Value parameters are plugged into an internal Diffuse node - one you can't see. That node is going into an internal Color_Math:Add node and getting added with all the other channels.

Alternate_Diffuse is also added into that internal Color_Math:Add node.

So is the product of Ambient_Color * Ambient_Value.

So is the product of Reflection_Color * Reflection_Value, etc.

All of the channels get added together. There is a slight compilcation to this when transparency or scattering is involved, but for a first pass to understanding that's about it.

Please keep in mind, however, that this is for rendering with Firefly, not for preview. Preview has its own bizarre rules that I have never bothered to figure out - I just don't care what preview does.

Now I will demonstrate the bizarre consequences of this.

But they are different shaders.

What do I mean by that?

I use the word "material" to refer to the effect - what you perceive - how it behaves.

I use the word "shader" to refer to the group of nodes, parameters, and connections that implement that material.

For any given material, there are an infinite number of different shaders that produce it - exactly - with no variation.

So - if many different shaders define the same material, it follows that there must be some mathematical equivalence going on between them.

When someone is aware of these, they can make progress toward a goal by choosing any of thousands of different changes to the shader.

When someone is unaware of these equivalences, they often make shader changes that have NO impact on the resulting material.

I did six shader changes here on purpose, but lots of people do this by accident. After an hour of twiddling, they're back to where they started and half the nodes don't do anything.

Something to keep in mind.

Here is the script I used.

I'm also pasting the contents here so you can just read it.

# I make a handy function to generate my poser surface
def S(dc, dv, ac, av, ad):
        s = Surface()
        s.Diffuse_Color = dc
        s.Diffuse_Value = dv
        s.Specular_Value = 2
        s.Highlight_Size = .001
        s.Ambient_Color = ac
        s.Ambient_Value = av
        s.Alternate_Diffuse = ad
        s.Displacement = disp
        return s

# make some cool nodes
pattern = Cellular()
disp = Bias(pattern, .7) - .4
dc = Clouds(RED, YELLOW)
dv = .05 + .95 * pattern
ad = Clay(Granite(IColor(79, 66, 188), 0, 4), .2)

# fun with math in example F - put any numbers you want here - comes out the same
P = .25435
Q = 11.658

# now demonstrate six different shaders that are actually exactly the same
outputs += [
        "A", S(dc, dv, 0, 0, ad),
        "B", S(dc * dv, 1,  ad, 1, 0),
        "C", S(0, 0, Diffuse(dc, dv), 1, ad),
        "D", S(0, 0, 0, 0, Diffuse(dc, dv) + ad),
        "E", S(0, 0, Blend(Diffuse(dc, dv) + ad, 0, 140.0/160), 8, 0),
        "F", S(dc, dv * (1-P), ad, (1-P), (HSV(Diffuse(dc, Q), 1, 1, 1) + ad * (Q / dv)) * (dv * P / Q)),
]

Thank you for the personal answer and for the very detail demo here. This post should be included in the Poser manual.

Cheers.

(Remove the .doc at the end - it's a .zip file)

Unzip it - you'll find .mt5 files inside. Put them in your runtime wherever you like.

Quote - Thank you for the personal answer and for the very detail demo here. This post should be included in the Poser manual.

Cheers.

You're very welcome, Paolo. I love your work.

Thank you for this BB..you have me understanding a few nodes and how they work...will be nice to examine ;).

Laurie

Thanks for the demo and examples Bagginsbill...

Thank you BB:) 

Very much appreciated your examples and explantation.

Thanks BB :)

Thanks- I always appreciate your information- now if only we could have caustics in Poser....

Quote - For any given material, there are an infinite number of different shaders that produce it - exactly - with no variation.

Consider my mind officially boggled. 8) And yet - I can understand why this is, given your explanation of how the surface node works.  

Quote - Thanks- I always appreciate your information- now if only we could have caustics in Poser....

With Reality you can :)

good, no surprises here (for me), but good to give it some attention every now and then.

Now, to spoil the fun a bit: switch Gamma on/off in PPro2012 and render twice... do you still have 6 similar results per image in both cases?

Quote - > Quote - For any given material, there are an infinite number of different shaders that produce it - exactly - with no variation.

Consider my mind officially boggled. 8) And yet - I can understand why this is, given your explanation of how the surface node works.  

It's very basic math (and obvious when you think about it). After all, 1 + 1 = 2.

But so is (1 + 1 + 1 - 1), and ((1 x 1) + 1), and (3 - 1), and (10/5), and (2 x ln(e)), and (log(100)), and...well, there's an infinite number of ways of getting a result of "2" from an equation.

Quote - good, no surprises here (for me), but good to give it some attention every now and then.

Now, to spoil the fun a bit: switch Gamma on/off in PPro2012 and render twice... do you still have 6 similar results per image in both cases?

(Caveat: I am not at home and do not have Poser to check anything. So I may have overlooked something. Nevertheless ...)

Short answer: for the above shaders, yes, six similar results.

Long answer:

With gamma, you will still see six identical materials, but not the same material as without gamma. I could render again and it will look different than the first image. However, the six pawns will match each other.

Gamma is applied to incoming material before the calculation, and to the final output pixel value after the calculation. This does not mean the results are the same with and without gamma - they are not. It means that I didn't do anything that would reveal a difference among these particular shaders if you did happen to change the gamma.

If gamma != 1, then the following things happen:

• Every color named in the shader will be anti-gamma corrected. If the color is not in a limited set of gamma-invariant values, it will be altered by gamma. However, it will be uniformly altered to the same value - as if you had simply entered a different set of numbers.
• Every incoming image map may apply the gamma as well - if it does, the numerical values in the image that are not gamma-invariant values will also change.
• The final output of the shader after adding all the channels together will be gamma corrected.

So - it is clear then that if a shader contains only gamma-invariant colors, then the shader is unaffected by gamma since the incoming material is not altered by gamma. When the colors are gamma-invariant, the input to the shader is unchanged, so the calculation is unchanged. Only the output is affected - therefore the calculated color is the same across all six.

However, my shader above does have one gamma-variant color - the blue used in the Granite node. Since that blue was altered by gamma exactly the same way in all six shaders and not used in something like a Clamp or Bias, they remain equivalent to each other.

Gamma-Invariant colors - I just made up this term so it deserves an explanation. What I mean by this is that the numerical value of a color is unaltered by gamma. This is possible when all three RGB components of the color are set to 0 or 1 in unit color system. For 8-bit values, this means every component is 0 or 255.

There are exactly 8 gamma-invariant colors - I actually define them as words in matmatic since I use them a lot. Four of these (BLACK, WHITE, RED, and YELLOW) are used in the shaders above:

BLACK = Color(0, 0, 0)

RED = Color(1, 0, 0)

GREEN = Color(0, 1, 0)

BLUE = Color(0, 0, 1)

CYAN = Color(0, 1, 1)

MAGENTA = Color(1, 0, 1)

YELLOW = Color(1, 1, 0)

WHITE = Color(1, 1, 1)

Want to know more - like why are these gamma-invariant?

Well anti-gamma correction for a given gamma is

def AGC(x): x ** gamma

Gamma correction at the end for a given gamma is

def GC(x): x ** (1.0 / gamma)

The ** represents exponentiation, or raising to a power.

When gamma = 1, both of these become x ** 1, which is x. That means gamma = 1 is the same as not doing gamma at all.

When gamma is not one, what values of GC(x) == x?

0 ** gamma = 0

1 ** gamma = 1

So it turns out that color components that are set to 0 or 1 are still 0 or 1 after doing either gamma function.

The gamma function of a color is simply applied to each component. With three components you have each one capable of being invariant if it has either of two values. Therefore there must be 2 * 2 * 2 = 8 invariant colors. And there are - I listed them above.

Are all equivalent shaders still equivalent with gamma?

No. If you do a nonlinear manipulation of the incoming colors, they will become different. However, everything I did above is linear.

BB,

not sure, for the following reason: the anti-gamma pass mentioned does work on textures and color swatches only, but not on numericals. So (dc,dv) and (dcdv,1) are not similar, as (ac,av) and (acav,1) are not - unless mathmatic puts dv (and av) as numericals in the node tree explicitely and doesn't generate the final colorswatches themselves. It might, then the mathmatic tree is fine but things might go wrong when building something by hand using adjusted swatches instead.

In other words: (0.5, 0.5, 0.5) at 100% behaves different from (1,1,1) at 50% in Poser gamma application, since te 50% color is affected but the 50% value is not.

I know you know, but a lot of other people are not aware of this and might fall into the trap when decoding Poser node trees.