Convert cycles closure (shader) output to colors?

Question

Is it possible to convert the output of a cycles Shader node to colors?

For example to use an ambient occlusion shader output to multiply or darken act as a mix factor between other shaders?

Answer 1

No.

Long answer: Closures (the green sockets) are symbolic descriptions of lighting behavior on a surface. They only result in a color value after evaluation of all the possible incoming light directions by the renderer.

Now, when you talk about using the result of an Ambient Occlusion shader for mixing other shaders, this describes a physical or chemical effect which is not part of the basic pathtracer model with inert materials, i.e. the light influences the physical properties of the material (which in turn could change lighting and so on ...).

A good illustrating example is phosphorescence - if you wanted to implement this with cycles you have to bake a map of the "charge" and use that for an emission shader, while also reducing the charge over time as well as increasing it with incoming light. The important point is that this whole physical simulation is outside of the actual pathtracer and only communicates with cycles via image textures (much like dynamic paint).

The key missing feature is baking of course. It will eventually be added to cycles, but for the time being you'll have to resort to using Blender Internal or some external renderer (or just make an image map by hand).

Answer 2

The simple yet unsatisfying answer is: No. It's not possible.

(Verified by a Blender developer, I had the same question a while back)

Followup explanation:

It would be possible to implement such a feature if cycles would render a second pass, meaning that it would render a complete image with the base shader and then re-render everything on the basis of the result of the first pass. Both passes would have to be noise-free, so this would effectively double the render time for each such connection that you use. And that doesn't take into account that a ray may bounce back and forth several times between two objects, and in theory, you would have to compute a new image for every single bounce then, as the result of every bounce is influenced by the previous one and needs a full pre-computed first pass of it.

Doing this for the full depth of possible bounces is impossible. Doing it only for the first bounce is against the concept of Cycles as an engine that renders continuously instead of in steps or with pre-computing anything. After all, Cycles also has to work in realtime, and that would be impossible to implement because there, you can't wait for two noise-free passes to compute for a usable result.