11
$\begingroup$

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.

$\endgroup$
4
  • $\begingroup$ It's the same if you bake the color texture in Cycles and use the image as a texture input of the next shader. Probably this would be too slow for the engine. $\endgroup$
    – FFeller
    May 27, 2021 at 18:44
  • $\begingroup$ @FFeller sure. I've done that more than a few times, myself. :) What I'm after, here, is the specific difference which makes it impossible to implement Shader to RGB for a path-tracer working the way Cycles does, but possible for EEVEE. $\endgroup$ May 27, 2021 at 18:47
  • 2
    $\begingroup$ Can't link to a reputable source right now, but I have a foggy idea of reading somewhere Brecht or some other developer saying it was not so much that it was technically infeasible, more a matter of principles that it would go against the philosophy of how Cycles works. Implementing it, would require some "ugly hacks" that would make the code more complex and fragile $\endgroup$ May 27, 2021 at 23:13
  • 1
    $\begingroup$ I think it ultimately comes down to circular reference: Shader to RGB on a table would have to wait for the rays hitting this point (not pixel; so another question is what would be the epsillon determining what is the same point) to finish their path to a light source to actually determine the color. On their way to the light source, the rays could hit other objects, e.g. a chair. But the chair's color may also use Shader to RGB... This could drastically change object's color depending on the order a ray hits multiple objects, giving unintuitive results, so problems pile up. 🤔 $\endgroup$ May 28, 2021 at 8:03

3 Answers 3

8
$\begingroup$

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.

$\endgroup$
2
  • 1
    $\begingroup$ 'I still feel..' etc. If I understand that right, YesBut. NPR often wants to manipulate the light-response of a surface, halfway down a tree. But wrangling fully-fledged PBR into generating toons always seems odd, to me. (Roll on, BEER.) I was previously under the impression that Cycles was closures, and EEVEE, somehow, wasn't. But no. The difference is that rasterisation doesn't require the convergence of a color evaluation from all over the ray-space. Cheers! $\endgroup$ May 28, 2021 at 9:19
  • $\begingroup$ @RobinBetts Honestly, sometimes I think the only reason that Eevee uses closures at all is for the sake of compatibilty with other rendering engines. (Not that that isn't wise.) They definitely aren't as helpful to a raster-based renderer. I'll usually hammer out an idea in Eevee first, and then switch to Cycles before I make it production-ready. $\endgroup$ May 28, 2021 at 22:59
8
$\begingroup$

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.

$\endgroup$
1
  • $\begingroup$ This answer .. Light-Bulb moment for me .. an awful lot of NPR could be achieved in compositing, which isn't covered a lot, out there. And a lot of the explanation can be deduced by comparing the list of passes made available by EEVEE with those made available by Cycles. $\endgroup$ May 28, 2021 at 9:04
6
$\begingroup$

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.

$\endgroup$
2
  • 1
    $\begingroup$ Love the image; it sticks .. sorry I couldn't tick everybody's answers :) $\endgroup$ May 28, 2021 at 9:21
  • $\begingroup$ @RobinBetts S’alright. I was figuring it out myself at the moment 🙂. $\endgroup$
    – TheLabCat
    May 29, 2021 at 3:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.