Summary:-
 

The shader GC method we are used to is: anti-gamma correct all inputs (colours and colour maps), carry out linear lighting calculations, and gamma correct the result. Applying this to a simple colour map and diffuse light shader:-

Output = GC( Diffuse( AGC( Color_Map ) ) )

where:
AGC is the anti-Gamma Correction function:  ** 2.2

GC is the Gamma Correction function: ** (1 / 2.2)

bb demonstrated that this is the same as:-

Output = Colour_Map * GC( Diffuse() )

In other words, gamma correct a Diffuse node on its own, and then multiply by the colour map. No anti-gamma correction required.

The screenshot shows my shader setup for this. Thanks to Robynsveil for pointing out an error in it, which I have corrected, and for the Matmatic script which generates it:

Surface.Alternate_Diffuse = ImageMap("toon1.png") * (Diffuse() ** (1/Add(2.2, 0)))

The Diffuse_Value can of course be reduced to less than 1.0 if required.

I caught this in the other thread and I found it rather intriguing how it was simplified from it's original concept.  It will be rather interesting to see some application renders between old and current thinking.  Also, how would specular setup come into play with this new Gc dynamics?

There is zero mathematical difference between the old and new methods, assuming bb did his sums right. (That's bordering on heresy!). But adding in the other effects might be a bit awkward.

The suggestion I made in the other thread about adding the (attenuated) Diffuse and Specular after separate gamma correction is clearly wrong, as that would be a non-linear addition.

I need more bananas... oh, and chocolate.

I'll just have the chocolate, thanks, Izi. :biggrin: Long as it's dark. :laugh:

I'm trying to get my head around the logic of WHITE * Light Intensity to the power of 2.2. Or does diffuse() do some calculations that change that value of Color(1,1,1)? I'm finding it hard to imagine this, but then, perhaps a tutorial on the diffuse node would be in order, here?

BB says: "The diffuse node does an internal calculation to determine the illumination and multiply that with the incoming clr."

So, basically it's diffout = clr * I
But clr isn't going to be WHITE, is it? It's going to be that colourMap that you are going to be multiplying with light intensity.

Am I way off base here??

That would be reasonable, Robyn.  Based on the Gc curve, white and black should be relatively unaffected by any modification.

um, i think you guys should keep in mind that he did say "if you're only doing diffuse calculations."  i can already tell you because my scripts allow me to switch on and off both linearization and correction that my non-linearized results are (imho) completely different than my linearized ones.

edited to remove completely irrelevant info.  sorry to misread your post Robyn.  i'm still not sure i understand it.

Quote -
I'm trying to get my head around the logic of WHITE * Light Intensity to the power of 2.2. Or does diffuse() do some calculations that change that value of Color(1,1,1)?I'm finding it hard to imagine this, but then, perhaps a tutorial on the diffuse node would be in order, here?

so, yeah, it does that multiplication that totally changes the base color, right?  you only get Color(1, 1, 1) where I = 1.  where I is anything else, you don't get the same color anymore.  or am i missing something?

Quote -
BB says: "The diffuse node does an internal calculation to determine the illumination and multiply that with the incoming clr."

So, basically it's diffout = clr * I
But clr isn't going to be WHITE, is it? It's going to be that colourMap that you are going to be multiplying with light intensity.

Am I way off base here??

well, color is anything you want it to be, right? if it's white (or 1), what you have is simply the light illumination.  and while you could definitely say that realistically nothing is either pure white or pure black, i don't think those are unreasonable values for a surface color.  but the yeah, color could be any color, right?  or am i missing something?

Well, I was kind-of looking at that shader of Izi's, and there's a diffuse node with nothing but white in it. So:

Surface.Alternate_Diffuse = ImageMap("toon1.png") * (Diffuse() ** (1/Add(2.2, 0)))

The:

Diffuse() ** (1/Add(2.2, 0))

is what I'm having trouble with. Diffuse() isn't actually doing anything that I can see. It's just multiplying white by whatever light intensity is in the scene.

hmmm.  i'm not sure i see why that's confusing.  that's exactly what diffuse is supposed to do.  or is it just because you have diffuse separate from the color instead of the color plugging into diffuse? 

That's right... I just tested it, and the above strategy does not produce the same effect at all as my original antiGC -> diffuse -> GC-correct method at all. To my mind Diffuse() is supposed to multiply colours with the existing light, I thought. Not WHITE and the existing light.

Yes, this only works for diffuse. I can't actually see any way to add in other effects linearly, such as specular and sss, that won't over-complicate the shader again.

( The Diffuse node will do its work on white just the same as on a colour map input. It's working out the effect that the scene lighting will have on any given diffuse colour, using white as its reference. A point which receives very little light will give a near-black output from this Diffuse node. A point which receives full white light will give a white output. A point which only receives blue light will give a blue output... etc. )

But before multiplying the colour map by this output, we have to make sure they are both linear, or both non-linear. The colour map is already GC'd, so we GC the Delta before multiplying. Multiplying two gamma-corrected colours is mathematically okay, as bb showed:-

 ( LinearColour ** n ) * ( Diffuse ** n )  =  ( LinearColour * Diffuse ) ** n

In words: multiplying gamma-corrected colour (the colour map) by gamma-corrected diffuse is the same as multiplying linear colour by diffuse, and then gamma correcting the result.

The difficulty comes when we want to add other colours, such as specular.

Cross-post with RV and others. Hmmm... the maths is correct, I'm sure, so where is the difference coming from?
I can't look at it now as I'm going to visit my Dad in hospital. Laters.

Hope he's going reasonably good today, Izi... my thoughts are with you both.

Okay, I did some tests. Bagginsbill is gonna cringe when he sees these, but oh well. These are screen caps of the original antiGC -> diffuse -> GC-correct method that we all know and love (ignore the other nodes on there for the moment):

And here is what I'm understanding is being suggested - note the difference in the PoserSurface preview window:

...and then, with colour plugged into the diffuse(diff_color) channel and Diff_Value set to .85:

I went back and forth between plugging that last one in and the first one in, and there actually is an appreciable difference.

ok, i see where i'm getting confused in the first place.  Diffuse isn't in sRGB space in the first place.  Diffuse is linear calculation, like everything else render based.

so not linearizing the original but correcting the the result is: (color * Diffuse) ** 1/n

but linearizing first is: ((color ** n) * Diffuse) ** 1/n

which is equivalent to : color * (Diffuse **1/n), but not (color * Diffuse) ** 1/n.

Oh!
Yep, that works. I had the process backward.

so i'd have to completely redo my shaders to actually test this.  i don't think i could use this in any of them, though.  i'd have to be able to separate all linear components from all sRGB components.  and i don't just use the power function for linearization and correction, so i'm not even sure that even this basic version would work for me.

I'm so used to thinking "Poser needs linear" that the concept of fixing the diffuse node simply wouldn't enter. And how this will work with CoE and all that is going to be a puzzle.

Far out - I still have a lot to learn about looking at maths and seeing the node - really fluffed this one up royally... how freakin' embarrassing. Oh well, BB and you guys need a good laugh from time to time - happy to provide that!

oh, no, i was totally thinking like you were for some reason.  the whole thing is getting into rethinking correction as well as linearization. but you basically have to be able to say here's our linear portion of our shader, and we can just correct that and multiply it by the sRGB portion of our shader.  works just fine if you have no color tricks up your sleeve.  i think it's a problem if in fact you wanted to, say, add a color mapped SSS portion to a color mapped diffuse portion. i personally just improved my lycra shader by linearizing at a different stage.  and i'm not sure how refraction and reflection would factor into all this.

i'll definitely think about how to streamline my node count and work my equations in general, especially since i use so many nodes for my equations.  but it's a back-burner sort of thing for me right now.

izzy, does yer/bill's new gc node tree prevent the alt_spec channel from causing surface to emit lite
in scene with no directional/IB lites? (poser 7 or later, GI/IDL enabled)

( OT. I only just got back from South London. Lesson learnt: DO NOT attempt to travel anywhere in southern England on Easter Bank Holiday Monday. Stay at home. )

Miss Nancy, I'm not sure I understand what's behind your question. Is there a new bug that causes the Alt_Spec channel to give a positive output when it has a zero input? Surely not... it's more likely that I'm just missing the point!

This alternative GC shader will only replace the Diffuse part of the gamma-correction shader that we know so well. As to adding other lighting and correction effects, we are still at home base. In fact, I am creeping closer to the conclusion that this alternative approach is going to be of no more than academic interest.

And if that sounds provocative, well, it's meant to be.... poke, poke, Mister C!

yes, that's the point.  if all directional lites are zero (dark scene), then a surface with alt_diff=0
would not glow in the dark.  otherwise, that and sevl. other channels will emit lite
with IDL/GI activated.

p.s. I was hoping some of them would try exposure control, but apparently they won't.
in re: poser, GC is the thing with much more extensive explanations.

Hey, sorry I wasn't around. The Easter holiday consumed me.

cobaltdream -

Quote - um, i think you guys should keep in mind that he did say "if you're only doing diffuse calculations." 

Bingo. I've warned you guys before I'm fond of parsimonious verbiage, particularly when I'm writing something to provoke thought and discussion. It worked perfectly.

So it came to light through your discussions that this is probably just an amusement - not particularly a useful simplification except for a clay or dirt shader. And so that's all it is. An interesting curiousity - a simplfication that has only a limited set of circumstances in which it applies.

But the more important thing is to become comfortable manipulating algebra to draw conclusions about how to build shaders. In that regard, this is a very good "etude".

For the last 3 weeks, I've been exploring the ramifications of powers and logarithms. I haven't discovered too much that applies to shaders, but my algebra chops are seriously improved. I ran into this particular case during that process and it occured to me that it applies to the GC workflow for a diffuse-only shader. Thinking it was neat, I wrote about it.

I, too, don't understand your question, Miss Nancy. I've seen you mention something like this before, and I don't get it. I remember answering a similar point you made a while back, and you didn't follow up, so I supposed that was the end of it.

Alternate_Diffuse and Alternat_Specular (and a couple others) represent positions in the shading equation where you get to add a term to the sum that it calculates.

Of course, if you insert (plug in) a constant value, then the shader glows.

However, I never do that. I always connect a lighting node, which means in the absence of light, that term is 0. The notion that these channels glow in and of themselves isn't correct.

Given a shader root node that calculates:

A + B + C

And you put A = 0, B = Diffuse, C = Specular, then you get:

0 + Diffuse + Specular

Which is a shader that produces a diffuse reflection and a specular reflection.

If on the other hand you put A = 0, B = 0, C = RED, then you get:

RED

Which is a shader that always outputs RGB(255, 0, 0), no matter what.

It's not particularly difficult to grasp that if you insert a term that is never 0, the output is never 0. Therefore, the output would "glow".

Why is it black?

Anybody? Anybody? Bueller? Anybody?

Hint.

The Diffuse node formula (roughly) is:

Diffuse_Color * Diffuse_Value * Cosine(alpha) * LightColor * LightIntensity

That is only for one light. When there are multiple lights, that is evaluated for each light and these are all added together.

Quote - So it came to light through your discussions that this is probably just an amusement - not particularly a useful simplification except for a clay or dirt shader. And so that's all it is. An interesting curiosity - a simplfication that has only a limited set of circumstances in which it applies.

Well, I've actually implemented this curiosity: 1, it works, 2. saves me a node, 3. exercises the bean. Thanks.

Quote - But the more important thing is to become comfortable manipulating algebra to draw conclusions about how to build shaders. In that regard, this is a very good "etude".

There were a few obscurities (to me) that prevented the abstraction that would have made the exercise work for me. No question it was neat and did sort-of make me look at what is happening differently - we are still feeding diffuse()/Poser linear information, right? not fixing the diffuse() node? - but those core concepts that cobaltdream finally clarified to this difficult-to-penetrate grey matter haven't moved much.

A bit OT, but I still can't reconcile the concept that if Poser needs linear information to process colours correctly and only the fewest are giving Poser that due to ignorance or apathy or expecting Poser to do the right thing with colours, why has it been left this way? IOW, why doesn't the diffuse component do GC internally, instead of allowing the entire bloody Poser community to produce rubbish? I see so much yellow bloom in the galleries it's sickening: yes, I know the information is available here, but jeez, some artists don't even go in here.
So, it's not getting out there. Sorry, but I have an issue with that. GC is not a Pro feature if people unwittingly produce crap because they don't understand they actually need to compensate for a Poser shortcoming with extra nodes in the material room. If GC were part of the process by default, lights would be designed around it and people would be producing better renders "out-of-the-box".

Quote - Hint.

The Diffuse node formula (roughly) is:

Diffuse_Color * Diffuse_Value * Cosine(alpha) * LightColor * LightIntensity

That is only for one light. When there are multiple lights, that is evaluated for each light and these are all added together.

Which is a bit different to:
diffout = clr * I

Rethinking everything. I tend to look at details and fail to abstract the core equations. Something wrong with me, there.

The Diffuse node doesn't do GC internally because GC should happen after all the terms are added together. Only when the Diffuse node is the only node is this simplification correct. In all other cases it is incorrect.

Assuming you're using linear input colors (which we create from color chips or from images by anti-gamma correcting), then the standard diffuse plus specular effect is literally a plus:

Diffuse + Specular

This sum must be GC'd.

(D + S) ** (1 / 2.2)

There is no simplification for that.

Suppose there is a reflection term as well, then it is:

(D + S + R) ** (1 / 2.2)

Except that when we do shader GC, the reflection is already non-linear and must be anti-GC'd, so we do:

(D + S + (R ** 2.2)) ** (1 / 2.2)

Combining the diffuse color map, C,  linearized, this is:

((C ** 2.2) * D + S + (R ** 2.2)) ** (1/2.2)

In general, the shader equation is a bunch of terms added together, and then a power is applied at the end to get GC. There is no mathematical simplification of this, because there is no simpler way to write

(A + B) ** C

My trick that started this thread was because there is a variation of:

(A * B) ** C

That gets us to a shorter result, when A is actually A ** (1 / C):

((A ** (1 / C)) * B) ** C = A * (B ** C)

See that? You just move the parenthesis from (A * B) ** C to A * (B ** C), assuming that you really wanted A ** (1 / C).

Quote - GC is not a Pro feature if people unwittingly produce crap because they don't understand they actually need to compensate for a Poser shortcoming with extra nodes in the material room. If GC were part of the process by default, lights would be designed around it and people would be producing better renders "out-of-the-box".

Except for all the people who don't understand why all their purchased light sets look like crap when you enable GC.

For example, we have Colm over at RDNA (a pretty smart guy and a good Poser artist) saying over and over that he doesn't like GC and suggests that people not use it.

GC is not for people who buy products that were designed to work right only when GC is not used, i.e. when compensating for gamma is done the hard way.

Yes, there is an easier way - enable render GC. But that has so many ramifications. Too much content exists that simply gets bolloxed by enabling GC. So people who generally buy content, and do not create content, simply would not use GC for the most part. Worse, if it was just turned on always, as it should be, these people would complain that Poser is borked.

Quote - > Quote - Hint.

The Diffuse node formula (roughly) is:

Diffuse_Color * Diffuse_Value * Cosine(alpha) * LightColor * LightIntensity

That is only for one light. When there are multiple lights, that is evaluated for each light and these are all added together.

Which is a bit different to:
diffout = clr * I

Rethinking everything. I tend to look at details and fail to abstract the core equations. Something wrong with me, there.

Well, not different. I was leaving out irrelevant details. I used the letter I to represent

Diffuse_Value * Cosine(alpha) * LightColor * LightIntensity

diffout = clr * I

or more fully described:

diffout = clr * (Diffuse_Value * Cosine(alpha) * LightColor * LightIntensity)

My version of Poser Pro 2010 has built-in rhetoric....

BagginsBill-

Quote - For the last 3 weeks, I've been exploring the ramifications of powers and logarithms.

Part of me wants to think that things like integrals, finding limits, and differential equations would be really important when it comes to manipulating lights and shaders.  I mean if all this stuff is physics based and calculus is good when it comes to physics...

I know this is OT, but part of me is surprised poser doesn't have some kind of node where you can write your own equation on the fly instead of attaching a bunch of nodes one at a time.  Example, it seems like basic gamma correction is X^(1/2.2) or something like that.  Well typing in something real quick (copy and paste) when you know exactly the equation you need might be a lot easier than a long chain of nodes where each node only does one little thing.

I vote for user created node types in poser 9.

/Winterclaw runs off

Winterclaw,

I'm curious as to whether you wrote that knowing about matmatic or not knowing?

I've heard it mentioned a few times and remember seeing it in Acadia's sticky but I've never used it so I can't say anything about it.

matmatic is a Python script I wrote for Poser. You can enter expressions for shaders in matmatic scripts, using the full power of the Python programming language plus the matmatic library, and it produces ordinary Poser nodes that implement what you said.

For example - this is a matmatic script for a typical GC shader that anti-gamma corrects a color map image, produces balanced diffuse and specular effects, and then gamma corrects the output.

s = EmptySurface()
gamma = PM(2.2, "Gamma")
map = ImageMap().labelled("Color Map")
spec = Blinn(WHITE, .1, .4, 1)
EmptySurface(Alternate_Diffuse = (Diffuse(map ** gamma, .8 * (1 - spec)) + spec) ** (1 / gamma))

Ah.  Well that would get the job done... however part of the reason I asked for custom nodes was to keep the mat room cleaner and another part of the reason was that I've seen several times that Poser's implementation of a certain node or way of doing things is odd or doesn't work right.  I was thinking if we could do custom nodes than if... crud I forgot who owns poser... anyways if they don't fix those nodes for poser 9 and you run into a case where you need that feature and you need it to work right, you could either write a new node or DL one from somewhere like renderostiy.

Anyways, if I get a chance, I'll look into matmatic.

What you describe is under discussion.