I get pretty good results for sweaty-looking skin with a Glossy node attached to Alternate Specular in the P7 Material Room with Firefly ray-tracing. Thanks, bagginsbill.

However, I have found that I have to include and tweak a Bump for the skin texture, so that the specular reflections have rough, irregular edges. Without the Bump, the specular reflections are rounded, contiguous areas with smooth edges, and this makes the skin look like smooth plastic.

The trouble is that if I increase the Bump value enough to make specular reflection rough-edged, to about 0.01, the skin looks like it has the texture of orange peel.

I've also played with the Roughness and Sharpness values in the Glossy node, but the results seem dependent on the Bump map. I've also tried attaching a Blender node with Glossy and Noise, but the reflections are still smooth-edged. So, finally, my question: Is there a way to mix a bump or noise channel into the Glossy node so that a Bump map isn't needed?

Thanks,
Rick

Whatever node is producing your bump - whether it's a texture map or some sort of prodecure - usually has an amplitude that is added (or multiplied?) to the main node's bump value, so maybe balancing those two values can give you something closer to what you're looking for. You could also increase the relative scale of your texture, or apply your bump to the main node's bump but use noise or something in the alternate specular.

There are ways to get the specular to show variation without using a bump map. I don't want to discourage you to learn interesting techniques, but I don't think you want to go there for this particular shader application. You really will get the best results with a bump map, since the bumps in human skin are the real-life reason we see this. If the real-life reason was that there was natural small-scale variation in the specularity then we'd want to pursue other models that vary the amount of specularity.

But the correct model here is a fine bump. So the orange-rind problem is not because of bump, per se, but rather because you used a bump pattern with size and shape like an orange rind.

Here is a demonstration of a suitable wet-human-skin bump using a turbulence node. Notice the bump depth is .005 inches - very low - not at all like an orange rind. Notice also the Turbulence scale - .05. With a bump this small, you can't even see it unless the skin is wet!

Something to watch out for is that the value for Bump (and some other values besides) relies on your selected measurement unit - so if your measurement unit is set to Meters e.g., you will get QUITE different results for a value of .005 in Bump (roughly a quarter inch, vs. 1/200th of an inch).

Ah thanky pjz - I always try to remember that tip but this time I forgot. It's very important that we agree on units. As pjz says, I'm using inches - be sure you translate if you're using something else - or better, be like me and use inches :) 

A nice thing (at least in Poser 7, and I'm fairly sure it works the same in previous versions) is that if you change your setting in preferences, it will automatically convert the numbers in the Material setup - so if you prefer to work in Meters, you can simply set your default measurement to Inches temporarily and make whatever number setting required, and then change it back (you don't even have to leave Materials Room to do it).  I am pretty sure that saved files store the number value in a basic unit type that is independent of your measurement unit, meaning all your old content should render the same if you ever do change your preferred measurement unit.

Thanks bagginsbill. The Turbulence node works well as an easily adjustable Bump, and gives the Glossy specular reflection the ragged edges I was looking for. I really appreciate your help.

Also, thanks pjz99. I changed my Units to Inches and entered the values bagginsbill showed, and then watched as I changed Units back and forth among Feet, Centimeters, etc. Funny, the Bump Value changed accordingly, but the values in the Glossy and Turbulence nodes were unaffected by changing Units. So you're right, we have to be careful when we're sharing Material Room settings, since Units affects some values there.

Rick

RJ:

Each numeric parameter on a node (or the PoserSurface) is based on some underlying unit. These are not documented well (if at all) so it took me quite a bit of experimentation to discover what they are.

This is a pretty important topic that I've never written about. It's worth understanding.

First we need to talk about the three coordinate systems we can work with in shaders and their corresponding direction (such as surface normals) and distance calculations.

• Model space - 3D - The xyz (I'm using lower case intentionally here) coordinates of each point of the object's geometry. This is with respect to the raw, original coordinates stored in a geometry file, such as an OBJ file. Transformations (translate, rotate, scale) do not affect these coordinates. Nor do morphs. Nor do displacements applied in the material room. Any given point is assigned a fixed xyz coordinate and it never changes. If you load two identical props, and do a bunch of transformations, morphs, or displacements to one of them, the xyz values of the corresponding points on the two props are still identical.
• World space - 3D - The XYZ (upper case intentional here) coordinates of each point after applying transformations, morphs, and displacements. Again, considering two copies of the same prop, the XYZ coordinates of the points on these props will be different if you move, rotate, scale, morph, or displace one of the props.
• UV space - 2D - This coordinate system is arbitrary, and may not even be assigned. Assigning these coordinates to a geometry is called "UV Mapping" and is usually used to map pixels of an image (such as a skin texture) onto the surface of an object. UV space coordinates never change, no matter what you do to the object.

In shaders, we can directly access some of these coordinates and related measures.

UV space- Variables/u (aka u_Texture_Coordinate) - the U value

• Variable/v (aka v_Texture_Coordinate) - the V value
• Variables/Du - the rate of change of the U coordinate, with respect to the rendered image. In other words, how much "U" is included in a given pixel. Something far away will have a higher Du than something close. Something angled away from the camera will have a higher Du than something pointing right at the camera.
• Variables/Dv - the rate of change of the V coordinate. Same rules apply as for Du.

**World space
**- Variables/P - the XYZ coordinates of the point being shaded.

• Variables/N - the "normal" or direction the surface faces in the world.

Combinations- dPdu and dPdv - the rate of change of the XYZ with respect to U or V. (As implemented by Poser for polygonal meshes, not particularly useful. It isn't continuous and smooth like you'd want it to be.)

• dNdu and dNdv - the rate of change of N with respect to U or V. (Again, not particularly useful in Poser for polygonal meshes, as it is not continuous and smooth.)

It would be great if we had a few more. For example, I'd love to have the exact direction vector to the camera and to specific lights. We can get at some of this information indirectly, through trickery. For example, the Edge_Blend node gives us an indication of the alignment between N and the direction to the camera. And the Specular node gives some indication of whether N points at a light or not. These are not completely or exactly what you want or need at times, but they are very useful nonetheless. For example, if you look at the shader I posted above, you'll see I used a Specular node to drive a Blender. The Blender is choosing two different tinted versions of the skin texture. When the skin points directly at a light, it uses the blue tint. When pointed away from a light, it uses the red tint. This is my favorite hack for giving human skin an appearance that approximates subsurface scattering.

So what is the point of all this knowledge? Well, first of all, it will help you to know what you're saying on certain parameters. For example, the Bump or Displacement amount is actually a World space distance, and is expressed in units matching your current choice for Display Units. I always use Inches, as I find it convenient to think in those terms. Another World space distance is found on Reflect and Refract - the RayBias. I won't get into why Poser needs this silly parameter as it is a painful subject to me and I get quite cranky about it. Suffice to say that if you change your Display Units, you'll see this number change! (at least in Poser 7 it does). Through experimentation, I am fairly certain that such World space distances are always written into the shader file in inches, regardless of how you entered them. This is important information for any software that writes shaders directly into files, such as my matmatic program.

Did you notice that none of the "Variable" nodes give us Model space xyz values? This is very unfortunate, as I've needed this information at times. But it would be wrong to think they're not used. They are used all over the place!!!

All of the nodes listed in "3D Textures" use xyz coordinates. When you set "x scale", for example, you are defining a divider to be used with the "x" coordinate. A bigger "x scale" causes the 3d texture to spread out in the x direction, by making the rate of change of x be lower. Similarly, "y scale" and "z scale" are also dividers for the corresponding Model space coordinates. By altering these scales, you alter the evolution of the 3d texture pattern in Model space.

Now it would be logical and consistent if Model space scale parameters were expressed using your preferred Display Unit, in the same way that RayBias or Displacement or Bump changes to meet your desire for mental math convenience. Well, they don't! Poser never shows these values in anything but their natural underlying Poser Native Units (PNU). That is why, RJ, you observed that the Turbulence node parameters were unaffected by changing Display Units.

You also observed that the Glossy parameters didn't change. But Glossy doesn't have any parameters relating to coordinates directly. It has Roughness and Sharpness, of course, but those have to do with angles and not coordinates or distances. If we had a preference setting for how angles are entered and displayed, for example radians versus degrees, then they would have to change, but we don't.

Now there are some nodes that have an interesting checkbox, called "Global_coordinates". For example, Cellular and Spots have this checkbox. Can you guess what these do? Stop reading and take a guess...

Yep - they change the node so that instead of using Model space xyz coordinates to drive the pattern, they use World space XYZ coordinates. Of what use is this? Consider what happens when you scale an object, such as the ground plane. The xyz coordinates spread out, right? So that means if you use a pattern on the ground, and you scale it up, you also scale up the pattern. This is generally not desirable for the ground. Suppose you're using a node to simulate waves on water, applied to bump or displacement. If you need more water, you want the prop to be bigger, but the waves should stay the same size. So you'd want to use World space coordinates, so the pattern's scale, with respect to the world, stays the same, even if the ground covers more of the world.

But my favorite nodes, Fractal_Sum and Turbulence, do not have this checkbox. What to do!!?!?

Well I discovered another bit of magic, an undocumented behavior that at first was very peculiar and difficult to comprehend, but I now use it a lot. If you plug any kind of node into "x scale", "y scale", or "z scale", those parameters STOP USING Model space x,y, or z values. Instead, they use the node you plugged in!!!

So, for example, I can plug a P node into any of those and use World space X, Y, or Z as I see fit. You have to either use one P node and three Comp nodes (to extract each coordinate) or use three P nodes, each set up to only pull out one coordinate. For example, P(x=1, y=0, z=0) will extract only the x coordinate. Unfortunately, due to how vector to scalar math works in the nodes, this gets divided by 3. So you should use P(x=3, y=0, z=0) instead, which cancels the divide by three.

You can also force one of the 3D texture nodes to be 2D instead! Yes you can. Plug U into "x scale", V into "y scale" and you have UV instead of xy. However, the z is still tracking Model space. To stop it, plug a Math:Add node in with a value of 0. This makes the z value a constant - thus the pattern ignores the Model space z coordinate.

With still more trickery, it is possible to design a set of nodes that causes the 3D Texture nodes to produce repeating tiles. This is a very esoteric thing, and is only needed if you're using Poser to generate seamless tiles that can be used as image-mapped textures for other purposes. Within Poser itself, it is generally better to take advantage of the infinite-non-repeating nature of the 3D textures.

I hope you've found this interesting. If something is unclear or you can't quite imagine how to produce a specific effect using this information, come back and ask. I'll post example renders and shader setups.

Thank you, bagginsbill. You've made me use parts of my brain that haven't been exercised since my calculus classes! Still, your explanations are so clear and thorough that I was able to follow your lines of thought, and now I have a better understanding of how the Material Room works.

I wondered about the purpose of the two-color Specular Blender on the Diffuse node. Now that it simulates subsurface scattering, I will have to give it a try.

Also, I was just thinking about doing an ocean scene, so I found your discussion about World space coordinates for water textures particularly interesting.

Finally, what is your Matmatic program, and where can I find it? It sounds most interesting.

RJ

Terrific explanation bagginsbill.  Yes, I have long been searching for the holy grayle of how to get Poser to use world mapped coordinates for textures.  In Vue, this is quite easy as materials support manny different type of mapping modes including World Coordinates.  Could you post a small example of how you would for example set up a node configuration to map a simple texture to tile or project using World Coordinates?  I've tried to use the various image projection modes in Poser but with no success.  Thanks.

Quote -
Finally, what is your Matmatic program, and where can I find it? It sounds most interesting.

The Poser material room is really nice for learning and experimenting. But connecting 50 or more nodes for more complex effects is a serious pain in the butt. At some point, I wanted to just write mathematical formulas. I also wanted to be able to use object-oriented programming techniques so I could make reusable shader components at a higher level than Poser gives us. I wanted to generate big piles of nodes in a loop. For example, the Poser "Brick" node sucks. It is not useful for serious work. Compare what you usually see with this the bricks at this link: Matmatic Bricks

That brick shader is 77 nodes! To build it by hand is excruciating. To make coherent changes is impossible. That's not even a big one. I have a cloth shader with over 440 nodes in it.

Thus was born Matmatic. It is a Poser Python plugin used to describe materials in specialized Python scripts, called Matmatic scripts. I have posted hundreds of these scripts.

I originally put it out as a "Beta" test. But that version was so close to perfect, I never put another one out. After Poser 7 came out, I had to issue a new one that was compiled for the newer version of Python that is in Poser 7, versus 5 and 6.

Here is a thread that sort of turned into an intro to matmatic.

Here is the original announcement

Here is the thread with the Poser 7 version that needs to be copied over the original. Get the version in post #6.

Acadia has put together a fantastic list of material room links. There are many links to matmatic scripts in there, too. Go here:

Material Room, Nodes & Shaders - Tutorials and Discussions (Bookmarks - Updated)

In addition to the matmatic stuff, she has linked many other very useful threads in there. Read it all if you want to really learn this stuff.

I also invite you to hang out at my forum - The Node Cult at RDNA. Over a period of time, I developed a "cult" of people who were annoyed at how difficult it was to find my posts among all the other Poser threads. So RDNA gave me my own forum - where we ONLY discuss shaders and nobody is allowed to complain that "this makes my head hurt"  LOL  Well they do anyway, but they still learn something.

Quote - Terrific explanation bagginsbill.  Yes, I have long been searching for the holy grayle of how to get Poser to use world mapped coordinates for textures.  In Vue, this is quite easy as materials support manny different type of mapping modes including World Coordinates.  Could you post a small example of how you would for example set up a node configuration to map a simple texture to tile or project using World Coordinates?  I've tried to use the various image projection modes in Poser but with no success.  Thanks.

Are you talking about the Image_Map node? You want to tile a texture image in world coordinates? If so, I know what you're talking about. The mapping modes, such as XY, don't work right. And checking Global_Coordinates doesn't work right either.

Is this what you want to do? I have a bunch of props. I am projecting a tiled image of a cat on all of them, using a shader that ignores UV and uses global XY instead.

Quote - Is this what you want to do? I have a bunch of props. I am projecting a tiled image of a cat on all of them, using a shader that ignores UV and uses global XY instead.

Indeed, that is exactly what I'd like to do

OK sorry this is complicated. The Image_Map node is really screwed up. This was the only way I've found to do it.

The trick is that you have to add the U coordinate to the U_Offset, and then subtract what you really want to use for the driver. In this case, it is X = P(1,0,0). Similarly, you have to add the V coordinate and subtract what you want which is Y = P(0, 1, 0).

In order to make it easy to scale, I added one more node at the lower right, the drives the scale of the two P nodes.

To produce this shader in Matmatic I would say:

scale = .01
uo = U - P(scale, 0, 0) # the U offset
vo = V - P(0, scale, 0) # the V offset
img = ImageMap(":Runtime:blah blah blah:cat.jpg", U_Offset = uo, V_Offset = vo)
Surface(img)

> Quote - OK sorry this is complicated. The Image_Map node is really screwed up. This was the only way I've found to do it. > > The trick is that you have to add the U coordinate to the U_Offset, and then subtract what you really want to use for the driver. In this case, it is X = P(1,0,0). Similarly, you have to add the V coordinate and subtract what you want which is Y = P(0, 1, 0). > > In order to make it easy to scale, I added one more node at the lower right, the drives the scale of the two P nodes. > > To produce this shader in Matmatic I would say: > > scale = .01 > uo = U - P(scale, 0, 0) # the U offset > vo = V - P(0, scale, 0) # the V offset > img = ImageMap(":Runtime:blah blah blah:cat.jpg", U_Offset = uo, V_Offset = vo) > Surface(img)

Well I tried to replicate this but I'm getting an image that is tiling in Quads (see the pic).  I applied the shader to just the Torso and shoulder materials here.  You can see that indeed it is tiling but it is scaling the tiles to fourths just as it is in your example.

Well the edges of the tiles have to be somewhere :biggrin:

If you want to shift the image horizontally or vertically, you'll have to add an additional constant offset to U_Offset and V_Offset. Try adding .5 to both to shift it half an image. You'll need more nodes.

In matmatic I'd say:

uo = U - P(scale, 0, 0) + .5
vo = V - P(0, scale, 0) + .5

Quote - Well the edges of the tiles have to be somewhere :biggrin:

If you want to shift the image horizontally or vertically, you'll have to add an additional constant offset to U_Offset and V_Offset. Try adding .5 to both to shift it half an image. You'll need more nodes.

In matmatic I'd say:

uo = U - P(scale, 0, 0) + .5
vo = V - P(0, scale, 0) + .5

Yes,  I did something similar by converting the P nodes to absolute values.  I guess I was looking for something closer to the way that Vue does this which pins the entire map to the infinite extents of the scene so you would not see any seams when set to a scale of 1.  Anyways, thanks again for the help.