Corona 1.4 render setup UI overhaul

[Nekrobul]

As long as those controls remains accessible through string options...

You so spoiled aprils fools best prank ever.

[Frood]

As long as those controls remains accessible through string options...

Awesome Romullus :) I can live with that, nice layout! Maybe the button should be labeled "Make nice Picture".

Good Luck!

[alexyork]

Haha that is great Romullus..

For what it's worth, Ondra, you have my backing for this approach 100%. Simplicity is Corona's main selling point. We would always rather spend more time on rendering and less time on fiddling with settings. Time is money. Machine money is less than user money. If we need to spend an hour optimising a render so it renders 1 hour less, it's a total waste of effort.

But we would probably suggest keeping these settings hidden away somewhere in the UI so at least those who do need them can get at them. Seems no point in removing them altogether.

For me, Corona can (and perhaps should) grow in complexity when it comes to features, such as elements, overrides, VFB tools and all that good stuff. That stuff increases productivity. Personally if I never have to look at another sample setting or AA/GI balance again I'd be a happy man. But give me lots of toys to make my images realistic and beautiful.

Cheers,

[Ludvik Koutny]

I am too for simple, but removing Max. ray depth would not make any sense. There are still way too many scenarios where it makes sense to adjust that value.

[denisgo22]

maybe I'm wrong, but i think that all as regards denoising filter /radius and None-Full-Fireflyes/ must be moved to VFB in addition to Color Correction options, same in VFB+ filters, since it is mainly a post process effect, for quick access and feedback during the test renders, because the process takes some time after the main render stops, and make it interactive on/off checkbox, to see the result immediately in VFB, in short as well as implemented in VBF+///

[Ondra]

when we hide max ray depth, we will also decouple different scenarios - reflective, refractive, and volumetric max bounces will be different, and with exception for volumetric bounces they will be set to optimal values and hidden.

As for the checkboxes vs. dropdowns: there is also one additional issue - maxscript access - if there is one dropdown "denoising", then everything is fine, one just sets renderers.current.denoising = full. But if there is a checkbox, one has to set renderers.current.denoising = full AND renderers.current.denoisingOn = true to have it correctly configured. That can be a source of bugs and problems.

[Ludvik Koutny]

maybe I'm wrong, but i think that all as regards denoising filter /radius and None-Full-Fireflyes/ must be moved to VFB in addition to Color Correction options, same in VFB+ filters, since it is mainly a post process effect, for quick access and feedback during the test renders, because the process takes some time after the main render stops, and make it interactive on/off checkbox, to see the result immediately in VFB, in short as well as implemented in VBF+///

Some parts of denoising settings will likely be in VFB, but many things still need to be accessible from render settings as well for animation/renderfarm rendering.

[racoonart]

As for the checkboxes vs. dropdowns: there is also one additional issue - maxscript access - if there is one dropdown "denoising", then everything is fine, one just sets renderers.current.denoising = full. But if there is a checkbox, one has to set renderers.current.denoising = full AND renderers.current.denoisingOn = true to have it correctly configured. That can be a source of bugs and problems.

Amen! :D

[Juraj]

That's why he wrote in in addition :- )

It definitely needs to be in render setup, if for anything, animation, gui-less render,vfb+,etc..
But since it doesn't require re-rendering, it should at same time, be switchable on/off in framebuffer.

[Christa Noel]

Here's another voice against removal of this parameter, I already had 2 jobs where I needed to increase it. I'm pretty sure it'll prove useful regularly, not often, but every now and then for sure.

Hi pokoy, may i know what kind of scene that need higher value than 25? Never thought there is a case that makes the scene needs more number of light bouncing

[romullus]

Here's another voice against removal of this parameter, I already had 2 jobs where I needed to increase it. I'm pretty sure it'll prove useful regularly, not often, but every now and then for sure.

Hi pokoy, may i know what kind of scene that need higher value than 25? Never thought there is a case that makes the scene needs more number of light bouncing

A scene with a lot of refractive objects, perhaps? https://forum.corona-renderer.com/index.php/topic,10005.0.html

[pokoy]

Here's another voice against removal of this parameter, I already had 2 jobs where I needed to increase it. I'm pretty sure it'll prove useful regularly, not often, but every now and then for sure.

Hi pokoy, may i know what kind of scene that need higher value than 25? Never thought there is a case that makes the scene needs more number of light bouncing

Sure. I tried to simulate heat haze with particle flow objects faced to camera, the object would have a map for glossy refractions. In some cases I needed to increase the value.

I guess people link reflections/refractions to rendering glass or reflective surfaces, in this case the 25 bounces limit is reasonable. There may be other cases though where people 'abuse' the renderer for something completely different.

[Nekrobul]

To be more obvious why we need MRD.

[burnin]

^Sure thing. Thank you!
From experience had noticed that simple users don't see the reason to why or the benefits (cuz it takes longer to render), then when need occurs, they just call it a bug.

[vertigo1]

+1 for simplicity.

Perhaps rather than "Advanced" settings, there could be "Override" settings. A place only for the brave to muster the courage to enter in those circumstances when they have something to render that falls in the 5% not handled well enough by simplicity and automation.