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.
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
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.
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.
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.
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.
Could be, but caustics is representative enough. Caustics are generally meant as a hard to sample, outlier light paths of high contrast to their surroundings, and all the settings in the caustics rollout are pretty much affecting exactly those.
The thing is that there are quite a few more Cycles settings that introduce bias, such as ray bounces, but those would still end up outside of the “Bias” rollout, which could then imply only those contained within the “Bias” rollout introduce bias, and that would not be true.
Somewhat related, the location of the OSL checkbox is in the wrong spot, it should be near the feature set selection, not hidden in the performance section. Sure OSL is not as fast as SVM but that doesn’t make it a performance option.
I would like to move the Color Management and Freestyle panels, the only reason they are there is due to a code limitation of Blender native vs. Cycles panels ordering. We have this in a few other places too, I plan to fix that still.