thanks for clarifying (and being willing to repeat yourself).  i think a percentage for that type of usage is very generous.   i've personally got no commercial plans at the moment.  but i really would like to make at least free dynamic clothes.  i've actually gotten into this because i got sidetracked while doing test images of a simple tunic i made for someone.  i eventually need a workflow for test images that doesn't involve working on materials pretty much at all.

i will say, lots of people who are well beyond noobs would probably like just materials and lights that work right.  even if they did follow your threads.  and lots (sadly) don't.  Poser is a tool for the average citizen to act out their creative impulses.  true, for most that's just pinups.  but i think there's some inherent value in having a creative outlet in life.   and if you just want to make stuff, spending hours figuring out materials and lighting can get in the way.  a decent level of realism is actually the most popular style for work in galleries here.  it's just that the average level of realism in the galleries  is dependent on the average level of realism in popular products and freebies.

Quote - we have to anti GC lights?

i knew i wasn't the only one! ;D  and ice-boy probably follows your work the closest.

Actually I did mention GC lighting impacts. In a post a week ago: (but of course you can't read every post I make)

Did you know that setting the light color is not the same as setting the light intensity when GC is involved?

With Poser Pro render GC enabled, all material node color parameters, including those on lights, are anti-gamma corrected before being used. This means that your 50% gray was not 50% gray. It was about 22% gray. That was multiplied with the 40% intensity, yielding an effective illumination of 8.7%, not the 20% you thought. So your effective total illumination from 5 lights was 8.7% * 5 = 43.5%, less than half of my single WHITE spotlight at 95%.

In your last post you said 40% * 50% * 50% * 5 = 50%. In that calculation what is the second 50% for? Without GC the calculation would be

Intensity * color * number_of_lights = 40% * 50% * 5 = 100%

With GC the calculation would be:

Intensity * color * number_of_lights = 40% * (50% ^ 2.2) * 5 = 43.5%

For this reason, I never use gray to decrease a light intensity. I always use white, and I use the intensity dial to adjust ... intensity.

Colbaltdream and ice-boy almost had the fatal heart-attacks.

no, not at all.  actually, i'm really low key about this. work on the other hand....

Quote - In your last post you said 40% * 50% * 50% * 5 = 50%.

pardon?  is that directed toward me?  because i don't remember posting that anywhere....

interesting thoughts.  i'll have to think about the relationship between color and intensity, and if there are any light colors i'd want to get to by colors with lower values rather than lights with lower intensity.  my thought is that i'd get what i wanted if i kept true to hue and saturation, and let intensity handle how bright.  but i could be wrong.

Sorry I was posting in a hurry as I had guests coming. My last post was a cut-and-paste from another thread, where I was discussing the total illumination from 5 lights, each with a 50% gray for color, was not 5 * mid-gray, because those colors were anti-gamma corrected.

I should have edited that a little.

so we dont need extra nodes in the lights?

 just dont use middle grey fo 50% of lights. but a white light with 50% intensity?

Well, see that's the thing. If you want neutral color lighting you use white or gray, then it doesn't matter what shade of gray it is, because GC can't desaturate what is already fully desaturated.

So if you use a gray,then really it is interchangeable with Intensity. For me, I never change the color of an infinite unless I'm doing a demonstration, because I want my scene white-balanced pretty much all the time.

But if somebody wants a colored light (not gray or white), and they have a specific color they want, that color must be anti-gamma corrected. Remember, the rule is all incoming color material must be anti-gamma corrected. You light color is incoming material.

aha  i see.
 so if i want an orange light (for example like  sunset) i need to anti-gamma correct . because if i wont i will not get the right color?

can i use the same shader like in the ENV_sphere?because i can not work in matmatic

All anti-gamma is the same.

Color_Math:Pow node
Value_1 = your incoming color, or white and connected to your incoming color
Value_2 = white - connect to 2.2.

NOTE:EDITED CORRECTION I WROTE THE WRONG FACTOR Value_2 should be 2.2

Quote - > Quote - we have to anti GC lights?

i knew i wasn't the only one! ;D  and ice-boy probably follows your work the closest.

I do try to follow but quickly get left behind trying to get my head around core concepts everyone else already understands, like Python functionality.... still studying Python class behaviour ... making headway, though - getting my head around the namespace/attribute/scope concepts and how they differ class to function.

In the meantime, you are all light-years ahead. I'll catch up though. Eventually. After all, this is a for dummies thread.

Might seem a bit premature, but I'm getting to this point:

Quote - Next I want to demo some blue paint...

What was your intended application for this paint, Bill? Eye shadow? Blusher? I can't tell from your code or from the explanation. Sorry.

In the original VSS (which is where the node set is meant to end up) we had lips as a separate material zone but connected to face and nostril in Shader Rules. In my shader I process the actual lip area slightly differently from the fade-in bit in the 1_Skinface region. I read in the Antonia thread you advocate not making the lip zone a separate material, but processing it all with masks in one material.

Question:
--since this is still V4 with her material zones, do I continue as before and make the lips, face and nostril materials obey one rule in Shader Rules?

Jeez, my question is crap. Sorry. This thread has become "nodes for the incredibly gifted"...

Quote - Might seem a bit premature, but I'm getting to this point:

Quote - Next I want to demo some blue paint...

What was your intended application for this paint, Bill? Eye shadow? Blusher? I can't tell from your code or from the explanation. Sorry.

I didn't have anything in mind. My point was that from the standpoint of the CSB concept, there's no difference between a color overlay, a bump overlay, a shine overlay, or any combination of these things. The different sections can be as wildly different as you like. CSB captures the essence of an extraordinary number of real-world materials.

Further, the mixing of CSBs encapsulates both the cases where you're dividing a surface into distinct, hard-edged regions, as well as smoothly blending one area into another - that's just a function of the gradients contained in the mask.

Quote - In the original VSS (which is where the node set is meant to end up) we had lips as a separate material zone but connected to face and nostril in Shader Rules. In my shader I process the actual lip area slightly differently from the fade-in bit in the 1_Skinface region. I read in the Antonia thread you advocate not making the lip zone a separate material, but processing it all with masks in one material.

Question:
--since this is still V4 with her material zones, do I continue as before and make the lips, face and nostril materials obey one rule in Shader Rules?

Jeez, my question is crap. Sorry. This thread has become "nodes for the incredibly gifted"...

I'm not sure what you mean by "process differently". Here's my point about multiple material zones. If you have two adjacent polygons in different zones, and you put the same shader on both, then they will look the same. If you put different shaders on each, then you have the potential of creating an abrupt, zero-width transition, i.e. no pixel obeying a little of both shaders. This is fine for wall meeets floor. This is not fine for cheek meets lip, because human lips do not suddenly appear within 6 nano-inches.

By "process differently" I meant: slightly different bump values going from mid-lip to edge (slightly different values in 1_Lip and 1_SkinFace), and slightly lighter colour for the main body of the lip vs the edge, so as to simulate lip-liner.
Note the word 'slightly'.

Won't be doing that now, since I can accomplish this much more effectively with masks, where a mask can indicate a shine gradient (which I think is awesome!) and other really cool effects!

Not a worry - I can make this work. This is an incredibly versatile script. On Node Cult I started a thread on elegantly-written code: been studying this over the past few days and I gotta say: this fits the bill (sorry, pun not intended).

Did my first render. One never shows first renders. Good reason for that.

But, the script works as advertised. Now, a bit of tweaking and getting a handle on that node-placement hack script you wrote for IsaoShi and we're laffin'....

I'll be back... and thanks, Bill.

like this? 

but can we have then the color in the preview?

p.s. so all the time we rendered the wrong colors?

Quote - > Quote - All anti-gamma is the same.

Color_Math:Pow node
Value_1 = your incoming color, or white and connected to your incoming color
Value_2 = white - connect to 2.2.

NOTE:EDITED CORRECTION I WROTE THE WRONG FACTOR Value_2 should be 2.2

like this? 

but can we have then the color in the preview?

p.s. so all the time we rendered the wrong colors?

That is the correct setup. Not "wrong" colors, per se, just that whatever color you wanted you had to put a much more saturated color into the light.  You couldn't just pick the color based on looking at it.

Now you can.

dumb me. i now tryed GC with poser pro and the same colors and its really different. poser pro GC was always nati-GC the lights.

dumb me to never noticed this before.

LOL. It's funny, I say words and I think people read and notice every subtle point. That's stupid of me. I should have been saying more details all along.

All I ever say is: All incoming colors must be anti-GC.

For me, this was obvious that it includes colors in light shaders. That's why I talk about IBL linear colors versus sRGB colors in the genIBL threads. It's very important.

yes. yes of course. thats why we you use the nodes in the ENV_sphere when doin an IBL.

pardon, but i'm still wondering about how we can use the new equation if you basically said it's wrong to not anti-correct images on input, and that we should preserve the hue and saturation shift, since you seemed to be saying that the new equation didn't do the latter and definitively said it didn't do the former.  also, i'm still wondering if you're saying IBL just doesn't work for any scene with flat surfaces.

Quote - pardon, but i'm still wondering about how we can use the new equation if you basically said it's wrong to not anti-correct images on input, and that we should preserve the hue and saturation shift, since you seemed to be saying that the new equation didn't do the latter and definitively said it didn't do the former.  also, i'm still wondering if you're saying IBL just doesn't work for any scene with flat surfaces.

I said it's wrong to not anti-correct images on input for GC. I didn't say that in the context of HSV Exponential Tone Mapping. I said the opposite - that HSVETM affords the possibility of getting decent luminance shifting while preserving hue and saturation, without having to anti-GC the incoming material. It is a way of converting linear to approximately sRGB entirely as a post-processing step. It is not based on the physics of light, nor on the mathematics of CG. It was developed in the context of manipulating HDR images.

Quoting myself here:

"Right! But it doesn't have that rapid rise from 0 that cobaltdream doesn't like. That's what causes terminators to look too sharp.

Also, while the curves are similar, this preserves hue and saturation! So you don't need to anti-gamma first. It kind of figures out what you'd get if you had done ant-gamma first, and produces similar results without doing so."

"By the way, the technique is similar to (or maybe exactly the same as) the tone mapping technique called HSV Exponential Tone Mapping or something like that. I can't find any clear CG-community approved exact mathematical definitions. I can only find verbal descriptions of these techniques in other products, like VRay and Kerkythea. In all cases they talk about adjusting luminance while preserving hue and saturation. It is from those little clues and the words HSV and Exponential that I guessed at how to do it."

Unlike GC, HSVETM does not change the relative ratios of R, G, and B. It scales them up or down together.

#1 is no correction
#2 is anti_GC the incoming color, do the diffuse+specular effect, then GC the result
#3 is take the incoming color AS IS, do the diffuse+specular exactly the same, then HSVETM the result

I'm using the HSVETM exponent 1/2.2 - 1 = -.545454 here so the luminance change is approximately the same.

There is a small difference in how the specular renders. Other than that, the GC and the HSVETM are very similar.

The HSVETM setup would work much better on the Artistic Lens than GC does, for example, as it works very well on rendered colors AS IS.

If you can put up with the slight difference in specular appearance, it's a good technique that let's you make a few less nodes in your shader. You still have to stop using the built-in specular and diffuse, because you need to post-process the result of adding those together.

Or you can use the lens, and don't change your shaders at all.

For me, the loss of character in the specular is probably a deal breaker. I tossed HSVETM out to you guys because I was investigating what it could do - what are its pros and cons, and I thought it would be good for you to give it a try. Why am I investigating it? Biting my tongue.

HSVETM holds up very well.

Quote -

For me, the loss of character in the specular is probably a deal breaker. I tossed HSVETM out to you guys because I was investigating what it could do - what are its pros and cons, and I thought it would be good for you to give it a try. Why am I investigating it? Biting my tongue.

SSS? :) 

Of course, we want SSS, but what about SSS would make me investigate HSVETM?

i dont know.  he he he :)

I hope you all won't mind if I go off-topic and discuss the mix.mm1.txt script again. I'm working really hard to get my head around how to implement.

My objective is to layer colours for eyeshadow, with eye-liner being the last eye-colour. I may or may not want shine for one or more of the colours.

I had actually typed a whole slew of questions but then I read and re-read your description again, and suddenly it gelled:

**# Main AGC objects first
colourMap = ImageMap().labelled("Color Map")
bumpMap = ImageMap(Background = setTurb).labelled("Bump Map")
skin = CSB(.5 * AGC(colourMap), .25, .01 * bumpMap)
 

Makeup colours

Blusher = CSB(AGC(IColor(237, 154, 130)), 1, 0)
highLight = CSB(AGC(IColor(196, 236, 220)), 1, 0)
eyeShadowA = CSB(AGC(IColor(223, 170, 137)), 1, 0)
eyeShadowB = CSB(AGC(IColor(27, 82, 60)), 1, 0)
eyeLids = CSB(AGC(IColor(16, 60, 52)), 1, 0)
eyeLiner = CSB(AGC(IColor(33, 0, 0)), 1, 0)
lipStick = CSB(AGC(IColor(223, 28, 0)), .7, .03 * bumpMap)
 
nailClr = CSB(AGC(IColor(138, 0, 17)), 1, 0)
 
blusherMask = ImageMap().labelled("Blusher Mask")
hiLightMask = ImageMap().labelled("EyeColour A Mask")
eyeShadAMask = ImageMap().labelled("EyeColour A Mask")
eyeShadBMask = ImageMap().labelled("EyeColour B Mask")
eyeLidsMask = ImageMap().labelled("EyeLid Mask")
eyeLinerMask = ImageMap().labelled("Eyeliner Mask")
lipStickMask = ImageMap().labelled("Lips Mask")
 
skinBlusher = skin.mix(Blusher, blusherMask * .5)
BlusherHilight = skinBlusher.mix(highLight, hiLightMask * .3)
HilightEyeshadA = BlusherHilight.mix(eyeShadowA, eyeShadAMask * .4)
EyeshadAEyeshadB = HilightEyeshadA.mix(eyeShadowB, eyeShadBMask * .6)
EyeshadBEyelids = EyeshadAEyeshadB.mix(eyeLids, eyeLidsMask * .9)
EyelidsEyeliner = EyeshadBEyelids.mix(eyeLiner, eyeLinerMask )
MadeupFace = EyelidsEyeliner.mix(lipStick, lipStickMask * .5)
 
limbsMask = ImageMap().labelled("Limbs Mask")
skinNails = skin.mix(nailClr, limbsMask)
 
nipsMask = ImageMap().labelled("Nipples Mask")
skinNips = skin.mix(skin, nipsMask)
 
outputs += [
  "-Skin", CSBSurface(skin),
  "-SkinNips", CSBSurface(skinNips),
  "-SkinNails", CSBSurface(skinNails),
  "-ShadowLipstick", CSBSurface(MadeupFace),
]**

Am I getting close, here?

Why do you use the maximum shine and 0 bump on eye shadow CSBs? Is it your intention that where there is eyeshadow, that material is glass?

Yes you're on the right track.

However, I would not keep changing the name as I do the mixes.

I'd just do:

csb = skin
csb = csb.mix[highLight, hiLightMask * .3)
csb = csb.mix(eyeShadowA, ...)
csb = csb.mix(eyeShadowB, ...)

This may not be obvious why this is better. Here's why.

What do you have to do in your script to skip one of the mixing steps. All I have to do in mine is comment that line out with a #.

What do you have to do in your script if you want to change the order? All I have to do is change the order.

I have to travel on business today so not much more posting from me.

Have a safe trip, Bill and thank you for mentioning those points about shine and bump... I hadn't addressed those aspects.

When you get back, I hope to have something a bit more polished.

Quote - Here is a render of all seven materials on seven spheres. 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.

I have looked at the speculars and reflections.

I'm finally using this tool (mix.mm1). Bill, another coup-de-grace! I never appreciated until now just how elegant this script is. It seriously does everything I need it to. The only thing that was keeping me from using it was, well, understanding what you were telling me.

I'm hopelessly thick, but as my boss back in Napa used to say: "Give you enough time, and you're quick." He was from Tennessee. Apparently that's how they talk, there.

Once again, thank you. I'll have a finished script ready soon, which I'll run by cobaltdream first, then I'll show you.

It's fun again! Long live Matmatic!

I don't think you're thick. Having brought me back here, I looked over the last few pages of stuff I wrote and I'm really surprised anybody can follow me at all. This is not casual reading. LOL

As I've mentioned before, I was working on a book and I've started again. I reviewed 20 pages of stuff I wrote a few months ago, and I'm looking at it and thinking it isn't going to be easy for people to get a lot from it. I feel like I have to go slower and introduce things a bit more gently. In 20 pages I hammered out like 30 different formulas that are really useful, with graphs, but didn't show examples in real use. This is a real puzzle for me - how to introduce all this new material to people who do not read equations or Python scripts as easily as I do.

RV: Rather than me just guessing how well it works, can I send you the chapter on Basic Unit Functions, as is, and just get your reaction?

PM me an email address, please.

CobaltDream, too.

And maybe ice-boy would like to take a crack at it?

ooooo, yay!  PM sent!

RobynsVeil and i have been emailing back and forth to share our understanding of Matmatic scripts.  it's been very enlightening.

Quote - ooooo, yay!  PM sent!

RobynsVeil and i have been emailing back and forth to share our understanding of Matmatic scripts.  it's been very enlightening.

I second the motion, m... particularly enlightening for me! And thank YOU.

Oh, and BB... PM sent (tingling with anticipation)

Are you going share any of this enlightenment with those of us lurkers who are living vicariously through you?

well, i'm not sure what would be useful for others yet. the only things that seem general so far are:

• in Python, it seems like the first argument of a class'  method is always the object itself.
• the color step (and therefore step) node is inverted from the function described by the manual.

oh, other aspects:

you can tell Matmatic to put a number higher than 1 into an equation, and even when it autormatically generates Color_Math nodes, it generates hypercolors internally. that is, it will look like it's using white, but the color is actually whatever you told it to be. i assume the converse is true, that numbers less than 0 become colors that look like black and are less than it.  this is useful if  to know if you look at the actual materials you're making to double check what your script is doing.

so the stuff i've been talking about with RobynsVeil mainly revolved around the principles of functions, classes, constructors, and class methods and properties.  i can try to elaborate here if anyone has questions about those.

in the end i can say, i looked at the beginning Matmatic stuff and the internal help, and it didn't do 1/10 of what just working with Mix.mm1.txt has done.  my suggestion is to take it, and simplify it.  just have it make corrected diffuse materials with no specular, and build from there. 

earlier in this thread, i offered to do a tutorial that would build the script from that base and go to bagginsbill's final version.  the offer's still open if anyone's interested.

Quote - the offer's still open if anyone's interested.

How many votes are you looking for? Here's one....

I may have misread something I saw elsewhere, perhaps even in one of our emails, CD, but I'd like to make something clear.

Poser internally does maintain full information about improper colors, i.e. colors with component values outside the range 0 to 1.

By improper, I mean more than 1 (a hyper color) or less than 0 (a hypo color).

If you have a series of nodes in which intermediate results are improper, and you later bring them back to being proper, it will work.

Furthermore, it is all too easy in matmatic to create improper colors that end up as color parameters of nodes. These will not display correctly in the material room, if you were to look at one of these nodes. But the real data is there. If you touch one of those using the color picker, you will lose the value that matmatic put there.

For example:

hyperOrange = Color(1, .5, .25) * 5 # a seriously hyper color

b = Blender(BLACK, hyperOrange, .2) # Value_2 is hyperOrange and will not preview correctly

s = Surface(b, 1, 0, 0)

This surface will look like an ordinary proper orange.

The Blender will take the hyperOrange and mix it with black, keeping only 20% of the hyperOrange, because the Blending factor is .2. Mathematically, then the output of the Blender is:

(1-.2) * BLACK + .2 * hyperOrange
.8 * 0 + .2 * Color(1, .5, .25) * 5
0 + .2 * Color(5, 2.5, 1.25)
Color(1, .5, .25)

Voila.

right.  i just wasn't sure that it was happening.  i was having such horrible problems with my sRGB/asRGB equation, and i knew the equation wasn't the problem but how i was implementing it.  so i had to look in the material room to see what was actually happening.  so i tried to make everything as explicit as possible, just in case.  and since i looked and only saw white, i thought that might be the problem.  and at first i thought that was taking care of it (i have no idea what went wrong with that test), but then i found that the Step function test for my conditional was just plain backwards.  since that meant a really incorrect linear transformation for most of the shader, i was getting awful, uncontrollable yellow bloom.  it turned me all around.  i questioned everything i was doing. 

so when i got myself straight, i double checked and found Matmatic and hypercolors performed exactly like i had been expecting in the first place.  but since i couldn't see that, i didn't know it.  so i thought i'd explicitly mention it, in case someone had a similar problem.

Looking for a second vote?  Here it is.

cool.  i'll start putting something together (late) tonight.  sound good?

Oh dear. I was just doing my own modification to the sRGB stuff, to use Color_Step instead of Blender.

I told you that in matmatic, a <= b uses Step or Color_Step as needed - not true. This is a bug.

So make sure you explicitly ask for Color_Step(a, b). Sheesh - good thing I kept the "beta" going for 3+ years. Finally found a bug.

Here are the functions you need.

def IF(test, tv, fv): return (1-test) * fv + test * tv
def SRGB(x): return IF(Color_Step(x, .00304), 12.92 * x, 1.055 * (x ** (1/2.4)) - .055)
def ASRGB(x): return IF(Color_Step(x, .03928), x / 12.92, ((x + .055) / 1.055) ** 2.4)