Why is 'Shader to RGB' possible in EEVEE, but not in Cycles?

Question

As a result of @Michael Macha 's comments on, and helpful edit of, this answer, it turns out my understanding of the differences between EEVEE and Cycles is a lot fuzzier than I thought it was. I get that BSDFs are closures? I understand closures to be functions carrying some of the external state that pertained at the time of their creation, waiting to be called with 'live' parameters?

But if BSDFs are closures in EEVEE, too, why is 'Shader to RGB' possible in EEVEE, but not in Cycles? Some indication of how data is shovelled around, and when, would be very helpful.

Answer 1

I seem to have been beaten to my explanation here, but I feel like I can expand a little. Cycles is designed to be an OSL-capable Monte Carlo renderer; it takes as long as it has to to output layers of specified quality, and takes everything in the scene (usually) into account to do this. This means that determining an RGB value for a particular closure requires an entire rendering of all items to be sure about—and it would mean that it would need to be that for every single ray.

In theory, you actually could do this, but no one would—this would be the gross number of individual rays contacting the material in question, multiplied by the time to render the rest of the scene anyway (and if it's glossy or translucent and might self-reflect, for all I know the sun would explode before that render finished). This is why for OSL-like closures, data can go in, but it can't come out until the material program has already been run. It's just impractical, and the quality bonus would be dwarfed by the amount of time taken.

However, Eevee isn't a true ray tracer. It's rasterization based. This is why it can render so incredibly quickly, actually; and final RGB color doesn't entirely rely on knowledge of the environment around the element. For this reason, given that Eevee renders images about a dozen times faster than Cycles, and that detailed environmental knowledge isn't usually necessary for Eevee to determine an RGB value, the notion of running a closure and outputting an RGB vector has been opened up. It's now, at least relatively, trivial; if you don't mind breaking compatibility with Cycles or (I think) Octane later.

I still feel that it's almost always more efficient to reference what you need of the color before you stuff it into the BSDF closure, but hey, everybody's on some kind of a deadline and sometimes the simplicity is worth it. It still effectively requires a rendering, it's just happening within your shader now instead of exclusively after it.

Answer 2

It's technically possible, but not that practical.

You turn Shader to RGB through rendering. Because in Eevee one object doesn't depend on the whole scene and because it does rasterization it's way faster, which makes it practical.

In cycles you want to render your scene into render layers, that way you get the Shader to RGB data, and then you can do postprocessing on it, which is the same like using that RGB output from shader in Eevee. Or you can bake the material (render into texture) if you don't need anything dynamic.

Answer 3

EEVEE is a rasterizing engine, which means it uses math formulas to approximate everything. Cycles, on the other hand, is a ray tracing engine. Because EEVEE is totally not based on rays, the color data for a material is entirely accessible within that material. In Cycles, however, any object can possibly be affected by any other object’s light behavior, and so one object turning operating instructions into set output values would be like a train car suddenly turning into a concrete cast of a train car: not very pretty or workable.