there’s quite a threat that Cycles could become a hell jungle of buttons in future. I am already starting to spot some bad decisions that could eventually lead in significant degradation of usability.
Namely, there are currently 4!!! knobs to control ray clamping. Clamp direct, clamp indirect, reflective caustics, and refractive caustics.
These settings are interdependent, so for example if you disable reflective and refractive caustics, then clamping won’t do much good, or if you set both clamp values too low, then disabling either of caustics won’t do any good either.
All of the modern renderers adapted Max. ray intensity trend originally started by Corona. There is simple mechanism that clamps any rays that differ from average of other collected rays in given pixel by a value larger than the entered value.
This preserves most of the soft caustics, drastically reduces noise, does no ruin HDR information of image, and is only single value. While i understand there is significant effort of making Cycles production renderer, having as many controls as possible is really not a way to go.
Also, aside from Path Tracer and Branched path tracer, there could be also some sort of simplified branched path tracer, which would have just single value to define amount of secondary rays per eye ray. It would have most of the performance benefits of branched one, with extremely simplified user input.
I know chances of the feedback getting from here to the developers are slim, but i have no idea what is the official way to send it.
To start with, I’d suggest that you try to flesh-out these observations into an action(able) plan. In other words, not simply, “it’s broke,” but: “here is how I suggest that we ‘fix it.’” In detail. Use this forum to develop consensus and momentum for your ideas. (Which ideas will inevitably break down to multiple development initiatives, with different relative priorities.) The clearer your ideas are, and the clearer it is that these ideas can be implemented, the faster its lift-off will be.
The :eek: total :eek: make-over of the Blender 2.49 user-interface was initiated in just this way, and it completely rejuvinated Blender as a product. It does, indeed, seem to me that Cycles has reached a logical point where we should step-back from its frenetic “feature-adding” development push and consider how to improve the overall user-experience. It won’t be easy, but software never is.
That is really interesting, Sundials, what you said about the Blender 2.49 > 2.5 make-over. Are there any resources to read about how that change occurred (and was initiated, according to you)? You really seem to be right about Blender being rejuvenated after that. When I come across obsolete tutorials from the 2.49 era, I really do cringe and remember why it took me so long to come around. But now, it’s increasingly difficult to look at Blender as different from other packages in any significant capacity…
Anyway, I know its off-topic…didn’t mean to hijack…just really curious…
Nice idea, but very hard to implement. While I am keep trying to make experimental bidir render usable i feel same, every extra control, even if it sometime make sense, must be replaced by good automatically driven defaults. With my experiments i end with 3x more controls then in Cycles, and every time i promise myself to remove some, i failed.
Going to just drop everything except “max bounce”, “MCMC/MLT”, and maybe some big green “safe button” that reset all to default.
I don’t know if you’re going to get good quality replies here, this thread is a year old and Rawalanche does not appear to come to this forum anymore (neither does Storm_st after trying to convince users that Cycles should become a strictly physical renderer rather than one focused on flexible shading techniques that even allows a degree of NPR)
