Cycles render settings cleanup


since 2.8 is a time for bigger UI changes, I would suggest to improve the most prominent deficiencies when it comes to Cycles render settings. They are quite confusing or overcomplicated at some places, but recent introduction of single column layout, which breaks the ability to suggest functionality of various render settings by their proximity to others made these deficiencies that much more apparent.

So, here we go:

Clamp Direct should be removed:
I have yet to see a single use case or or scene where clamping direct lighting results in any significant performance boost/noise reduction without completely ruining direct light transport accuracy. While clamping indirect lighting makes a lot of sense, clamping direct doesn’t. That’s why no other renderer out there implements such option.

Performance benefits of choosing Sobol over CMJ are pretty much random and inconsistent. A good default should be chosen and this option should be hidden. The technicalities behind this option are so complex that no user who is not a renderer programmer at the same time would be able to make an educated guess on which one to use anyway.

Reflective and Refractive caustics:
There is not a single use case where it makes sense to disable either reflective or refractive caustics completely, when we have indirect light clamping already. These two toggles mean that refractive materials will cast completely opaque shadows and that metallic materials will bounce no light at all. Both of these effects severely compromise light transport accuracy while posing nearly no performance benefit over using indirect clamping with some low value (like 1-2)

Square samples:
It was implemented with a good intention, but it just creates another unnecessary layer of complexity for both new and existing users to deal with. Especially if they decide to exchange their render settings and some of they may use it while others don’t. These days, Cycles is optimized well enough that it’s rare to ever see users inputting such a large numbers of samples in UI sliders that it makes sense to have a specific feature to alleviate it.

Overall, the reason to remove these is that the benefits or flexibility these options bring are so small they do not outweigh the drawback of making Cycles harder to use by polluting render properties panel with settings which significantly increase room for user’s error.
What I mean by that is that chances any of these settings will be used in a wrong way, which is harmful to resulting image quality is significantly larger than chances someone will utilize these settings in a good way.

Naming improvements:

Light Paths category → Ray Depths:
Chances are that both new users and existing users with some rendering experience will be able to associate term “rays” with tracing depth rather than “light paths”. While Cycles technically is a path tracer, if I was a new user, just learning about computer graphics, the term “path” would certainly be more confusing to me. Generally, if you ask people around how would they expect a panel of settings to control ray tracing depth to be named, not many of them would say “light paths”.

Transparency → Opacity:
Transparency is quite ambiguous term. While in some renderers it means refraction, in others, like Cycles, it means opacity. Opacity is a term which would remove any ambiguity out of the terminology. You will often hear artists talk about opacity maps, but rarely transpancy maps. And if you hear transparency maps, they are most likely talking about refraction amount map, or something like that.

Glossy → Reflection:
Term “Glossy” kind of implies this sampling value is only used for reflective surfaces either above or below certain roughness, depending on if the user is used to glossiness or roughness workflow. This is again ambiguous. Naming it reflection would send a clear message that the ray depth affects all reflections.

Transmission → Refraction.
Transmission is a term rarely used in any rendering engines made for consumers, not scientists. And those few rare times it’s actually mentioned in some consumer renderer, it’s usually in conjunction with Diffuse Transmission, rather than refraction. Vast majority of new users or users coming from other renderers will be looking for refraction ray depth and wondering why in the world they can’t find it.

Geometry (roll-out) → Hair and Volume
You have no idea how many times I was looking for volume step size and forgot where it was, when I finally found it in the roll-out which as little descriptive of its contents as possible. :slight_smile: This again comes down to programmers often using quite different association of the terminology than users, but the fact is this UI is supposed to be used mainly by users, so some compromises should be made.

Film → Framebuffer:
Film roll-out mostly contains frame buffer settings, while the term “Film” will most likely evoke things like camera response curve in most of the users.

I’d suggest to merge Film roll-out with Post Processing roll-out. They both contain same category of settings, and it appears division of the settings they contain into these two categories is rather arbitrary, than based on some deep logic. This will save us one roll-out.

All in all, I am quite confident that with these changes, Cycles would become a bit easier for users to pick up.


I don’t particularly care for this setting, but many renderers do have a clamp setting that affects both direct and indirect light, and this is basically the equivalent functionality of that.

In general it can be helpful to have some high overall clamping for that one shader or light that gives extreme values or fireflies, to avoid problems in compositing.

The plan is to make CMJ a debug-only option.

I don’t think that’s true, in some scenes they do decrease noise significantly compared to even indirect clamping with a low value. The proper solution to make these obsolete is may be to make higher Filter Glossy values work more aggressively.

Rendering without these caustic paths but with diffuse indirect light was the standard for production rendering for quite a while. Which isn’t to say I would suggest users to do it, but it is workable method to optimize render times.

Personally I’d be happy to remove it, but when I tried I got a lot of negative feedback about it. Here among other places:

The panel contains more than just ray depths though. I understand it would be more standard but with features like Light Path Expressions coming in more renderers this isn’t that uncommon a term?

If we change the naming it’s going to be a painful change for the Blender code, UI, documentation, and existing users. While it would be more standard, I’m not that interested spending time to go through that process.

“Alpha maps” are a pretty standard name in CG that is also used throughout Blender, and I plan to add an Alpha socket to the Principled BSDF. For integrator / film type settings I don’t think it’s really that non-standard to use the term “transparency”, mostly in shaders the term “opacity” is used as far as I know.

We inherited the name Glossy from OSL, which got it from Arnold. If we rename this it would be to Specular, since Reflection is quite ambiguous as a term for this. In my opinion Reflection as a name for any type of specular reflection is a legacy term from when direct specular and indirect reflection were treated as separate things by renderers.

It’s a term used in at least Arnold and PRMan, so it’s not that uncommon. I prefer to reserve the term refraction for what it actually means, and in my opinion using it to describe transmission effects more generally is again a legacy thing.

Note that this panel also contains adaptive subdivision settings. Maybe we can find a better term than “Geometry”?

Framebuffer also sounds quite technical though, and I’m hesitant to introduce that term into Blender just for this purpose.

The Film settings are baked into the render, the post processing settings can be changed without re-rendering. I think that is a clear distinction we have to make.


I mostly agree with Brecht about nomenclatures, I see them as correct with the function they perform and they are used equally throughout the industry. But it is true that Film is not right because it seems that blender has a strange pipeline.

I myself have by default removed reflections and refractions almost always. I only activate them when necessary, which is rarely the case.

1 Like

Hey, thank you for taking your time for such elaborate response! :slight_smile: Definitely some good points.

I am quite confident that most of those renderers clamp only indirect light, or in other words, they do not apply ray clamping for explicitly sampled (MIS) light sources. I may be wrong, but so far, I did not come across a single scenario where ray clamping would have any visible effects on scenes direct lighting only and exclusively diffuse surfaces with GI turned off.

Well there are some corner cases, where it may help. The most common example is probably a light bulb (spherical area light or MIS sampled emissive sphere) inside a lamp shade with metallic material. Strong, small light source close to highly reflective material is firefly factory. The problem with this setting is that it’s global. Proper solution to handle such cases is usually a ray switch on material level, for example swapping metallic material for very dark gray or even black diffuse material specifically for GI rays only. However, if you kill all reflective caustics globally, just to remove those fireflies, you will also lose very important light bounces in other parts of the scene, where they contribute to final image quality in a meaningful way.

Also, the only renderer which I can think of, that standardized rendering without caustic paths but with diffuse indirect light was Arnold. Arnold is not a good example to take for quite a few reasons :slight_smile: These days, times have changed, so I think it’s more common to see settings like these deprecated, or even gone. They were deprecated by the time ray value clamping became standard.

That’s a textbook example of this :slight_smile:

I think in this case, it would be good to make a strong decision.

I am not so sure here LPEs are a good idea in the first place. There were a few renderers which implemented them, but they generally ended up a bit underused, because they are a bit too complicated for an average user to tackle. That being said, Arnold implemented LPEs as part of their AOVs, and even kept the name Light Path Expressions, yet their ray depth setup is still called Ray Depth, in both 3ds Max and Maya :slight_smile:

If it’s way too difficult change here, then it definitely doesn’t pay off. It’s a minor thing. Would be nice to have but not that crucial. So I agree the benefit here would not pay off considering the trouble.

Heh, as a user, I still associate term “Specular” with those old fake specular highlights. But yes, Specular would definitely work better than Glossy :slight_smile:

But then I am kind of confused if transmission affects only refractive materials, or for example translucent materials as well, since translucency is a type of transmission. I mean, what else, aside from refraction parameters of Cycles’ shaders is driven by transmission depth? Opacity is driven by Transparency, and it likely has no effect on both SSS, which has separate setting, or diffuse transmission, which uses diffuse setting. Correct me if I am wrong but transmission depth is only manifested by what’s basically a refraction in Cycles’s
set of shaders.

Yes, I missed that indeed. Honestly, I think that subdivision rate is better suited for performance roll-out. That’d basically make my proposed “Hair and Volume” work, or wouldn’t it?

Fair point :slight_smile:

Funny, I did not know that up until now :slight_smile: That being said, I would expect something to be called “Film” to be also somewhat dynamic, and not baked into the render, but that’s already stretching it, and playing with words. I still think it could have a better name, but I indeed struggle to find a better one myself.

It goes back further than that, when renderers like PRMan introduced GI or when Mental Ray was initially used with GI for movie production it was without those caustics. And today most realtime engines still ignore them. Clamping really is not a full replacement for this in my opinion.

It also affects the Translucent BSDF (diffuse transmission).

Nearly all the Geometry panel settings are performance / quality trade-offs. But adding them all to the Performance panel would be too much. Maybe separate Volumes and Surfaces panels are ok, even if the Volumes panel only contains two settings.

Yes, I guess this would be a reasonable compromise.

Also thanks for explanations on the other points. No disagreements there either except the ignoring of caustics option. Both V-Ray and Corona these days enable both Reflective and Refractive caustics by default, and rely on ray clamping to do the work. Only difference being that both of them do transparent shadows instead of true refractive caustics for refractive (glass) materials, so refractive caustics are opt-in per material effect. In general, transparent shadows masked by fresnel effect tend to end up closer to the ground truth than heavily clamped refractive caustics.

Speaking of panels: I think the support of subpanels is a great move, but they can add a little extra UI complexity when scanning the properties. Could a few pixels of indentation for the subpanels title be an idea?

Yes, it’s planned to improve the header drawing of the subpanels.

Nearly all the Geometry panel settings are performance / quality trade-offs. But adding them all to the Performance panel would be too much. Maybe separate Volumes and Surfaces panels are ok, even if the Volumes panel only contains two settings.

It always seemed strange to me that Volume Sampling was outside of the Sampling panel, since the setting (like clamping and seed) relates directly to how samples are taken and processed. May I suggest subpanels for “Surface Sampling” and “Volume Sampling”?

The Film settings are baked into the render, the post processing settings can be changed without re-rendering. I think that is a clear distinction we have to make.

This distinction has never been clear to me until you just explained it :slight_smile: . Perhaps “Render Processing” might be a good renaming of the “Film” panel? As in, processing applied to the Render itself and not after the render - in contrast to “Post Processing”, which is processing applied non-destructively after the render is done.

Just a thought out of curiosity, why not consolidate things like DoF/Motion Blur/Denoising/Freestyle into subpanels of such a “Render Processing” section? After all, from a user perspective, all of these are essentially advanced post processing effects that happen to need to be baked into the render itself.

And again, it might not be clear to a new user that they can’t just ex. remove motion blur after rendering.

1 Like

This is how I designed the settings:

  • Sampling: controls the amount of noise in the render.
  • Light Paths: controls lighting quality.
  • Geometry: controls surface and volume detail and quality.
  • Performance: controls render performance without affecting the look or noise.
  • Freestyle, motion blur, film: rendering effects that affect the look.
  • Post processing: additional post processing not done by Cycles.

Note the volume step size and max steps is the equivalent of the dicing rate and max subdivisions for surfaces. So I’d rather keep those separate from the Sampling panel.

Perhaps a “Camera” panel makes sense, with film and motion blur. It would make more sense if DoF was global but it’s per camera. “Render Processing” is quite ambiguous in my opinion. Freestyle is a bit odd since it’s mostly per render layer, so perhaps it could just an on/off setting under “Post Processing” with the Line Thickness moved to the render layer settings.

1 Like

It’s getting a bit tricky, because for example Glossy filter and refl/refr caustics toggles do IMHO significantly affect noise amounts in renders.

I actually think it’d make great sense to move these 3 into sampling rollout, then rename Sampling to Sampling Quality and Light Paths to Ray Depth.

Camera panel to merge film and motion blur sounds like a really good idea. I support that.

Lastly, it looks like in performance panel, there are a few settings ripe to be exposed in debug mode only:

  • Tile sizes should be probably automatic, since they are handled much better now.
  • Progressive Refine doesn’t work well for a while now, it heavily under-utilizes both CPU and GPU. (It works fine in viewport rendering mode, but it seems to use a different approach in final render mode).

On an unrelated note - I would really like to see an option to be able to force simple Path Tracing for viewport preview renderer even when using Branched Path Tracing (BPT). BPT handles some scenarios bit better than simple Path Tracing, but viewport feedback interactivity usually suffers a lot from BPT. If this new toggle was enabled, then whenever user switches to BPT, viewport preview is still rendered with regular PT, and “Preview” value in the AA samples section of BPT panel will be used to define max amount of regular PT passes for viewport preview.

Then Geometry would be better named Detail? Sounds more generic than the former, which btw suggests something more about the shape of objects.

The toggle you propose I’d like it more to keep BPT but setting every raytype to 1. This is almost fast as PT yet it gives better/faster results when using many lights or with interior scenes

Detail is way too ambiguous for rendering context.

As for the other toggle. First of all, it’d be probably more complicated than it needs to be, and second of all,
I would say that priority of the viewport preview is feedback speed. Furthermore, by setting every raytype to 1, you will pretty much turn BPT into regular PT :slight_smile:

Nope, it’s not like that: PT takes 1 sample randomly choosing the raytype encountered along the ray path, BPT takes 1 sample for each raytype encountered along the ray path, so they are more samples anyway, given that more than one shader (glossy diffuse etc) type are present in the scene, which is 99,9% of common jobs.
That said, an addon (amaranth I think) lets me quickly set %'s of the raytypes sample amount, but it actually changes the values, and I have to remember to set them back to 100% for final renders, which is no optimal solution imo. There’s no render/viewport distinction. This is another case of an option that would fit good in the simplify panel, but this is another story…

It is strange to me that denoising isn’t in the the sampling panel with the other render settings related to noise. I realize that denoising is a post effect and it makes sense in that aspect, but to not even have it in the render panel doesn’t make sense for discoverability and workflow. I think it should be changed.

But it’s a per render layer setting, so how would that fit in render settings tab, which has global settings?

With Blender 2.8 being so much about decluttering the UI, I’d vote in favor of removing Square Samples. The discussion that @brecht linked even has the author of that post (and many other) later saying that Square Samples should stay in 2.79 but be reconsidered in 2.8.

A simple check for the version can convert older files by multiplying the value.


I agree with Pablo.

Square samples should be removed, I think it missleads new users (at least it did it with me) and tends to make users think that they need 10000 samples to get a clean render, wich is not true if you know how to configure Cycles.

On the other hand no one mentioned Branched Path Tracing.

I see two possible problems with this related somewhat to square samples.

The first problem is the lack of clear documentation, no matter how much I scratch my head, I can´t wrap my head around on how to properly configure it to leverage less noise and more speed. When you enable it you really don´t know where to start, I´m not sure how can this be improved because I´m not exactly sure how does it work, but when you enable it for the first time the nearest thing in my mind was the square samples setting.

The second problem is the lack of actual consistency with the meaning of “sampling” in branched patchtracing and in the normal pathtracing, and this makes the user go crazy, because if you configure the same number of samples for everything you don´t get the same result in both engines, I know that this is mainly because you can get the same number with different multipliers, but this is what makes the user crazy and it connects directly with the first problem.

I post this here because I think this is a matter of interface more than functionality and maybe adjusting some calculations in the numbers shown in the UI this could be solved.

Also the first problem could be solved with a proper tutorial about it, something that tackles it deeply and not just the brief description in the manual, because while it´s literal, it´s not explanatory.

These are my impressions and I may be wrong of course but I would like to know your thoughs about it because I think BPT is being misssused or underused to optimize scenes.


1 Like


it appears there still hasn’t been any significant progress in improving usability of Cycles’ render settings UI in 2.8, but there have been some regressions. Namely:

1, It appears that the rollout vertical arrangement is quite random:
It should instead be sorted and prioritized by usage, something like this:

2, Since there are now not only rollouts, but also sub rollouts, it amplifies the issue of poor category naming and poor categorization, making certain settings even harder to find, such as:

Clamp Direct and Clamp Indirect settings are present in the sampling rollout. These settings do not modify amount or distribution of samples. They modify light path accurracy, and therefore belong in the Light Paths category. Specifically, they should be put in Caustic sub-rollout of Light Paths, like this:

Volume stepping and hair settings are still present in the rollout labeled as “Geometry”, which implies containment of settings like raytracing acceleration structure, definitely not volumes. This should be renamed to something more appropriate.

3, Device selection should go back from being buried in the performance rollout to the header space, under feature set and render engine selection. Arguably, it’s way more important setting than feature set selection. Missing this setting due to being hidden may give newbies hard time, not realizing they are not utilizing their hardware to its full potential, as well as seasoned users, who may forget to switch the setting because it’s hidden out of sight.

1 Like

re-naming the submenu would be good then. something like “bias”?