When FireFly (FF) shaders produce black in SuperFly (SF), it's usually because there was one particular aspect of Cycles nodes that SM could not see a way around.

The "wires" that carry data between nodes come in two fundamental types in FF - 3-tuple or number. (The most common 3-tuple is to represent an RGB value, but there are other 3-tuples for non-color data such as Normal (N node), Position (P node) etc.)

The "wires" in Cycles (aka SuperFly or SF) come in three flavors - 3-tuple, number, and "closure". The "closure" type of data is the output of a shader node - those that appear with names ending in Bsdf. Historically we called these "lighting" nodes in FF. Lighting or Closure nodes include Diffuse, Clay, Blinn, Anisotropic, Reflect, Refract, etc. In other words, when running SF, all the legacy FF lighting nodes are producing closure data, whereas under FF they produce 3-tuple or color data.

Because closure data is not actually just a 3-tuple (it's not a color it's a probability and a color and an alpha and some other stuff), Cycles refuses to let you deal with closure data as if it is a color. (I do not know why - I can only say it is what it is. If I had built Cycles, I would not have made such a limiting design choice.)

Therefore, it is illegal to process the output of a lighting node with color manipulators. If, for example, the output of a Scatter goes to Color_Math for post processing before reaching the Alternate_Diffuse input of the root node, Cycles will just ignore all that and give you blackness. You have to move color manipulations to the other side of any lighting nodes.

There are a couple exceptions. One is that a Blender node (not the program, but the FireFly node called Blender), when fed closures, is actually replaced with a MixClosure under SF. I have tested this many times. I'm less sure about other exceptions, but I recall Stefan mentioned maybe that Color_Math:Add with both chips set to white will become an AddClosure automatically, and so that special case is supported. There may also be an exception for HSV under limited circumstances, such as Saturation = 1, Value = 1, Hue = 1, and color chip is white.

It is generally a simple matter to rearrange the order so that color manipulation is done BEFORE lighting (i.e. before becoming a closure). If the shader satisfies that criterion then generally speaking it works fine both in FF and SF.

However, there are other reasons you may not get what you want. For example, most of my FF shaders add together a Blinn and a Reflect. I do this because FF has always (and still does) only used the Blinn with lights and only used the Reflect with objects. To get reflections of both lights and object you have always had to use both nodes. Well - in SF, Blinn reacts to lights and objects. Reflect also reacts to lights and objects. Therefore the sum of these gives you duplicate reflections resulting in the extraordinary unrealistic appearance of silicon on everything. So the irony is that when you do the "best" PBR in FF, that same shader becomes decidedly unrealistic under SF.

In such cases, it's better to build a hybrid shader.

If, like so many naive Poser users, you NEVER bothered with even attempting realism, and you don't have the reflect node, just the Blinn, or worse, just the basic built-in Specular on the PoserSurface root node, then that renders pretty nice in SF because you were always missing those reflections of objects and now they are there.

I tried to come up with a suggestion that SF should detect certain PBR idioms in existing FireFly shaders and deal with them. For example, I suggested that the FF Reflect node should not function under SF, since the Blinn or Specular handles reflections just fine. They thought such "magic" would be too confusing. They thought that might make some people confused.

Personally, I think what they chose to do is CERTAIN to make some people confused, whereas the magic version would have just worked.

Whatever - it is still possible to make changes in an SR. I did not convince them that my high-quality PBR shaders that look as realistic as possible need to work in SF - they figure if you went to the trouble to load a BB shader, you'll go to the trouble to load a new BB hybrid shader that works in FF and SF, or maybe you'll just abandon FF and the point is moot.

---

Renderosity forum reply notifications are wonky. If I read a follow-up in a thread, but I don't myself reply, then notifications no longer happen AT ALL on that thread. So if I seem to be ignoring a question, that's why. (Updated September 23, 2019)