could we have  a hyper color only in reflections and not on the objects ? 

I apologise for not providing all the colour information so that you could reproduce my attempt at experimentation. Here are those numbers:
purple: (158, 0, 126) or (.6197, 0, .4141)
orange: (255, 59, 38) or (1, .2313, .1490)
Anti-gammaed (^ 2.2), that would be:
purple: (.3489, 0, .1437)
orange: (1, .0403, .0151)

Adding the colours: (1.3489, .0403, .1588)
Clamping (1, .0403, .1588)

So, Clamp does only bring down to 1 those values that exceed 1 or up to 0 those that are less than 0 of-the-tuple. In which case, I don't want to be wandering into the add-colours-then-clamp zone, since that won't give me a predictable outcome.

Ice-boy brings up a point... I see specular set at 3 and above in existing shaders. Obviously the originator of the shader was after a specific effect. Would you like an example of what I mean?

Colours for reflection or specular: they need gamma-correcting as well, don't they?

I've gone a bit off-topic myself, if the topic was sharing GCed materials. Getting back to that, I'd like to be reasonably sure that what I'm sharing is going to be a "Valid Shader". By that, I mean: something that closely approximates what one can expect to find in the real world.

If that sounds lofty, one of the reasons I continue to struggle doing maths (starting with understanding them) is because of the concept that materials can be mathematically represented.

All this is not easy for me. I agree that I tend to run questions into each other which makes it hard to decipher what exactly is being asked. I will endeavour to isolate a question from other questions in order to facilitate a response.

Note the word "endeavour".

Assumption: all colours that end up in the diffuse_color and alternate_diffuse channel need gamma-correction before processing.
Question: do colours used in nodes that get plugged into specular channels need gamma-correcting before processing?

Guys when you point at one node and shout "Hyper color here" you're myopic.

What does the rest of the shader do with that, hmmm?

If I take an ordinary color X, and I do

d = DIffuse(X, Diffuse_Value = 800)
s = Specular(X, Specular_Value = 1000)

You all see hypercolors and get freaked out, but what if later I do

output = (d + s) / 1000

What do I have now? Not hyper anymore is it?

Quote - Guys when you point at one node and shout "Hyper color here" you're myopic.

When I refer to hyper-colours, I'm referring to existing shaders. Or specular values > 1.

But, I get the impression with that response that you've answered my question. Any colours plugging into specular or reflection channels need gamma-correcting.

Thank you.

RV: I was one post behind - we're cross posting.

In answer to your latest question, your rule is false.

First of all we are not gamma-correcting incoming colors - we're anti-gamma correcting them.

Second, it isn't a matter of where you're plugging them in. It's simply this: if you choose a color based on what you see on your screen (or paint them, or do anything involving getting visual feedback as you make color choices) then you are working with visuals in sRGB space. Before you work with these visuals arithmetically, you want them in linear color space.

It doesn't have anything whatsoever to do with where you're plugging these values in. It has to do with what is the true numerical value you are trying to work with.

What color (true linear color numerical value) do you think the blue background in the renderosity website is?

Quote - > Quote - Guys when you point at one node and shout "Hyper color here" you're myopic.

When I refer to hyper-colours, I'm referring to existing shaders. Or specular values > 1.

But, I get the impression with that response that you've answered my question. Any colours plugging into specular or reflection channels need gamma-correcting.

Thank you.

A specular value > 1 that is later multiplied with a number far less than one is not a hyper color.

i am confused.

Bump does not use colour information.
Neither does displacement.
Nor does the transparency channel use colour information.

Diffuse_Color does.
So does alternate_diffuse.

I know that if I plug a colourMap into a bump channel what is being used is not the colour information.

From what I'm reading now is that since I do use the colour information in specular and reflection and all those - anywhere, really, where I see colour in an existing shader, those colours will need to be anti-gammaed before processing.

It boils down to intent.

Quote - i am confused.

Whether you come up with hyper-colours in the middle of your processing is immaterial, is what I understand from Bill's remarks. You probably will. There are methods to ensure that conservation of energy rules aren't transgressed that you can apply prior to gamma-correcting. Bill's already given us several.

These are fresh ideas to me (anything newer than 2 years is fresh!) - not something I work with every day or think about every day, and will take some time to assimilate. And even a bit longer to make these ideas into working principles. Hence, the failure to term things properly. I have it in my code, for crying out loud:
anti-gamma
...process...
gamma

At the risk of being premature with what follows next, I'm going to jump right in with something complex. I want to create a GCed version of this dress which has the following shader for the flowers on the dress:

There are some interesting things happening here. I'm not going to worry about the bump and displacement imageMaps... they don't involve colour. They reference the same image, so I'm going to make that one node. My plan is to move activity from the diffuse_color and specular_color to the alt_diffuse and alt_specular channels.

The colours in those channels need to be anti-gammaed, as well as any colours in the weave and imageMap_4 nodes.

Now, I've got a specular_value of 1. And a reflection_value of 3. Diffuse_value of 1. I'm beginning to think that in order to arrive at realistic values, I'd have to work this as a script:

def makeSurface():
  gcVal = Add(2.2).labelled("gcVal")
 
  # Maps
  colourMap = ImageMap("VDRflwr_rpd01.jpg").labelled("Colour Map")
  dispMap =  ImageMap("VDRflwr_rpd01D.jpg").labelled("Displacement Map")
 
  # define colours
  DiffClr = IColor(112, 31, 255) # Diffuse_color Blue
  W_Bclr = IColor(126, 70, 0)    # Weave Base_Color copper
  W_clr2 = IColor(225, 205, 153) # Weave 2nd_Color gold
  ReflClr = IColor(38, 112, 255) # Reflection_Color light blue
 
  # anti-gamma the map and colours
  lnrClrMap = ((colourMap * DiffClr) ** gcVal).labelled("Linear ColourMap")
 
  setWeave = Weave(WHITE, W_clr2 ** gcVal, W_Bclr ** gcVal, 1, 1, 3, -6, .2)
  setSphere = SphereMap(setWeave * (ReflClr ** gcVal))
  
  setRefl = (setSphere ** (1/gcVal))
 
  setDiffuse = Diffuse(lnrClrMap, .7 * (1 - setRefl))
  
  # Deals with diffuse
  setShader = (setDiffuse ** (1/gcVal)).labelled("DiffuseRGB Out")
 
  
  # Makes the actual surface
  s = Surface(1,1,0,0)
  s.Diffuse_Color = DiffClr * colourMap
  s.Diffuse_Value = Add(0,0)
  s.Reflection_Color = setRefl
  s.Reflection_Value = 3 * setRefl
  s.Bump = .03096 * dispMap
  s.Displacement = .12411 * dispMap
  s.Alternate_Diffuse = setShader
  return s
  
makeSurface()

Which creates this:

Not sure how I'm supposed to feel about a reflection value of 3, but the rest I'm fairly happy with. I think.

i was just asking sometimes i have an object that is glowing. so i use the ambient . i make it more then  1 so that in the reflection materials( car,...) its super bright.
but when you render out the object it doesnt look like the original color.

for example red. normal red. i make it 3. so superbright. it will be brighter on a reflective surface. but the object itself is not rendered as the original color.

Quote - I'm confused

RV: The key lies in bb's statement:-

Quote - It doesn't have anything whatsoever to do with where you're plugging these values in. It has to do with what is the true numerical value you are trying to work with.

An example to illustrate:

Take a specific colour value: (0.5,1.0,1.0) - a light cyan. Suppose this same colour appears in two places in the calculation of diffuse colour in a particular (hypothetical) shader.

Firstly, it is intended to use a light cyan (to some extent) in the diffuse colour of the rendered surface. But your GC version of the shader will gamma correct that colour on output, so you should anti-gamma correct it on input.

But it is also used elsewhere in the shader to multiply the diffuse colour in order to reduce red channel intensity by 50%. In this case, you should not anti-GC it. If you do, you will reduce red channel intensity by around 78% (assuming GC=2.2).

A silly example maybe, but it illustrates the point that whether you Anti-GC or not depends on the purpose of each specific value within the calculation.

(Poser Pro provides a way to define a colour value to suit each of these purposes: the Simple_Color node is automatically anti-GC'd by Poser Pro, whereas a User_Defined RGB value is not.)

pardon, but i'd be interested in learning to sRGB correct/anti-correct rather than gamma.

cobaltdream... I have an sRGB output correction shader, based on the sRGB shader that BB posted for his Artistic Lens (over in that thread).

I replaced the Artistic Lens nodes (Refraction and HSV) with an input node to plug in the linear value to be corrected, and tidied up the layout so I could see what was happening.

As it's basically BB's work, I'm not sure I should post it. (?)

See? You're not sure what you can and can't do?

Heheh. Ice-boy says it's all just parameter values, not programming, and anyway you can't copyright ideas, only implementations. Post it.

By the way, maybe you don't want GC or sRGB either - maybe you want tone mapping, particularly HSV exponential tone mapping. Physics isn't everything - sometimes CG is about art.

yes i think he could do it. but it comes down to respect. if you respect a guy who creates those amazing things then you dont post  or ask if you can.

True. I wavered before posting an experimental image using a single light and Blinn nodes (no diffuse) with GC at 1.1. It's TY2, so realism was hardly what I had in mind!

Ummm. I'm not sure how I go about posting my (your) shader now.... I know I have to pretend it's a txt file, but where do I put it so I can link to it? Anyway, here's a screenshot.

Linear Input goes into the LINEAR INPUT node.
Top 3 nodes calculate the linear part of the graph.
Bottom 7 nodes calculate the non-linear part of the graph.
The Switch nodes toggle the two components on and off, based on the threshold value.

(edit) hmmm... is that image okay, or a bit too fuzzy?

the image is fine, but isn't the point of sRGB conversion that it needs separate treatment for red green and blue?  oh, and i meant the equation, not the nodes.  if i want to do this to every material, i think i've got to start using matmatic.  since this thread had moved to that, i thought it was going to be all equations now.

Color_Math is separate treatment for Red Green and Blue - identical, but separate.

You can still use the two base calculations in this shader, but you will need a separate switch for each colour channel. That's easy enough to implement in nodes, but sorry I haven't learnt Matmatic yet. (I don't agree that non-familiarity with Matmatic syntax should exclude anyone from taking part in this discussion).

The equation implemented in this shader is:
IF(x <= .0031308, 12.92 * x, 1.055 * (x ** (1/2.4)) - .055).

Maybe the subject of sRGB correction would benefit from a new thread? RV is dealing with GC at present. Just a suggestion...  :O)

(edit) oh, I didn't see bb's post. Is it not possible that one colour channel could require the linear part of the graph, but another could require the non-linear part? So wouldn't we need to switch them separately?

Ignore me, I just answered my own question. The switch works independently for each channel.

I just dialled in an input colour with red > 0.003131 and blue < 0.003131, and each channel uses the appropriate linear and non-linear part of the graph. So all we need is the Matmatic for this..... :O)

Quote - ...Linear Input goes into the LINEAR INPUT node.
Top 3 nodes calculate the linear part of the graph.
Bottom 7 nodes calculate the non-linear part of the graph.
The Switch nodes toggle the two components on and off, based on the threshold value.

Now, I'm confused. I thought this was about converting existing colours so that Poser can work with them. Is that node set something you'd use to perform the conversion?

My understanding was - and now you can see just how sketchily I do understand things - that:

---colours come into the shader gamma-corrected, i.e, in sRGB format.

---The input then has to be anti-gammaed using this formula:
linearColourMap = sRGBColourMap ** 2.2
At which point Poser 5-6-7 can appropriately process the colour.

---Then, before giving giving those colours to the renderer, you gamma-correct them with:
coloursToRender = processedColours ** (1/2.2)

I'm relatively simple - hence the name of the thread - so this is all I've been able to digest. At this point, I'm not following this direction of this conversation anymore. Am I missing some important complexity? Or is my above approach too simplistic? Isaoshi, what are your nodes doing? Calculating for some threshold... why?

What am I missing here? I'm very slow and very thick... please explain.

Hi RV: sorry to confuse with this. 

Cobaltdream asked for the details of sRGB correction a few posts back. The shader I showed above is just an sRGB version of the very simple Output Gamma Correction calculation that we have been using here in this thread.

To explain briefly - Gamma Correction using a curve with a power of (1/2.2) is an approximation to accurate output correction to true sRGB colour space. The difference is only really noticeable at very low illumination levels, like deep shadows.

I did think it would be better to have a separate thread for this sRGB thing, but it showed up here. I agree it would be good to get back to basics in this thread!

Sorry.

Quote -

Quote - It doesn't have anything whatsoever to do with where you're plugging these values in. It has to do with what is the true numerical value you are trying to work with.

...
Take a specific colour value: (0.5,1.0,1.0) - a light cyan. Suppose this same colour appears in two places in the calculation of diffuse colour in a particular (hypothetical) shader.

But it is also used elsewhere in the shader to multiply the diffuse colour in order to reduce red channel intensity by 50%. In this case, you should not anti-GC it. If you do, you will reduce red channel intensity by around 78% (assuming GC=2.2).

Can we go back to basics?

My understand was that all but black 0, 0, 0 and white 1, 1, 1 needs to be anti-gammaed. Or should I have said all but 0 and 1 should be anti-gammaed.

Since:
1 ^ 2.2 = 1
0 ^ 2.2 = 0
So, it follows that:
1, 0, 0 (red) anti-gammaed is 1, 0, 0 (red).
Yes?

You guys are going to get sick of me....

Please don't apologise, Isaoshi... and thank you for explaining. Now that I understand the purpose, I think it's an elegant solution.

I'm sorry I'm so incredibly slow at all this, and thanks to everyone for their patience. Actually, your explanation with the cyan did clarify BagginsBill's point: that anti-gamma needs to be selectively applied not based on in which channel the process was going to end up, but rather what sorts of maths you were going to perform on it.

Am I anywhere near the target here?

Which - if this is true - means that I'm going to have to understand the inner workings of each node in order to prevent bogus colour processing.
Like, the Weave node, above. It has three colour channels: Base_color, Color_1 and Color_2. What is it doing with them? Just applying them incrementally to the different aspects of the weave spectrum - sheesh, I wish I had the right words to describe what my view is on this - or are colour maths being performed? In which case, my anti-GCing them prior to plugging the colours into those three channels is in error. Same with the light blue I took out of the Reflection_color channel.

This is all getting very confusing. I need some structured guidelines. Do this when you encounter that. If you are going to do this, don't do that. It's not just a simple matter of anti-GCing all colours at the input side of the shader, is it?

 No, we are not going to get sick of you! If I can't explain something properly it's my failing, not yours.

Back to basics....

If we are incorporating output gamma correction in our shaders (which we are), then:-

1. Any colour used within the shader on the basis of its appearance on screen (and that's how it should appear in the render) must be anti-gamma corrected on input. This applies to any colour channel.. diffuse, specular, ambient, translucent, reflection. It applies to a colour defined in a Simple_Color node, for example, just the same as it applies to colour maps.

(Your question about the weave node is a good one. Is it performing any internal colour maths? Would this maths give a different result if it used anti-GC'd versions of the selected colours? I don't know. But... someone presumably set up this weave node within the shader on the basis of how it appeared on their screen, either in the material room or in the render itself. So you could just anti-gamma correct the output of the weave node, and it will appear in your gamma-corrected render the same as you see it in the Material Room).

1. Any arithmetical operator expressed as an RGB fraction -- e.g. the (0.5,1,1) red-channel reducing multiplier I used as an example -- must not be anti-gamma corrected.

In my example, I wanted my RGB number to halve the intensity of the red channel in whatever light value is coming in from the scene, but not alter the green and blue channels. That's why I put 0.5 in the red channel, and 1.0 in the green and blue channels. It's already a linear-space number. If I were to anti-GC this number, it would change it to approx. (0.21,1,1), and when used as a multiplier it would reduce red channel intensity to less than a quarter of its original value.

yeah, it made a lot more sense to me when bagginsbill went into the whole anti-gamma/gamma in the artistic lens thread.  i also understand why we're circumventing the diffuse node for the alt diffuse node now..  as far as i can tell, basically, if it's plain node starts off looking like you want, and you're not just using it numerically (like transparency, bump, and displacement), you need to anti correct it.  by plain, i mean doesn't respond to light.  so the weave node would need anti-correction if you think it looks fine as is.  if you don't, then it needs different correction.

think about it this way: if you started with a simple color in and didn't anti correct it, when you corrected the end product, you'd be working with a completely different color than you started with.

this is why i'd like function node.  i think it would be much easier to understand and adjust if we could just apply transformations in one node rather than 3 or more. 

Beautiful discussion - very subtle points being raised. This is Node Cult stuff, but here at Renderosity. Ha!

Anyway, RV you're correct that for x = 0 or x = 1, x ^ 2.2 = x so gc and anti-gc don't matter. For any other value (or any color containing such value as a component) you must think about what it means and whether or not to use it.

RV, the Weave is blending the colors you give it, but in a complicated pattern (shaped like a weave.) This blending is the same as the Blend node, and it is color math. You are correct to wonder if it is a mistake to anti-GC the colors before using them in the Weave node.

Based on the weave node alone (leaving aside how its being used later) if we're thinking about it as if it were a baked image map node instead, we'd want to anti-GC it AFTERWARD, not BEFORE. Why?

Do you remember my demonstration a few weeks ago regarding the Blender node to produce a gradient between two colors?

Do you remember that when we make a gradient in linear space, we pass through different intermediate colors compared to the same gradient in sRGB space?

Everybody needs to go here:

http://www.renderosity.com/mod/forumpro/showthread.php?thread_id=2762503&page=6#message_3428749

Look at my gradient demos comparing a gradient in linear color space with the same gradient in sRGB color space. (or more specifically, the approximation to sRGB called GC(2.2) color space). Read what I wrote there until you can explain it without me.

So if we're talking about a pattern generating node that produces a pleasing color pattern involving gradients, and the author made his/her choices of colors and parameters interactively, while viewing a preview of this pattern on in the material room, then you must conclude you do not want to change the author's pattern. Procedural patterns are not right or wrong - they are what you wanted them to be. As the result of experimentally interacting with a gradient that was working in sRGB space, the results should be considered to be correct, a priori. Therefore, anti-GC that node after it does its gradient pattern building work.

Note, however, that this is precisely NOT, I repeat NOT, what happens in Poser Pro when you enable render GC. In that case, each incoming individual parameter is anti-GC'd and THEN the nodes get to make their patterns. In that case, there will be subtle differences between the GC and non-GC rendering of that shader, differences that go beyond luminance. They will involve the evolution of gradients through a different color space.

For this reason, the mechanical conversion of shaders to become GC shaders, while maintaining the original author's intent, will be very difficult.

After you get done figuring out whether to anti-GC before or after the Weave node, you have the odd fact that it then is multiplied with a shade of blue. Now you have to ask (as Izi pointed out) was that blue the result of a visual choice (I like this shade of blue) or was that blue the result of a ratio choice (I like this ratio of R, G, and B, as a multiplier, and the fact that said multiplier has an appearance of this blue is not relevant at all.)

Which is it?

Or, should you wait till after the multiply with blue to do the anti-GC? That's not what Poser Pro would do.

Poser Pro would have anti-GC'd the incoming colors to the Weave, which would alter the gradient intermediate colors produced. It would also have anti-GC'd that blue mutliplier. The product of those would be a new color that bears little to no resemblance, mathematically, to the color the original author intended, no matter how you look at it.

No, I'm afraid that the only way to maintain any conformance with the pattern the original author intended is to understand how the author arrived at that. In my opinion, the correct place to insert the anti-GC in that shader is right before the Diffuse node, not earlier.

Quote - Not sure how I'm supposed to feel about a reflection value of 3, but the rest I'm fairly happy with. I think.

Remember I've been saying over and over that you can't look at just one term and make sense of it. There are more terms involved here.

In the original shader you showed, the user had Reflect_Lite_Mult turned on. This introduces additional calculations into the Reflection channel.

In particular, Reflection_Lite_Mult will multiply the amount of incoming light with the Reflection channel data. This means that when light is less strong, the Reflect_Color will be diminished.

WARNING: This has no basis in reality. YOU SHOULD NOT USE THIS FEATURE IF YOU DO NOT WANT ME TO KICK YOUR ASS.

It is something (ugly) we have to take into account when analyzing what a shader is doing. Reflect_Lite_Mult is a difficult one to separate out. It means that the amount of incoming light is multiplied with the value, sort of like the Diffuse node would do. So we can approximate this flag with a white Diffuse node who's Diffuse_Value is 1.

Notice also that the value plugged into Reflect_Color (the Sphere_Map) is ALSO plugged into the Reflection_Value.

Whew. This is a crapload of nonsense, but if you're trying to reproduce it, here you go.

The Reflection channel is contributing

Reflection_Color * Reflection_Value * Reflect_Lite_Mult

to the sum of the output color.

I'm not going to measure that blue that's in there, just let's call that the reflBlue.

Based on the value and the connection we know that

Reflection_Color = reflBlue * Sphere_Map

We know based on the value and the connection that

Reflection_Value = 3 * Sphere_Map

So the contribution from the reflection channel, altogether, is

3 * reflBlue * (Sphere_Map ** 2) * Diffuse(WHITE, 1)

In other words, the pattern from the Weave (after sphere-map projecting it as a reflection map) is squared, multiplied with the blue, tripled, and also multiplied with the amount of incoming light.

Why!?! No f'ing clue, but if you're trying to reproduce that shader, and only add the GC effect, you have to reproduce all of that.

RV:

You didn't do all that, so your new shader is going to act very differently.

Furthermore, you didn't do the GC right - remember you must add together everything all into one color, then and only then can you perform the final gamma correction.

In your GC version, you left that whole business in its own channel. A GC shader does not leave anything plugged into anywhere else on the Poser Surface that generates color. All must go through your Pow node.

You must add everything together yourself, then send it through the Pow node.

Quote - But... someone presumably set up this weave node within the shader on the basis of how it appeared on their screen, either in the material room or in the render itself. So you could just anti-gamma correct the output of the weave node, and it will appear in your gamma-corrected render the same as you see it in the Material Room).

Right on, Izi. Go one step further, though and consider the multiplication with the blue. Is the blue the sort of ratio control you discussed, or was that arrived at based on the visualization after the multiply? Either way, the blue should be left alone. But Poser Pro will change it. This is one disadvantage of Poser Pro, and one reason why total understanding and total control of the shader color math is key.

This is like the difference between a Digital SLR and a Point-and-shoot. If you're going to put the SLR in automatic mode, don't buy it.

Quote - Look at my gradient demos comparing a gradient in linear color space with the same gradient in sRGB color space. (or more specifically, the approximation to sRGB called GC(2.2) color space). Read what I wrote there until you can explain it without me.

Right. I decided to do exactly that. Pretty much got my head around everything else that was going on, but this!!!

Quote - x = (U - .5) * 1.5 + .5

I really, really want and need to learn how to do this sort of pattern thing. Obviously, it is what creates the gradient, U being the U_Texture_Coordinate, which starts off on one one side as black and creates a gradient to white horizontally (side to side) and then I got lost. So, telling someone else about this, I'd be quite nebulous about this point.

From what I see, though, is that colours with values in their tuple other than 0 and 1 are going to compute brighter using the linear gradient method:
linearGradient = Blend(a ** 2.2, b ** 2.2, x).labelled("linearGradient") ** (1/2.2)

where you anti-gamma colours in each channel in the Blend node and x does the gradient thing in the the Blending channel, and then you gamma the result right there before the blender output.
But that x in the Blending channel which uses that U-formula thingie I'm totally stuck on. I couldn't begin to explain how that works. It's the horizontal gradient bit. I think I saw something about those U and V nodes in The Node Cult, plus we were starting to consider them in the hair shader in the Anisotropic thread on here.

Going to take this to work tomorrow to digest.

On to the next bit.

Quote - Furthermore, you didn't do the GC right - remember you must add together everything all into one color, then and only then can you perform the final gamma correction.
In your GC version, you left that whole business in its own channel. A GC shader does not leave anything plugged into anywhere else on the Poser Surface that generates color. All must go through your Pow node.
You must add everything together yourself, then send it through the Pow node.

Now, for an extremely dumb question.
If I have a different pattern - colours and glossy and clay and whatever - for the specular side of things that have nothing to do with diffuse, is it error to set up a:
nodes -> anti-gamma -> specular -> gamma -> whatever non-diffuse channel
thing for that for that purpose with its own pow(linearColour ** (1/2.2) node? I mean, it would be difficult to do conservation of energy... I realize that. But, is the whole idea wrong, based on what you've said?
IOW, do I plug in output from my final product gammaed-colour (through one and only one pow node) to alt_specular and Reflection_color?

Trying to ask a single question by itself, here:
Should there, in a "valid" shader, only ever be one gammaed output, i.e., one pow(linearColour ** (1/2.2) process?

Next question:
if this is true, does this single output only ever gets plugged into the alt_diffuse channel?

Next question:
and if this is true, does nothing gets plugged into other channels?

I'm clearly highly confused on this. And this post is replete with multiple compound complex question for which I apologise in advance. I've tried to simplify my questions as much as possible. Thanks for your patience.

Oh, and thank you for pointing out that those two:
Reflect_Lite_Mult
Reflect_Kd_Mult
were turned on. I remember reading discussion on this topic before, and had I realized they were turned on would have turned them off. Who knows what that would have done to the look of that material, though. So, I do a screen cap and then, turn stuff off and recreate a shader from scratch to reporduce the desired effect, except using the correct nodes and setting this time.

Right.

My approach to shaders is invariably: are they valid to begin with? I've had too many discussions with people mucking around in the material room to be convinced that shaders are always developed with a clear knowledge of what exactly is going on. People go after an effect. If the preview looks something like what they're after, they'll use whatever settings and nodes and whatever to achieve that effect. Some may even test that shader in a few different lights to make sure they sorta get a similar effect in other light conditions.

So, what do I do? Try to bring that shader back to some semblance of reality? Try to reproduce the effect but correctly, with a working knowledge of what nodes should be used to create that effect? Certainly, the latter, but implied here is that I possess a greater knowledge of shaders than most developers.

In which case, I'd better get crackin'... got heaps to learn!!

Quote - ... implied here is that I possess a greater knowledge of shaders than most developers.

Hehe... I think it's quite likely you already do! Someone referred in a recent thread to "a shader guru like BB or RobinsVeil (sic)" . You've made it, big time, name up in lights... with inverse square falloff, of course.

Quote - YOU SHOULD NOT USE THIS FEATURE IF YOU DO NOT WANT ME TO KICK YOUR ASS.

quickly writes a script to turn it off everywhere
I think I'll just add this in to my "switch all texture filtering off" script.

Quote - But Poser Pro will change it. This is one disadvantage of Poser Pro, and one reason why total understanding and total control of the shader color math is key.

Poser Pro does not anti-gamma correct a User_Defined node, I discovered, so there's an easy way round this.

Quote - Hehe... I think it's quite likely you already do! Someone referred in a recent thread to "a shader guru like BB or RobinsVeil (sic)" . You've made it, big time, name up in lights... with inverse square falloff, of course.

Oh my stars! All anyone has to do is read this thread and then read the VSS - Opinions thread to realize whilst there are people who are getting it, I'm definitely one of BagginsBill's slower students, the one he turns to with a feeling of dismay when my hand is waving in the air, thinking: "oh, no, not her again!"

Quote - ... I'm definitely one of BagginsBill's slower students, the one he turns to with a feeling of dismay when my hand is waving in the air, thinking: "oh, no, not her again!"

They are poor students who keep their hands down after tripping over the first few hurdles of incomprehension. I think anyone who is passionate about teaching a subject, like bb, must simply adore those who are passionate about learning it, like you. (I would say "and me" but I'm too prickly to be adored!)

I adore you both.

Thanks for separating your questions. Here are your answers:

Quote - Should there, in a "valid" shader, only ever be one gammaed output, i.e., one pow(linearColour ** (1/2.2) process?

Yes. Anything else and you're letting Poser add two values together and you're not gamma correcting the final combined color, which is what we're trying to do.

Quote - if this is true, does this single output only ever gets plugged into the alt_diffuse channel?

You could use others depending on why but you have to know why. The Ambient_Color is exactly the same as Alternate_Diffuse. Alternate_Specular and Reflection_Color and Refraction_Color are also identical, unless there is transparency involved. Then those three are different. Stick to Alternate_Diffuse for now. 

Quote - and if this is true, does nothing gets plugged into other channels?

Nothing in any other other color channels. However, Bump, Displacement, and Transparency channels are not color channels. There is no reason to manage these in some other way, and besides, there's no way to do it.

Quote - > Quote - Should there, in a "valid" shader, only ever be one gammaed output...

Yes. Anything else and you're letting Poser add two values together and you're not gamma correcting the final combined color, which is what we're trying to do.

I was afraid you were going to say that. The issue I saw with what I was asking was: the CoE thing wouldn't / couldn't be done properly because you'd be entering values for Poser to pass on to the renderer in more than one location (channel)... but I failed to even think it was adding colours. Yikes! Hypercolours. Right inside PoserSurface...

So, I'm back to square one with my face / makeup shader. I had kinda come up with a solution, but it's been rendered (pun intentional) invalid. So, I am still unable to get any gloss to appear on the lips to any degree - if any gloss appears anywhere, it's on the whole face.

Bill, I'm not going to ask you how to incorporate that into my shader, because you're making a competitive commercial product which will do exactly that with considerable finesse and it would be unethical for me to expect any further help now.

I now know what I can't do - I can't create a separate set of nodes and anti-gamma - process - gamma and plug into Alt_specular or reflection_color or any of those alongside of my current shader. In other words, I can't use the common model of one set of nodes for diffuse colour and another set for specualr effects.  All that information needs to come from the alt_diffuse channel.

I've tried to sort out from PR3 what was plugging into what, because I could do glossy lips with it, but oh dear, quickly got lost.

Back to simple node tricks. There must be some way to do this! I'll see what I can come up with.

Might be on to something?

I'm thinking of using a group of Blender nodes to daisy-chain my "glossy" nodes (not literally the Glossy node, but nodes to put gloss on lips and on eyeshadow) like I'm daisy-chaining my masks and colours.

I'm going to bed now, but I'm going to work it out in Matmatic and see how it looks - see what you think. I actually mucked around in the mat room for once, trying to see what Bias does to the Specular_Value channel in Specular (node, not the channel on PSurface).

I think I see a light here. More like a glimmer, but it has a wee bit of gloss on it.

Edit: re-reading that Bias and Gain section you so painstakingly put together....

wait a sec.  how is this different than changes to your specularity map?  i mean, it seems to me, that what you need is a mask on controlling whether one spec map is used or another and whether one diffuse map is used or another.  diffuse might be more difficult because you have different and less SSS on skin with makeup.  but i'd think the specularity / diffuse CoE is totally separate from controlling the specularity itself, which is what the spec map is for.  seems to me instead of one base map, you're now talking about 3 maps combined.  i mean, setting it up manually is kind of like weaving, but the concept is the same for n masked maps as for 2, right? 

edited to add... i'd think CoE would deal with the end result diffuse and end result spec, and your masks and maps would determine what the spec and diffuse were.

so i'd think (without accounting for bump and displacement, or transparency)

take all color maps and anti-correct them.
apply their various SSS cheats to them.
combine them according to their maps

take all specularity maps and combine them using the masks
apply the new specularity map to all the appropriate aspects of your specular node(s)

apply AO rules to both outputs
apply CoE rules to both outputs
combine
correct
feed into alt diffuse?

Precisely, CobaltDream. You spelled out exactly what I cobbled together last night. Only I didn't express it very well at 1 in the morning. Now, you've saved me the trouble.
I'll post the code later this morning...

What's nice about this is that I can apply differing degrees and strengths (or whatever is the proper term) to each masked area of specularity. IOW, eyeshadow shine should (and does) look different to lip gloss, and blusher doesn't have a shine.

Download this script. Read along as I talk about it.

The first few lines are just setting up some handy functions and a node for my gamma correction value.

def PM(x, lbl): return Add(x).labelled("PM:" + lbl)
gamma = PM(2.2, "Gamma")
def AGC(item): return item ** gamma
def GC(item): return item ** (1 / gamma)

PM makes a parameter node - takes a number and a label.
gamma is our default gamma value.
AGC is anti-gamma correction - use it on any incoming colors.
GC is our gamma correction - use it at the end to make the final output color.

Next is the a class definition I made up to help organize things.

For almost every opaque dialectric material, we only care about 3 things. We care about diffuse color, shininess, and bumpiness. Pretty much anything from skin, to paint, to lipstick can be made with only these three parameters.

So I define a class, called CSB to represent anb hold information about color, shine, and bump.

The init function is the constructor. In addition to the new CSB item being built, it takes 3 arguments; color, shine, and bump.

You can create one with anything you want for the color - just make sure it is a linear color, not an sRGB color. That means you can make one with an explicit color, or a node with a pattern in it, or an anti-gamma corrected image map. Doesn't matter what it is - everything will work.

I have invented this shine parameter - it does not correspond with any particular node parameter you've ever seen exactly. But you have seen it (in a somewhat different flavor) in the VSS skin template. There are many ways to interpret the shine, but we can generally say this: when shine is 0, you should have a completely flat matte surface. When shine is 1, you should have something that is super shiny like glass or beautifully waxed car paint. When something is very shiny, it should also include a reflection effect, not just a specular effect. We'll see how to implement these things later.

The last argument, bump, is quite straightforward. It's simply a bump pattern suitably scaled. It could be 0 for no bump, or it could be a Noise or Turbulence node with the scale already built in, or it could be an image map.

The only other method I put on the CSB class is the mix method. This method takes itself as the first argument, a. The second argument, b, is another CSB material you want to mix with this one. The third argument is a mask to control the amount of mixing or Blending of the two materials. It can be a constant, or it can be a pattern node like Spots, or it can be an image map.

The implementation of this method is incredibly simple. It creates 3 blender nodes using Blend. It blends the color, shine, and bump from a and b, according to the mask value. It creates and returns a new CSB object with these new blended values.

return CSB(
   Blend(a.color, b.color, mask),
   Blend(a.shine, b.shine, mask),
   Blend(a.bump, b.bump, mask)
  )

Next is a method called CSBSurface(item). It takes a CSB object and builds an actual Poser material for it.

First it pulls out the three CSB properties. Remember, these can be numbers, colors, nodes, images, whatever you've got in the CSB.

 color = item.color
 shine = item.shine
 bump = item.bump

The next step is to calculate a reflectionValue to use for controlling how much diffuse versus mirror reflection we get. I have included a nice little cheat I've developed that approximates the Fresnel equations to a very high degree without bothering with a ton of nodes.

 reflectionValue = Blend((1 - .18 * EdgeBlend(1, 0, 1)) ** 30.8, 1, .03)

This equation is not completely 100% accurate, nor is it particularly adjustable for various IOR, but it is close enough that you're not going to care, and it is very fast.

Now for the specular effect, I use Blinn. Remember that I came up with this idea of a single value called shine, which we get from the CSB object. Here is how I implemented shine.

 specular = Blinn(WHITE, .02 ** shine, .4, 4 * Bias(shine, .25))

Let's look at the eccentricity which controls the size of the highlight. When shine is 0, it will be .02 ** 0 which is 1. This is the maximum eccentricity. When shine is 1, it will be .02 ** 1 which is .02. This is the minimum eccentricity - a tiny point of light. We could try other more complicated approaches, but this suffices for almost everything.

For the luminance, I used 4 * Bias(shine, .25). I chose this formula not based on physics or anything, but just based on how I expect the appearance of a highlight to work out when I use shine values that make sense to me, like .25 for skin. When shine is 0, this is 0. When shine is 1, this is 4. When shine is .5, this is 1. When shine is .25, this is .25. Neat, huh?

OK so how are we able to get away with just one Blinn node? It's because the places where we need more or less specular can all be handled by just modulating the eccentricity and luminance. Since I've tied these both to "shine" in a nicely coupled way, as long as shine varies, so do both of these Blinn parameters. So you don't have to think too much about how to alter the shininess - just make a map that describes the shine level as a gray scale value from 0 to 1. And if you're mixing CSB objects, then these maps or patterns will be mixed appropriately, so that for any given spot on the figure or prop, there is a certain shine that should be applied there.

Next is the Diffuse component.

 diffuse = Diffuse(color, .85 * (1 - specular))

Here is where some of the conservation of energy stuff is applied. I would normally just use .85 for the Diffuse_Value, but I want the diffuse reflection to be suppressed if the specular reflection is high. By using the complement of the specular, I get an inverse relationship, such that there is at least a nod to CoE, if not totally physically accurate. Close enough, believe me.

Next is the reflect node.

 reflect = AGC(Reflect())

Notice I anti-gamma correct this. When you build a scene where all the shaders are producing gamma corrected values, then the Reflect node gives us data in sRGB space. We have to undo that before we add it to the other things, because we want to be doing linear math. In particular, if you're using my environment sphere, you're getting a direct reading off of a photograph and that is sRGB. So we AGC the reflect node here, like any other incoming material.

Now another nod to CoE comes next. I want to choose whether I do difffuse or normal reflection. A blender node always does a weighted sum of two things, with the weighting controlled by the third argument - the blending factor or mask. The way we're doing things makes this simple. The reflectionValue calculated earlier tells me how this material reflects based on viewing angle. I need to combine that with some respect for the shine level. Based on how I want shine to behave, I Bias the shine down a bit and just multiply it with the reflectionVlaue. That's my blending factor between diffuse and ordinary reflection. I store the result in nonspec, meaning this is everything but the specular.

 nonspec = Blend(diffuse, reflect, reflectionValue* Bias(shine, .2))

Now I combine the nonspec and the specular effect.

 output = nonspec + specular

and I gamma correct it.

 output = GC(output)

Now I just need to make a surface, put the output in Alternate_Diffuse, and put the bump in Bump.

 return Surface(color, 0, 1, 0, Alternate_Diffuse = output, Bump=bump)

That's all there is to making a pretty good opaque dialectric surface from a CSB item. Since the CSB item has already taken care of modulating color, shine, and bump, all that other stuff is out of the way already. In other words, making a mixed or layered multi-material surface is no harder than making a single-material surface.

OK so how do I use all that.

Well, first I make a CSB for skin. This is not the real good skin you see in VSS, but just your basic cheap procedural skin, with no brains to it. Of course you should use a color map here, and a bump map, and whatever other goodies you might have for your figure. I'm just doing a demo on some spheres. So this is what I did.

skin = CSB(.5 * AGC(SKIN), .25, .01 * (Turbulence(.02, .02, .02) - .5))

I'm using Turbulence for bump, I'm not bothering with variable shine but just using .25, and I'm not bothering with skin color details - just a constant dark skin, anti-gamma corrected, of course. I'm using the matmatic pre-defined color for SKIN. Not bad, you'll see.

Next I want to demo some blue paint.

paint = CSB(AGC(Color(.2, .5, 1)), 1, 0)

And some lipstick.

lipstick = CSB(Color(.2, .05, .08), .7, .03 *(Turbulence(.1, .1, .1) - .5))

Again, I'm using a Turbulence node, but you would probably want to use your figure's bump map. Usually we like to put a bigger scale on that, so you see me using .03 here, versus the .01 I used on the skin. Do what's right for your situation.

Now for my demo, I wanted a couple masks, one for paint and one for lipstick. I'll use these masks to layer the paint and/or lipstick materials on top of my skin material. Remember, we're not doing the whole surface yet. We're just modulating the CSB parameters. My masks here are just some Spots nodes with a little scaling and clamping. You would want to use your makeup masks that you drew for various things.

Once I have my masks, I can make a mixed version of skin and paint, or skin and lipstick, just by asking the skin to mix with one of the others.

paintMask = Clamp(10 * (Spots(0, 1, .2, .3, .4) - .5))
skinAndPaint = skin.mix(paint, paintMask)

lipMask = Clamp(10 * (Spots(0, 1, 1, .3, .4) - .5))
skinAndLipstick = skin.mix(lipstick, lipMask)

Now once I have one of these two-layer CSB objects, I can add the remaining material as a third layer, by asking the mixed material to mix with yet another material. I did both combinations.

skinAndPaintAndLipstick = skinAndPaint.mix(lipstick, lipMask)
skinAndLipstickAndPaint = skinAndLipstick.mix(paint, paintMask)

That's everything I wanted to demo. Now I just need to build my matmatic outputs list, generating a surface for each of these demo CSB objects.

outputs += [
 "Skin", CSBSurface(skin),
 "Paint", CSBSurface(paint),
 "Lipstick", CSBSurface(lipstick),
 "Skin+Paint", CSBSurface(skinAndPaint),
 "Skin+Lipstick", CSBSurface(skinAndLipstick),
 "Skin+Paint+Lipstick", CSBSurface(skinAndPaintAndLipstick),
 "Skin+Lipstick+Paint", CSBSurface(skinAndLipstickAndPaint),
]

In the bottom row is paint, skin, and lipstick.

In the middle row is skinAndPaint followed by skinAndLipstick.

In the top row is skinAndPaintAndLipstick followed by skinAndLipstickAndPaint.

I think you'll agree this is very well organized and easy to assemble different combinations.

Be sure to click for full size. Look closely at the speculars and reflections.