I noticed that animating any color property in any material node chain causes the preview rendered to not display that material color correctly.

To see it, create two spheres side-by-side. In their materials, do the following:

-------------------------
* On one sphere, add a diffuse color that's a combination of all colors (not just all red, etc..), like R=240 G=70 B=40

* On the second sphere, create a "Simple Color" node and add the same color to that node, then connect it to diffuse color.
--------------------------

At this point, the two spheres look exactly the same.. Now:

------------------------
* On the second sphere, ANIMATE the simple color (click key next to clolor selection swatch), DISCONNECT the node from the diffuse color root, then reconnect it.
-------------------------

Now, the second sphere looks very different, even though, strictly speaking, nothing has changed. I notice that this happens in all instances of animated color swatches in any type of node, on all figures and objects...

Does anyone know how to fix this? It *does* render okay in the actual Firefly/Superfly renderer, but it's annoying to have the Preview renderer mess this up.

You will also see this color shift if you animate the Diffuse Color on the PoserSurface node alone.

Open a support ticket. Hopefully, the techs will have an explanation for the behavior.  It might be an unreported bug.

The other thing is that Preview is limited to FireFly only.  If you have ANY SuperFly nodes in the material room that will effect the Preview engine.  If you only have FireFly nodes you should have no problem.  

I must respectfully disagree. This issue occurs even with the PoserSurface node present. The sole workaround seems to be establishing your node connections prior to animating the channel. Additionally, I've noticed this change when switching back and forth to the Material Room.  I have a feeling that something got broken.

I received a response from a submitted ticket, very quickly, actually, kinda impressed, heh. I just took a few days to play around with it.

I *THINK* the below is correct. I didn't 100% understand the answer, but:
   It turns out the "Gamma Correction" setting under the "Firefly" render options will actually change the behavior of the Preview window. If Gamma Correction is "on", the preview renderer appears to use the SueprFly renderer to produce the preview. If the Gamma setting is "off", then the "firefly" renderer is used to produce the preview.

The way that the two renderers produce their "preview" is different.

I tried experimenting more, in general, with node settings and values to see the differences between teh two renderers, but I lost the plot a bit... too many unexpected variables and things I clearly don't understand. Like, the same material chain with the same settings/property values will priduce completely different color resuits in Firefly vs. Superfly,  but this depends on "unexpected" things, like whether the property is animated or not, deviation from default value (rather than just the straight value), etc...

In general, the major difference for the preview is that Gamma setting.

That's good to know although I think that is an odd behavior.  It is worth keeping an eye on it.

So, the above post I made is *not* correct. The Gamma setting does NOT change the renderer... I misunderstood the response from my ticket.

I think what's happening, now, is that animating a color property causes the scene-wide Gamma setting to apply to that color, **in the Preview render only** not in the Firefly / Superfly render.

The cockamamie solution I came up with is to add series of nodes to apply an inverse gamma ( For instamce, 0.4545 for the default 2.2 document gamma) to an animated color, then multiply that with texture node output. The gamma value in the gamma node is animated, so that the gamma can be set to 1.0 before rendering the scene... So basically, the preview renderer now displays the correct colors with aniamted color properties, and the "corrective gamma" is set to "unity" before rendering the scene (since the actual Firefly / Superfly renderer never had the problem with animated colors, no correction is needed, so that "corrective" inverse gamma actually causes it's own problem if not set to unity).