So:
**
def makeSurface():
  # Gamma-correction node
  gamma = Add(2.2).labelled("GammaCorrection")
 
  # Placeholder for colorMap
  colorMap = ImageMap().labelled("Color Map")
 
  # Colours to fiddle with
  ltBeige = Color(.98,.94,.88)
  ltBlue = Color(.91,.95,.95)
  
  # Underlying skin tone
  baseTone = SimpleColor(ltBlue * colorMap).labelled("BaseTone")
  
  # Complexion
  setSkin = Spots(
    Base_Color = baseTone,
    Spot_Color = ltBeige * baseTone,
    Spot_Size = .1,
    Softness = .35,
    Threshold = .7,
    Noise_Type = 2).labelled("Complexion")
 
    # Anti-gamma process
  linearColormap = (colorMap * setSkin) ** gamma
 
  # Set up specular node
  setSpec = Blinn(1,.4,.4,.4)
  
  # Set up the Diffuse node, keep it from exceeding conservation of energy with Specular
  setDiff = Diffuse(linearColormap, .7 * (1 - setSpec))
 
 
  
  # Setting up PoserSurfacce
  s = Surface(1,0,0,0)
  s.Diffuse_Color = colorMap
  s.Specular_Color = WHITE
  
  # keeps diffuse_color from doing anything but just displaying in the pose room
  s.Diffuse_Value = Add(0,0)
  s.Highlight_Size = .02
  s.Bump = Sub(ImageMap(Background = Turbulence(.05,.05,.05,8,0,.5,.15)).labelled("Bump Map"),.5) * .03
  
  s.Alternate_Diffuse = (setDiff + setSpec) ** (1/gamma)
  
  return s
 
makeSurface()**

Nope.

baseTone already is the multiplication of ltBlue * colorMap.

Then you when do this bad thing:

linearColorMap = (colorMap * setSkin) ** gamma

you're multiplying the colorMap with itself. Remember the base color fo the spots (mostly what it produces) is baseTone.

So when you multiply colorMap * setSkin you're really doing colorMap * colorMap * ltBlue. You don't want to do that.

setSkin (as you've called it) already is the final color. All that remains is to anti-gamma that.

linearColormap = setsSkin ** gamma

Look here's one way:

baseTone = SimpleColor(ltBlue * colorMap).labelled("BaseTone")

setSkin = Spots(
    Base_Color = baseTone,
    Spot_Color = ltBeige * baseTone,
    Spot_Size = .1,
    Softness = .35,
    Threshold = .7,
    Noise_Type = 2).labelled("Complexion")
 

Anti-gamma process

linearColormap = setSkin ** gamma
 

Here's the other way:

baseTone = SimpleColor(ltBlue * colorMap).labelled("BaseTone")

setSkin = Spots(
    Base_Color = 1,
    Spot_Color = ltBeige,
    Spot_Size = .1,
    Softness = .35,
    Threshold = .7,
    Noise_Type = 2).labelled("Complexion")

setSkin = setSkin * baseTone

Anti-gamma process

linearColormap = setSkin ** gamma
 

The second way is just factoring out the common factor. It works just like factoring the addition of a product.

Just as in arithmetic you learned this rule:

ax + ay = a(x + y)

I'm teaching you a new rule:

Spots(ax, ay, ...) = a * Spots(x, y, ...)

I get the feeling like my understanding of this isn't up to asking a question, but here goes:

I would use Spots(x, ay, ...) if I want the tint only affecting one channel and Spots(x,y,...) * a if I want it affecting all colour-based channels?

Yes

Well , not in general, not all color-based channels.

This isn't about matmatic. This is how the node works.

Spots produces one of two colors. If you pre-multiply both, that's the same as post-multiplying the spots with something.

You can't generalize this, however. For example, pre-multiplying each input to a Velvet node will not produce the same as post-multiplying. The reason is the internal math of the velvet node is not simple addition. But the internal math of Spots is.

Thank you, Bill.

In order for this to sink in properly, I will now endeavour to recreate in Matmatic code your eye shaders for PR2.  I feel that this will be the best way to be able to see shader functionality properly: break it down into code. Oh, and I will be putting gamma correction code in all my projects from now on.

I've been thinking about this all day.

Another thing I want to do is change how freckles are distributed on the face. I've observed that their distribution and density tends to vary a bit as one comes down the face. There's less on the jaw and chin, whilst the heaviest concentration seems to bee on the cheeks and nose. I found your freckle mask - can't remember from where, probably RuntimeDNA, and intend to use it.

The pseudo-code or whatever ya wanna call it?

Well, for one thing, since the freckle texture based on Spots is going to be affected by the mask, I won't be tying it into the baseTone anymore. Can't have masked areas no longer affected by Spots also missing that ltBlue tone. The colorMap will have the ltBue color multiplied in.

Remembering your suggestions for makeup for VR3, it will involve a blender node, to which the spots and the freckle mask somehow tie in.

Thinking out-loud, here.

Been a busy day in recovery, so I'll need to just sleep on it for now... I'll let you know how I go in a day or two.

The general strategy for masking an effect in matmatic is to do two equations. The first equation describes the math without the effect. The second describes the math with the effect. Then you drive a Blender to run both and choose (or mix) according to the value of the mask.

So:

colorMap = ImageMap("").labelled("Color Map")
color = colorMap

using WHITE initially means it has no effect, but can be changed later in the mat room

generalTint = SimpleColor(WHITE).labelled("Tint")
freckleTint = SimpleColor(ltBeige).labelled("Freckle Tint")
normalSkinColor = generalTint * color
freckles = Spots(1, freckleTint, ...)
freckledSkinColor = freckles * normalSkinColor
freckleMask = ImageMap("").labelled("Freckle Mask")

application of mask to choose between normalSkin and freckledSkin

color = Blend(normalSkin, freckledSkin, freckleMask)
color = color ** gamma
diffuse = Diffuse(color, ...)
 

I am printing out every word of yours and every image you posted on this thread, Bill. I've come to the horrible realisation that my reading of this material has not been very careful: moreover, I had printed out the VSS thread some time back and was reading it at work and WOW, so much of it made sense, now... but I also realised to my horror that you had had to repeat yourself so much on this thread ... so much of it was covered on THAT thread.

Sheesh!

So, if I go silent for a bit, it's not because I'm off doing hair or make-up or something: I'm carefully memorising some of these concepts in order to avoid stupid mistakes in the future.

Took your ingredients (above) and did this:
**
def makeSurface():
  # Gamma-correction node
  gamma = Add(2.2).labelled("GammaCorrection")
 
  # Placeholder for colorMap
  colorMap = ImageMap().labelled("Color Map")
  skinColour = colorMap
 
  # Colours to fiddle with
  ltBeige = Color(.98,.94,.88)
  
  # Underlying skin tone
  generalTint = SimpleColor(WHITE).labelled("Tint")
  freckleTint = SimpleColor(ltBeige).labelled("Freckle_Tint")
  normalSkinColour = generalTint * skinColour
  
  freckles = Spots(
    Base_Color = 1,
    Spot_Color = freckleTint,
    Spot_Size = .1,
    Softness = .35,
    Threshold = .7,
    Noise_Type = 2).labelled("Freckles")
  
  freckledSkinColour = freckles * normalSkinColour
  freckleMask = ImageMap().labelled("Freckle Mask")
 
  skinColour = Blend(normalSkinColour,freckledSkinColour,freckleMask)
  # Anti-gamma process
  skinColour = skinColour ** gamma
 
  # Set up specular node
  setSpec = Blinn(1,.4,.4,.4)
  
  # Set up the Diffuse node, keep it from exceeding conservation of energy with Specular
  setDiff = Diffuse(skinColour, .7 * (1 - setSpec))
 
 
  
  # Setting up PoserSurface
  s = Surface(1,0,0,0)
  s.Diffuse_Color = colorMap
  s.Specular_Color = WHITE
  
  # keeps diffuse_color from doing anything but just displaying in the pose room
  s.Diffuse_Value = Add(0,0)
  s.Highlight_Size = .02
  s.Bump = Sub(ImageMap(Background = Turbulence(.05,.05,.05,8,0,.5,.15)).labelled("Bump Map"),.5) * .03
  
  s.Alternate_Diffuse = (setDiff + setSpec) ** (1/gamma)
  
  return s
 
makeSurface()**

I used a freckle mask you'd offered on RDNA or somewhere some time ago... seems to work (meaning... after distributing with VSS, the freckles are appropriately masked out). I'll have a closer look tomorrow.

There's so much I suddenly want to do with shaders and everything, but first, before I start doing anything, I'm going to make sure that every concept you so painstakingly shared is going to be a solid, well-trialed reality to me.

It's Friday night here in Oz. They let me off early from recovery. A little. Good job they did: don't know I could stay away from working on this shader much longer.

At first, I was doing pretty well. I had some lights that seemed to bring out the best in the bump map. Here's how I see bump:
**
s.Bump = Sub(ImageMap(Background = Turbulence(.05,.05,.05,8,0,.5,.15)).labelled("Bump Map"),.5) * .03

** where s is actually the PoserSurface. So, I'm plugging in a turbulence node right into the background channel of the bump map. To do what? Create a bit more bump? Stir it up a bit?

All this reminds me of when I finally started coding in VB... actually coding. At first, I knew what I wanted to do, and went in search of other, more knowledgeable people's code to do it with. Hey, I'm a nurse. I didn't have the time or resources for formal computer programming training. Surprisingly, in this way I learnt the functions and when to use them, to the point where I could sit down and just write code and have it all work. Do it enough, and you get a feel for it.
Now, it's boiling down to determining 1. what do I want to do 2. what do I use to accomplish it with 3. which nodes go with what?

Not that I don't have plenty of great examples. I'm actually using Bill's Vr2 - no, you won't recognise it here, Bill:
and I'm pretty sure I haven't arranged nodes groups by functionality, but at this point: who cares! The meat of the shader is in putting together these statements:

**s.Bump = Sub(ImageMap(Background = Turbulence(.05,.05,.05,8,0,.5,.15)).labelled("Bump Map"),.5) * .03
**
not the resulting set of nodes.

Still, I want to get the relationships of the functions (nodes) right. Up to now, Bill's been giving it away. He basically gave me the ingredients on that little shader up there. He understands what needs to happen and when... and I have realized that at this point, I don't. I've been playing with that shader, trying to add features from that Vr2 shader like AO. Not obvious.

Here are my assumptions about scripting for Python, as applied to Matmatic:
-- code is interpreted (or processed, whatever) sequentially, line by line ... so it's important where you put what. Can't reference something that hasn't been created / initialized / dealt with yet. Just like any other programming language. Functions are processed when they are called, including UDFs.
-- You can create bogus shaders with code. Even if you've got the math right. It can happen unless you understand the relationship of materials to light

The more tricky part of shaders still needs to be discovered: what goes with what. At this point in time I'm looking at AO. Picked up that in Pr2 it's got a close relationship with the diffuse node. And in most discussions on Node Cult and here, the relationship between the AO node and the diffuse node appears strong, but I'm not sure about how the association works. Diffuse has something to do with light and colour and ambient occlusion has to do with light and shadow. Usually lights are involved with creating shadows, but from what I've read Poser has shortcomings (not sure what they are or if I'd understand them if they were explained to me) with regard to creating believable ambient occlusion under all light settings.

So, I'm trying different combinations. VSS and Matmatic make it very easy to quickly see results.

Oh, and I still have nostril glow. Even after killing all lights and:
Adding a light.
Selecting the light properties.
Checking the "Infinite" option.
Shadows at Depth map - tried Ray-trace as well... same result
Editing the Shadow Min Bias: setting it to .1
Switching to the light parameters.
Setting the shadow map size to 1000.
Setting the xrotate to -20
yrotate to 10
zrotate to 0

...and Rendering with Cast Shadows and Raytracing on, raytrace bounces 1, irrad. caching 50, pixel samples 2, min shading rate 1, min displ. bounds .008, use displacement maps on.

Might have been my shader? Now, I hadn't introduced any AO at this point - it's that shader from 9 messages or so ago.

Wow - big post. Let's take small steps. I'm going to give you quick recipes, sort of like "30 minute meals". That means this is the easy version. It is not what you'd get in a gourmet restaurant, i.e. one of my full-bore shaders, ok?

OK So here's the recipe for AO. Multiply the AO node with your diffuse value. If you are using a constant for diffuse value, such as 1, then all you need to do is 1 * AO, which is AO. See?

Suppose I have this fragment:

spec = Blinn(...)

diff = Diffuse(color, 1-spec)

The second expression in the Diffuse constructor is my diffuse value, i.e. the brightness of the diffuse reflection.

So to integrate AO into that I will bring the diffuse value out into a variable, for clarity and improved readability, and then multiply it with the AO:

spec = Blinn(...)
dv = 1 - spec
ao = AmbientOcclusion(...)
dv = dv * ao
diff = Diffuse(color, dv)

Regarding the ImageMap Background=x - this is not a Poser shader node thing, this is a VSS thing.

Recall that VSS copies shader Templates to actual target figure materials, and is supposed to convert the template to a final shader based on what it finds on the figure already, particularly with regard to image map file names.

So when you have a Bump Map in the template, there are two major situations VSS has to deal with:

A) It can find a Bump Map file on the target
B) It can NOT find a Bump Map file on the target

I, as the designer of the VSS script algorithms, am perfectly clear on what to do in case A. I should plug the bump map file into the template shader where you specified the Bump Map. That's clear to you, too, I hope.

Now what is the protocol for case B? I decided to leave it up to you, the designer of the template shader. I just needed to come up with a way for you to instruct VSS what to do in case B.

Are you able to guess?

In case B, VSS will remove the Image_Map node and use what is plugged into its Background instead.

So what you see is template instructions to VSS on what to do in case B.

s.Bump = Sub(ImageMap(Background = Turbulence(.05,.05,.05,8,0,.5,.15)).labelled("Bump Map"),.5) * .03

In Case A VSS rebuilds that for you like this:

s.Bump = Sub(ImageMap("actualBumpHere.jpg"), .5) * .03

In case B (no file defined), VSS rebuids that for you like this:

s.Bump = Sub(Turbulence(.05, .05, .05, 8, 0, .5, .15), .5) * .03

In general, any VSS template shader can have any number of named image maps in it. Each of these is a placeholder to be populated with a filename during synchronization. In the case where no filename is available, the value set in the Background of the image map will be used as a suitable substitute.

If the substitute value is another image map, and it cannot be synchronized either, and the second map has an alternative, it will be used as the alternative to the first image map as well. In otherwords, image map alternative substitution is recursive.

You might notice that in some of the shader I put out, the Specular Map background points to the Color Map. That means I, as the designer of the shader template, am informing VSS that if it can find a Specular Map, use it, but if it can't, to substitute the Color Map instead. Further, you may see that the Color Map has an alternative as well, which is a simple skin-like color.

Wow, so much for Nodes for Dummies. This thread makes my head hurt. :)

Can we talk about Turbulence?

I've been attempting to get a satisfactory level of bump, and have been experimenting with Turbulence. I can't say I'm making a whole lot of sense of my experiments, so I need a basic understanding of what does what.

So some basic questions.

Does Turbulence interpret the bump map, or is it creating extra turbulence, quite apart from the map?

If I'm trying to get smoother and rougher, should I be doing this primarily with the Gain parameter, or the xyz Scales?

What's the difference between "Original" and "Improved" Noise Types?

What is Octaves? Is this a multiplier of some sort?

Edit: I guess part of what I'm trying to determine is whether I need to be doing most of my tweaking in the Material Room, or the real answer lies in improving my bump map itself in terms of levels of contrast etc. I'm struggling to get a balance between the visibility of wrinkles I'm creating over against the more general turbulence of the skin.

Fun thread, hey?

You need to understand something about the shader script first, Believable. The script gets run in Matmatic which generates a material file (mt5). This file then gets loaded into the VSS prop under material Template Skin. Now, from what I understand from Bill's post just above yours, VSS makes some decisions about what to put where depending on what it finds.

VSS assumes that you either have a colourMap (jpg UV mapped to that body part) for your various materials... or not. A bumpMap or not. A specularMap or not. It decides when you click synchronise what needs to happen based on what it finds out in the material fields.

I tested this: took my bump map node out of my 1_SkinFace material, then synchronised. So, it plugged in a math_functions(sub) 1,.5 and plugged in that Turbulence node with the above parameter values into Value_1 of the Sub node.

Thanks, RobynsVeil. It should be understood that I have already run VSS, and am now tweaking various parts as I find necessary. I'm not really concerned about the scripts at this point, just understanding what the facets of the Turbulence node are doing.

As to the AO, I'm struggling a bit. Probably doing something stupid, so I'm looking at each and every symbol to make sure I didn't put a + when I was meant to put a . I tried this (leaving out stuff that hasn't changed):
**  # Specular node
  setSpec = Blinn(1,.4,.65,.4)
  
  # Sets the diffuse value, which is going to be whatever's left over from subtracting 1 from the specular value
  setDiff = 1 - setSpec
  
  # Ambient Occlusion node
  setAmbOccl = AmbientOcclusion(.7,40,.1,1)
  
  # Could also be expressed as setDiffVal = setAmbOccl   ??  trying to get my head around shortcut statements
  setDiff = setDiff * setAmbOccl
**
  # Underlying skin tone
  baseTone = Blender(colourMap, Blender(ltBlue * colourMap, ltRed * colourMap, .5).labelled("BaseTone"), .7)**

and then:
**  # Gamma-correction process
  linearColormap = setSkin ** gamma**
** 
  # And finally, that diffuse node with all values where we want them!
  setDiff = Diffuse(linearColormap,  setDiff * .7)**

and finally:
**  s.Alternate_Diffuse = (setDiff + setSpec) ** (1/gamma)**

which is no different. Preview looks fine... colours are all there. Skin renders monochrome. Obviously preview isn't going to give you all the information... long ago stopped trusting it.
What am I missing about:
spec = Blinn(...)
dv = 1 - spec
ao = AmbientOcclusion(...)
dv = dv * ao
diff = Diffuse(color, dv)

Where you said color, I'm assuming you mean my linearColormap (which includes that gamma-correction stuff), not just colourMap (the imageMap) itself? Or, if so, where to I do gamma-correction now? colourMap, btw, is referenced by a new Blend thingie where I try to bring a bit more warmth into the skin with:
**  # Underlying skin tone
  baseTone = Blender(colourMap, Blender(ltBlue * colourMap, ltRed * colourMap, .5).labelled("BaseTone"), .7)**

I feel I'm so close... attached you should find the entire script - just removed the mm1 bit...

@ Believable:
I haven't been able to find a decent breakdown one how exactly turbulence works, but you can find some fascinating applications of this function which might give some insight:

www.runtimedna.com/mod/forum/messages.php
and do a search for "turbulence"

and here's an interesting application of turbulence on brick:
www.castleposer.co.uk/articles/material_bump_brick.html

Other thing you can do is set it up as a material on a simple surface, change the parameters and render... see what it does.
Coming from a musical background, I say "octaves" has to do with frequency, as in: how dense the pattern is or something? Guessing, here....

Thanks, RobynsVeil... I searched on Turbulence Node at that RDNA forum, but didn't come up with much that looks relevant.

But brick article at castleposer is pretty neat... not sure what it means for my implementation, but it's neat.

I do suspect that much of the problem I had was in the map... in order to get the wrinkles strong enough, the skin was too rough. Not enough contrast, I think. Am still experimenting.

Are you using that shader I put up (can't really call it mine, since BB provided all the ingredients)? You might try bringing the bump value down from .03 if you find the skin is too textured to look healthy or pretty. Like .025 or even a bit less.

Quick answer, although I gotta read some more stuff and don't have time. The Turbulence, as I've used it, is doing NOTHING if you have a bump map file. Even if you plug it in yourself into Background, that channel does nothing when the file fills the UV area completely. That's why I use that channel to indicate what is the alternative to using a bump file. It's a dummy - a waste - a useless user of space.

The Turbulence pattern is built up of noise at various frequencies. The more higher frequencies you ask for the more busy the pattern is (less smooth, more detail.) Each octave is twice the frequency of the next one below it. If you ask for 8 octaves, you will have information in the pattern that is 1x, 2x, 4x, 8x, 16x, 32x, 64x, and 128x the basic frequency of the pattern.

The basic frequency is set by the scale parameters on the node. The smaller the scale, the higher the frequency. The scale can be different in each of the 3D axes, x, y, and z.

The Bias and Gain alter the resulting data before delivery from the node. When Gain is increased, the mid values are pushed more towards the extremes of 0 and 1 (black and white). When the Gain is decreased, extreme values are pushed more towards the middle .5 (gray).

The Bias shifts all the values towards 0 (when bias is below .5) or towards 1 (when bias is above .5). The amount of shifting is in proportion to the bias value with respect to .5. In other words, bias = .7 would produce a shift from .5 to.7, and all other values slide in proportion to where they are. Bias = .2 would produce a shift from .5 to .2.

The Original versus Improved Noise_Type has to do with the underlying pseudo random number generator used. In Poser 5, the random number generators used were somewhat inferior. As a result, some visible non-randomness shows up in certain situations. To rectify this, the makers of Poser introduced new, improved random number noise generators. However, to respect the fact that this would perhaps alter the appearance of some shaders which were just fine the old way, they give us a switch to choose, and the default is to do it the old way to maintain backward compatibility with shaders developed before the improved version was available.

Thanks for that info, BagginsBill. That certainly explains why I wasn't seeing a difference when I dropped the Turbulence scale from .05 to .01.

RobynsVeil, no I didn't use a shader you posted - didn't even know that's what that was; I thought it was part of a conversation you were having with BB.... or maybe you're not referring to the attachment just above.

Anyway, I'm relatively happy with the default VSS shader at the moment; I'm just trying to get the bump right before I do the final tweaking of other stuff.

Will post the results I'm presently getting when I have a couple renders to show. But since it turns out this isn't node-related, perhaps I'll start another thread.

Oh, and FWIW - my bump value is presently at .0045 (note the extra zero), so not really a strong setting... but I guess my map is pretty strong.

Oh, what a complex web we weave, when first we practice to...
...write scripts.

Not even going to mess with AO right now. Read a bit on the VSS Opinions thread about what all's got to be considered, and I'm just not going there. At the risk of seeming analog, I thought I'd pursue my first objective with Pr2:
marrying much superior skin-tone technique with whatever make-up schemes I wanted.

I wasn't liking how the shader tended to attenuate the colours of my jpg make-up schemes. So, I created a mask, one to block out the effect of the shader (some, to a certain degree, not completely) over those areas I want the make-up to shine through.

Thus:
**...
  # Placeholder for colourMap
  colourMap = ImageMap("HeaMULolita.jpg").labelled("Color Map")
...
  # Gamma-Corr apply
  linearColormap = setSkin ** gamma

  # Set up specular node
  setSpec = Blinn(1,.4,.65,.4)
  
  # Set up the Diffuse node, keep it from exceeding conservation of energy with Specular
  setDiff = Diffuse(linearColormap, .7 * (1 - setSpec))
  setShader = (setDiff + setSpec) ** (1/gamma)
...
  s.Alternate_Diffuse = Blender(setShader, colourMap, ImageMap("HeaMkLipsEyes.jpg") * .9).labelled("MakeupMask")
...**

where ... is unchanged code from above.
What do they say about "a little knowledge is a dangerous thing"? I wonder if there's an inverse-proportion rule that applies here? If so, I'm deadly.

Two new challenges have arisen. One, now I've got a second version of the shader with code specific to this mask for the face and lips. Hey, no problem, right? I just create a new rule in VSS - kinda like what we were doing in Vr3 a while back, there - and pop that resultant mt5 in there. No dramas. Oh, and in the final version, I'll remove hard-coded references to any ImageMap files for that bit that goes in the template. That's just for testing. And that's what I did. And it worked. VSS is marvellous... so flexible!

However, you can see that I've kinda circumvented the gamma-correction within that last  Blender because I reference the colourMap node directly for the masking bit... and from a principles standpoint that just seems wrong. Oh, and it kinda looks wrong too. Seems the whole thing should be gamma corrected.

So, I did. Created a separate placeHolder for the gamma-corrected version of colourMap:

CGcolourMap = colourMap ** gamma
...
**  s.Alternate_Diffuse = Blender(setShader, GCcolourMap, ImageMap("HeaMkLipsEyes.jpg") * .9).labelled("MakeupMask")
...**

which then gets referenced in that last Blender. Looks better.

Probably still not right, but whoa, most of Heather's make-up looks much stronger, now. We've gone from:

to:

blending quite nicely with the shader. I'm not saying this is an improvement, but one can see the make-up scheme more clearly. And onecould dial in how much one wanted to see within that Blender node (currently set at .9).

Still a bit of work to do on those lips. Still, I feel I'm making headway. At this point, I could even explore which make-up colours go best with which skin tones, and do the skin tones when I set baseTone:

**  # Underlying skin tone
  baseTone = Blender(colourMap, Blender(ltBlue * colourMap, ltRed * colourMap, .5).labelled("BaseTone"), .7)
**

BTW, it's funny how, even after seeing how much easier and logical it is using code to create shaders, I still end up going back to the mat room and try to re-arrange the nodal spaghetti. Why?? What's the point?? Old habits die hard.

Little update on Matmatic shadering (don't wanna have young BagginsBill shuddering, so I won't post the code) ... here's what it produces:

5 materials for my latest character - to be published as soon as the testers give me the green light - in one sneeze: face (makeup set), limbs (for tatts, if I want them), nails, nipples (and other areas where I don't want my shader to over-ride the underlying texture) and skin. No, the code is not pretty - part of the reason is so that I can make a pretty arrangement in the mat room - but it seems to be working. HOWEVER, I'm still learning things about gamma correction and conservation of energy and keep runnng back to my code to tweak it some more.

I only do nodes in the mat room to check on colours, any more. Everything else is done in Matmatic. It is the most amazing tool... and if I understood maths a bit more, it would magnify the "amazing" to "phenomenal". So, I look at other people's code. There are some bright lights out there. Makes me feel really dim!

Key principles I go by in my code:
  --if an image (colourMap) file is used, it's gamma-corrected before use, and un-gammaed after processing, before I output to the alt_diffuse channel. Sound right?

  -- the diffuse values are balanced with the specular values (to equal 1 and no more than 1) in all instances before output.

Not even going to try to deal with AO or SSS or any of that - only just getting my head around this. What I would love to see is what other people have written in terms of scripts.

RuntimeDNA has been down for a while, which is frustrating since so many links here point to there. Any idea when they're planning on being back up? Wanna do some more reading!

is there a good site where the math nodes are explained? 
i only found this site
www.castleposer.co.uk/articles/maths_add.html

And, here's a render of that above-mentioned character - "Heather" - using that shader:

One disadvantage to this shader that I haven't figured out how to get around is: the colours and such don't output to the preview window. That's okay by me - I can always do  quick 30-sec render to check my work, but some people might find that a show-stopper.

Just looking at this render: looks like I might have to tweak the eye-shadow mask 2 a wee bit... I did two layers of colour because I just wasn't getting the colour depth I wanted, so yes, I kludged it. Two layers created the effect I wanted. Obviously I'm still unclear on some aspect of the Blender node. Or perhaps it was the way light fell on the eyelid that gave the impression it wasn't being shaded to the degree I was hoping for.
Besides the eyeshadow mask, need to redo the brows. Going to allow slight colour variation there, so the brows can match the hair.
And the bump seems to be going into the skin, not out. Maybe bring the bump down a titch, too...
Details, details.

Quote - is there a good site where the math nodes are explained? 
i only found this site
www.castleposer.co.uk/articles/maths_add.html

I believe BagginsBill is writing a book on just that. I'm so far behind you Ice-Boy in this regard it ain't funny, but it's not keeping me from banging away at it. I'm finally getting to a point where experimentation is beginning to make a bit more sense, but apart from the node reference that BagginsBill provided with MatMatic and what you've found at CastlePoser, not much structured stuff seems to be out there.

the manual from poser is very bad.  so i am googling he he :) 

You can even say that the Poser manual is useless... why something so important should be glossed over by all manuals on the subject that I've found gives rise to the impression that those that wrote the manual were fairly clueless how to take full advantage of this incredibly rich aspect of their product.
Good luck googling - I haven't found all that much, myself...

question about the reflect node.
if we use more then 1 reflect node in the material ( only eyes for example) does this mean that it will render two times longer? 

other question. with the image node we can offset in teh U and V direction. can we somehow do a trick to offset other nodes? for example the reflect node or the diffuse node.

i know a very strange question.

Quote - question about the reflect node.
if we use more then 1 reflect node in the material ( only eyes for example) does this mean that it will render two times longer? 

The reflection part will be twice what it was before, but that is not all the time, so not two times longer.

Quote - other question. with the image node we can offset in teh U and V direction. can we somehow do a trick to offset other nodes? for example the reflect node or the diffuse node.

i know a very strange question.

I wish. No.

grrrrrrrrrrrrrrrrrrrrr POSEEEEEEEEEER

Whilst this post might seem a bit tangential and non-sequitur, I've exhausted all other venues to ask this question, and it is about nodes. And, I'm a Dummie, so it all fits.

Mr Baggins lit a massive fire with his exhortation to gamma-correcting our materials. I've re-read the how-to thread several times, but I can't help but feel this is but the tip of the iceberg of what needs to be discussed on this topic. There are so many different materials for so many different types of objects and such huge runtimes to convert. A simple "just do it" is unsatisfactory.

I have questions.

The whole conservation of energy issue and how it relates to GC was left open-ended: sort of an "it depends" kind of non-direction. Too many loose ends, and then the burning question: how many of you are converting your materials? How are you doing it? with a script (Matmatic) or by copying and pasting a little set of nodes from a prop to your material and making the necessary attachments... or...???

Why is this not being discussed anywhere? I've tried to bring it up in the Poser Users forum I belong to and cited examples on how it might be accomplished easily, but haven't gotten any sort of interest or buy-in or acknowledgement or bloody anything, really - quite frankly, I'm convinced they're hoping I'll just shut up about it and go away or something. I know I can be very annoying...

BUT!

The renders!

Far out... they speak VOLUMES! Every material I convert comes to life. I've done before and afters and jeez, there's no question this is a valid activity to be engaging in. So, why aren't we creating a GC trading post? Freebie GC upgrades for Poser 5, 6 and 7 users? People posting GC versions of popular clothing items? Or am I tiptoeing into a copyright infringement zone... heck, it's a shader, right?

Been trying to sort out how one could (script-wise) add the shader to an existing material whilst keeping the original imageMaps and stuff. That would be a cool script to write. It would have to detect the material setting already in that zone, and just add those nodes, and make all the connections.

This post will probably be ignored... I'm kinda getting used to that, now. Just wondering if there are any other artists out there as impressed as I am with this who might be interested in starting a discussion group on how to optimize a method to GC a whole runtime of materials.

Anyone?

 Because those who have Poser Pro will have overblown GC shaders if you do that, since Poser Pro applies GC by default. If you're going to have GC shaders aplied, make sure it's easy to re-adjust the level of GC like VSS's skin shader is.

How many have upgraded to Poser Pro? Am I the only Poser 7 user?

I suppose I should have said this GC strategy applies only to Poser 5, 6 and 7 users... which are in the thousands. With the economy the way it is, I doubt that many of us are going to be able to afford upgrading to Poser Pro any time soon.

But, you illustrate my point. My simple solution to managing GC probably isn't going to be very practical if I'm distributing GC'ed material to the community at large (which would include Poser Pro users). No discussion has been forthcoming from anyone about how this might be accomplished. The shader that comes with VSS is a skin shader, and has properties specific to skin. Reverse-engineering this shader to let Parmatic manage non-skin materials is a bit beyond my capabilities.

By your answer I gather you feel that this is not the right venue to discuss this? or that gamma-correcting material is an inappropriate activity since Poser-Pro users will not be able to use the GCed material?

Please explain.

 No matter whether you distribute gc-shaders or not, part of your userbase will have to make changes to the shader, is what I'm saying. So whatever the shader you distribute is, make sure it's easy to apply or remove GC as necessary. I have poser pro and I know bagginsbill has Poser pro. With the ability to have 6 gigs of ram available to rendering, I could never go back to poser 7.

Basic problem, not too many individuals completely understand the concept and problems of Gc in relation to proper monitor settings and calibration.  It is just a hobby and they are perfectly content with whatever results they obtain.  Sure it would be easy for the vendors to include such Material Room shader setup for their customers, if they understand the necessity at all.  And that where lies the problem, the knowledge is not wide-spread and re-enforced.  I use PoserPro and I can totally disregard the need to Gc (well...not totally disregard).  The application does it for me.  But, just the same, I shouldn't be ignorant to the fact that Gc does not exist.  Nowadays, I find myself critically examining each piece of content installed into my software and wonder how I can improve the texture to a higher degree.  There are alternatives, and being much aware of such, we should not be afraid to alter the authors creation to suit our needs.  BB has been beating his head against a very dense wall to bring the Gc point to the masses.  And there are many more jumping in on the cause, myself included.  But let's be realistic, many artist posting their creations in the gallery have never, and will probably not, set foot into the forum to learn an extra thing or two.  Which is. IMO, a crying shame.

I'm happy for you that you can afford Poser Pro, and that Bill can afford Poser Pro. I can't and the way things are looking, I won't be able to for the forseeable future.

BB has made a point of emphasizing that gamma-correcting is essential if you don't have Poser Pro. Since you and he are still a part of a minority, the majority of us need a solution that works.

You can use the materials as-is. We can't - well, we can, but we get crap renders. he has provided a solution for this.

I'm not sure what exactly your point is: that we *shouldn't use this solution? and distribute it amongst ourselves?

Te point is.. whatever shaders you intend to distrubute, make them such that your users can turn on GC or GC off through the shader assuming they do not have poser pro. In VSS's skin, it's easy to change the GC, so I'm asking that if you intend to distribut out shaders, make them just as easy to change the level of GC in the shader, since if your target is Poser 7 users, you'll have GC enabled in the shaders to make them look good.

Quote - Basic problem, not too many individuals completely understand the concept and problems of Gc in relation to proper monitor settings and calibration.  It is just a hobby and they are perfectly content with whatever results they obtain.  Sure it would be easy for the vendors to include such Material Room shader setup for their customers, if they understand the necessity at all.  And that where lies the problem, the knowledge is not wide-spread and re-enforced.  I use PoserPro and I can totally disregard the need to Gc (well...not totally disregard).  The application does it for me.  But, just the same, I shouldn't be ignorant to the fact that Gc does not exist.  Nowadays, I find myself critically examining each piece of content installed into my software and wonder how I can improve the texture to a higher degree.  There are alternatives, and being much aware of such, we should not be afraid to alter the authors creation to suit our needs.  BB has been beating his head against a very dense wall to bring the Gc point to the masses.  And there are many more jumping in on the cause, myself included.  But let's be realistic, many artist posting their creations in the gallery have never, and will probably not, set foot into the forum to learn an extra thing or two.  Which is. IMO, a crying shame.

And this is precisely why I feel it is important to form a discussion group to elucidate some of the more obscure aspects of gamma-correction. I've come to the conclusion that most people don't want to know - it's a bit like when Bill shows us with maths how materials can be made more valid... "Oh, but it's maths! My head hurts!" But maybe, just maybe, some of us DO want to know.

Quite frankly, hborre, the current discussion on the VSS thread is quite beyond me now... I've gotten into converting materials and doing renders and oo-ing and ahh-ing over the marvellous colours and everything and can't get my head around why no one else is even slightly interested in trying this. No, not you Poser Pro users, obviously. Why should you? it's built in. But there are THOUSANDS of us other poor schmoes who won't be able to plunk down hard cold cash on a hobby when the kids need feeding and school fees are coming due and priorities must be met... but we still want to get the best results we can.

It is to that group of people that I am appealing. And the question stands: who is gamma-correcting materials? How are you doing it? Let's share techniques and ideas.

Or was BagginsBill's exhortations to us Poser 5, 6 and 7 users all in vain?

Quote - Te point is.. whatever shaders you intend to distrubute, make them such that your users can turn on GC or GC off through the shader assuming they do not have poser pro. In VSS's skin, it's easy to change the GC, so I'm asking that if you intend to distribut out shaders, make them just as easy to change the level of GC in the shader, since if your target is Poser 7 users, you'll have GC enabled in the shaders to make them look good.

Yep.

Any suggestions how?

When buying items in the Marketplace, the seller usually specifies whether the item is Daz-friendly or Poser-specific or whatever. Or, they distribute a Daz Component ... point I'm making is: a vendor could make a Daz / Poser Pro version and a Poser 5, 6 and 7 version of her product.

Ya think that would work? Shaders don't weigh much...

It's easy enough to make it turn on or off - you simply put the Gamma value in a math node as in VSS. You pretty much have to anyway, since you cannot enter 2.2 in a color.

I've been wanting to publish (commercially) some shaders for a long time, but haven't had the time to do so. If I did, you'd find the pack full of all sorts of common classes of materials, in GC and non-GC versions. I wouldn't require the user to go into a material and edit the Gamma. It's easy enough to make two versions of every shader using matmatic, although the techniques require that you be more structured in your development of the shader.

At the top of my script, I create the Gamma node once and assign it globally.

gammaValue = Add(2.2).labelled("PM:Gamma")

I make one node for the inverse of that.

inverseGammaValue = 1 / gammaValue

I define a global flag for defining whether or not I want the GC version.

gammaEnabled = 1

I define a GC function that takes some node or color and checks the flag. If it's on, I do the GC, otherwise I just return the thing.

def GC(thing):
  if gammaEnabled:
    return thing ** inverseGammaValue
  else:
    return thing

I also define (very important) the anti-gamma function for incoming material.

def AGC(thing):
  if gammaEnabled:
    return thing ** gammaValue
  else:
    return thing

Then I write my shader as a function. Throughout the function I make sure to anti-gamma correct any incoming material (color maps, individual colors) and then gamma correct the final assembled output.

def ExampleTrivialShader():
  colorMap = ImageMap().labelled("Color Map")
  clr = AGC(clr)
  diffuse = Clay(clr, .85, .5)
  specular = Blinn(.3, .1, .15)
  result = diffuse + specular
  result = GC(result)
  return Surface(colorMap, 0, 1, 0, Alternate_Diffuse = result)

Then I call it twice

gammaEnabled = 1
outputs += ["GC", ExampleTrivialShader() ]
gammaEnabled = 0
outputs += ["NoGC", ExampleTrivialShader()]

If I was doing this on a large scale, I'd actually clone the material folder, and then remove all the GC versions from one, and all the NoGC versions from the other, and the user could just install one or the other or both as they see fit.
 

Hmmm. It occurs to me that while my technique is fine for shaders authored by me via matmatic, it's not particularly a good workflow if you're trying to take an existing shader build by someone else with a crapload of nodes and all you have is the material. In such cases, you're forced to reverse-engineer the shader and make an equivalent matmatic script. That's a pain in the butt.

So, suppose my first commerical product was a script that automatically does this to materials directly in the scene. (Would not work for Poser 5 - there is no node API in that version.)

Is that worth something? I know you talked about the point of doing this yourself is to avoid paying for Poser Pro. But would you pay something for such a script?

It does that for every material which does not have a node connected to alternate diffuse, all in a given actor.

That's pretty much what I was doing by hand in the last time. But if I'm to use a Stonemason set ever again, I need some kind of script to do that.

I planned to release this into Freestuff. I did not plan to ruin your start as a merchant BB, but since I would not pay much for such a script I did not plan to make people pay for it. 

I assume that a script done by you would have better results and most probably a nice GUI, which mine surely will not have, so maybe there is a market for that. But I assume that you would have enough to sell if you would find the time to actually prepare stuff for any marketplace. 

Yea there's plenty of other stuff to sell.

If I did a script, it would handle the more complicated cases, like V4's default shaders. What you did above is very sensible and will work for tons of "ordinary" materials - most of what is used looks like that. A script that does that is only a few days work, whereas what I was thinking of would take weeks to get right for all the scenarios.

Consider how many people use the color map, invert it, and run that into bump. Now should you GC that or not?

Or using reflection and/or refraction - now it gets tricky.

you still have to tweak every shader by hand to make it work in combination with skin,shoes,clothes,....

you need to tweak the colors. some textures were made because they had to use brighter lights. so when you use GC your colors are completely off. so you need to tweak. maybe even change the texture.