I have a problem (I assume) with my Firefly render settings. I have a reasonably complicated shader node setup for a V4 character including animated shader node settings intended to allow me to dial up skin complexion colours and a blush colour and intensity (not to mention variable transparencies). All of these seem to appear correctly in the OpenGL preview (though admittedly, I often have to force Poser to reload textures to get the preview to behave). But when I render using the maximum, final render settings in PoserPro2010, the render shows the unaltered base texture without the previewed diffuse colour variations or the applied blush masks.

Has anyone seen similar behaviour?

I have been blaming inadequate swap space on my dual-core MacBookPro and inadequate memory, but my new, top-of-the-line iMac with quad-core i7, 16G RAM and oodleplexes of empty disk space is producing the same untanned, unblushing renders. Lightning fast, but lacking character hinted at by the previews.

Post some screengrabs of the problem nodes, and the render settings.
It might get you on the way?
A picture tells a 1000 words.

Cute face BTW.

Note animated shader parms on diffuse color; swatch shows actual complexion colour.

Three blenders for diffuse, specular and bump are masking out the eyebrows using a V-Coordinate shift of duplicate image maps from higher up the forehead; masked by the eyebrow mask with contrast increased by a power math node.

Why do the alternates even exist if they just replace the primaries???

Shader node variable settings in attached image

Render settings surrounded by render with disconnected alternate diffuse in attached image

Try setting your Diffuse to 0.8 or lower if you want a texture plugged into the alternate diffuse to show up more.

A fair comment Teyon, but in this case it's not the alternate diffuse effect that's missing in the render, but seemingly anything plugged into the main diffuse color that has animated parameters, i.e. the diffuse color itself and the blush mask strength and colour (variable changes show up in the OpenGL preview perfectly but fail to render in FireFly). This seems like a bug in how firefly interprets animated variable inputs, or, at least, a problem with how the shader nodes are fed into the firefly render engine.

I'm really loathe to bake the textures or de-animate the variable parts, because the whole point of the exercise was to have a blush response on demand in an animation, which can't easily happen with baked textures.

so it probly still doesn't render blush animation with nothing plugged into alt spec and "refl lite mult" unchecked.  a render of the full-length animation will show no blush in any frame.  there's a mask blush and blush mask node (maybe inverts).  is there a way to simplify the blush node group and delete everything else (blinn, spec et al.) temporarily to debug the blush node group?

Not very many individuals push the render settings to final, too time consuming for rendering purposes.  You should make your changes under manual for better control.  Although you are not designating gamma correction in your render settings, I would double check all transparency and bump maps for the correct gamma setting of 1 in the texture manager.  Again, you are not using Gc in final render, so it may not change anything.

@Miss Nancy: I had previously tried just adding the variable hsv coloured blush mask to the texture, but the result was too dependent on the original skin texture colours, so I resorted to masking out the blush region with the mask before adding back in the hsv coloured blush.

@hborre: I agree, I was just attempting to push the limits of new, top-of-the-line hardware ;-). With 2Gb of VRAM and 16Gb RAM on a quad-core i7, I'm getting lightning fast renders and barely troubling the iStatMenu graphs for memory usage during renders. It all smacks of a firefly s/w bottleneck or excessive optimisation.

The dials you show - there is only one set of them, instead of one per material. How? Are you using dependent parameters?

o.k., I see only the hsv node is keyed above.  my vote would be to delete that and instead key the mask to fade in/out to black. in response to the following post, if varying tex strength doesn't work, then maybe multiply it by range of 0 to 1 over period of anim.

@bagginsbill: Yes, indeed. Lots of hand-text-editing of the material .mc6 files to consolidate the animated shader nodes for every skin material on V4!

Ah, the hazy depths of one's thought processes when trying to overcome a seemingly simple problem.

Background: to achieve a reasonable appearing animated blush response, and not just look like an instant case of acute rosacea, both the saturation and value (intensity) of the coloured blush mask have to be animated. A solid, fully saturated colour is also not believable as an autonomic blush. Clown makeup, yes. Blush response, no. Experiment produced 25% saturation at 75% value (intensity) as a reasonable looking blush with a photoshop created mask with full white at the blush centres, gaussian blurred to black outside the blush area.

Recent past: then along comes a wonderfully subtle blush mask from a commercial texture set (Juniper). Unfortunately, the subtlety isn't quite overcome by maximising the Blush animation variable. What to do? Ah, I'll just change the texture_strength on the blush mask from 1 to 2! shouldn't be a problem, right? After all, examination of the mask's histogram shows nothing brighter than a 50% gray, so doubling that shouldn't exceed any bounds, should it?

Present: WRONG, CRETIN! OpenGL may have not problems sorting sanity from madness, but Firefly is assembled from ethereal glows of whimsy and cannibalised luciferase. Texture_Strength 2 is nicht und verboten. I must resort to more complex methods of intensifying a subtle mask such as raising it to a fractional power. One half seems like a good start for making the lights lighter and the blacks blacker.

As I proceeded to re-apply the animation and ERC shader complexity that was necessary to achieve the smoothly animated blush onset with a single dial tweak, I ran once more into the problem that fails to appear when you're just twiddling sliders in the material room; the blush just wasn't intense enough with the subtle mask, given the ERC was designed for a mask with full intensity gamut. The "simple" solution of bumping the texture_strength over 1 immediately blows firefly to the weeds and, admittedly, also plays havoc with the texture previews in the material room.

Strength is peculiar. When set to zero your image becomes all white. Any fraction is blending the image with white. Any value over 1 is exaggerating the difference from white. So - basically everything that is below max value goes lower.

If you're starting with all values below 1, increasing strength makes them all go lower, with some of them going negative. This is not your desire.

To keep 0 at 0 and increase all values, you multiply the map with a number greater than 1. Hard to do when you are only allowed to enter colors up to 255, right?

Your image is not color so use math nodes. Connect a math node to your mask image. In that math node, enter any number you want, such as 2.

Then 0 stays 0 because 0 times 2 is still 0. Where the mask is .5, you'll actually aget .5 * 2 which is 1.

In fact, if you know the min and max value of your input mask, a single math node can normalize it to the range 0 to 1. Here is how.

Suppose your mask is faulty and its luminance values go from A to B, and these are not 0 to 1, but some other numbers.

Connect this to a Math:Subtract node in Value_1.

Value_1 should be 1 / (B - A) and Value_2 should be A.

This node will then change the mask range from [A, B]  to [0, 1].

For example, suppose the mask luminance goes from .2 to .6.

You use Value_1 = 1 / (.6 - .2) = 1 / .4 = 2.5. And Value_2 would be .2.

Having re-RTFM it appears that the hsv node is not at all what I wanted it to be for. Instead, the User_defined node is where it's at. With the same animated parameter dependencies used by the hsv node, user_defined set to HSV mode both displays the blush in OpenGL hardware preview and renders in Firefly. Woo hoo.

However, I'm still drawing a blank with rendering the animated value of the Diffuse_Color swatch on the PoserSurface node in the full complexity shader scene.

Your little tidbits leave me with more questions and concerns.

Are you building a product intended for multiple versions of Poser? The numbers in the UserDefined node prior to Poser 7 SR3 were bugged. Poser erroneously used the square root of the values you put in there. Most people cannot make a shader that behaves the same in all Poser versions using the UD node. I can, but I know all the math and can navigate the material room blindfolded.

Also, what exactly were you trying to do with the HSV node? I can use it to produce any color in HSV mode quite easily. Set the color chip to YELLOW. This is numerically hue number 1. Then the hue scale parameter works correctly because it is scaled by 1. Saturation and value work as expected. Its the hue that is tricky.

The hues are:

Red=0

Yellow=1

Green = 2

Cyan = 3

Blue = 4

Magenta = 5

Hue is modulo 6, so when you get to 6 you're back to red.