Corona 1.4 render setup UI overhaul

[Ludvik Koutny]

Here's concept for improved UI open for feedback:

Denoiser mode moved into scene settings:

Reasoning:
Denoising is not something that affects true performance of rendering, it's more of a postprocess effect. Also, Performance settings are described as something only experienced users should touch, that's definitely not the case of turning denoiser on/off.

Denoiser radius moved from debug into scene settings next to the denoiser toggle:

Reasoning:
When we are denoising images that are very close to the final, with very little residual noise, we may benefit from using lower denoiser radius, so we can clean up very subtle noise with nearly no detail loss. Also, when trying to denoise very noisy images, it may be beneficial to increase denoiser radius to get clean and less splotchy result, at the expense of some detail.

Pros:
More control over how denoiser works

Cons:
One more UI element bloating UI
May confuse new users who may set it up wrong and then whine on support portal denoiser causes too much detail loss or produces blotches.

Added % sign after Noise limit spinner

Reasoning:
To indicate value is set in percent

Adaptivity toggle will remain in devel/debug settings

Reasoning:
Adaptivity will be always on by default, and we should focus to make it more proof for all of the scenarios. So if you have any scene where adaptivity makes results worse, then definitely post it on mantis. Of course, adaptivity by design will often cause more noise on some areas of the image at the expense of cleaning up others. That's not a bug behavior. But if you find any scene where adaptivity makes picture truly worse, then definitely report it. It will stay exposed in deve/debug though, if someone ran across some rare scene, where it makes issues in the middle of production.

We may introduce "Adaptivity recalculation interval" setting

Reasoning:
This value defines how often is image evaluated and adaptivity sampling focus adjusted accordingly. In early testing build, default was 2, now, in latest build, default is 10. While 2 was way too low, 10 is probably way too much. If we expose this setting, would you guys be willing to intensively test it and help us find the best default among different scene types?

[romullus]

Here's concept for improved UI open for feedback:

I like it, but please, add checkboxes for denoiser and render selected instead of those none and disabled dummy modes. Have pity on users.

We may introduce "Adaptivity recalculation interval" setting

Reasoning:
This value defines how often is image evaluated and adaptivity sampling focus adjusted accordingly. In early testing build, default was 2, now, in latest build, default is 10. While 2 was way too low, 10 is probably way too much. If we expose this setting, would you guys be willing to intensively test it and help us find the best default among different scene types?

For sure. But why not to leave it exposed permanently in devel/experimental rollout? I'm sure power users would love to have one more control to play with ;]

[Christa Noel]

For sure. But why not to leave it exposed permanently in devel/experimental rollout? I'm sure power users would love to have one more control to play with ;]

yes big agree, I like that idea. +1!

[lacilaci]

For sure. But why not to leave it exposed permanently in devel/experimental rollout? I'm sure power users would love to have one more control to play with ;]

yes big agree, I like that idea. +1!

Well if changing the setting can make a notable difference in performance, then yes... otherwise you can still experiment with it using string options right? "int adaptivity.adaptivityInterval = #"

By the way, interval is in passes right?

[Ludvik Koutny]

In this particular case, checkboxes here do not make any sense honestly. It's a simple rule:

you would have 3 UI controls instead of 2, but they won't give you any additional flexibility (you won't be able to do anything new you could not do before) and they won't make process faster or easier to use. It will add visual UI clutter without any reward what so ever.

[romullus]

Sorry Rawa, but i completely disagree with you, it WOULD make process faster and easier to use (click vs click-move-click) and it almost won't add any visual clutter as no controls have to be moved or crunched - there is plenty of space to add those checkboxes. Every (i mean EVERY) single time i use render selected feature, i wish that there would be that damn checkbox. As much as i like elegant and simple UI idea, i can't stand when usability has to be sacrificed for it.

Sorry for a rant, i just need to vent my frustration. If it's firmly decided that those checkboxes has no place in Corona's vision of UI, i won't bother you again about it.

Well if changing the setting can make a notable difference in performance, then yes... otherwise you can still experiment with it using string options right? "int adaptivity.adaptivityInterval = #"

Thanks for info!

[Ludvik Koutny]

The thing is that there are more than one options. So while denoiser would be activated with a single click, firefly removal would then have to be click-click-move-click instead of click-move-click. And render selected has more modes as well, so as long as user does not want to use what's set there by default, it's actually one more click for him.

While i agree that every click or move should be shaved off if possible for tasks that are done often, enabling denoiser or render selected is probably not a task that is being done 10+ times a minute, so it's really not worth adding UI clutter.

Lastly, UI always needs to have clear and consistent guidelines. You can't use few different UI philosophies scattered across single piece of software, or you end up with something like 3ds Max itself. So if we followed a logic that any dropdown that has none option should have checkbox activator, then primary and secondary GI would have checkboxes to, so would image filter and VFB type. Now we would have 6 new UI elements that do not add any real speed or flexibility benefit.

[Frood]

i can't stand when usability has to be sacrificed for it.

I think it´s only a different definition of "usability". I remember the UI switch from Alpha to v1.0: suddenly I needed twice the time to find the (few) settings, some of the Corona magic got somehow lost. And what about new users? One of the most appealing features of Corona was/is it´s simplicity. This is a bigger deal than one might think as someone who has been using Corona for a long time now.

Solution may be having a "Standard" and a "Advanced" GUI. Similar to checking "Development/Experimental Stuff" but with impact on all rollouts/settings. This way you (and me, because I also miss it) may get your checkbox in "Advanced" mode ;) or the adaptivityInterval (please do;) while new users have the simplified UI. Regarding that checkbox it does of course not make sense to change the basic handling but you get the idea.

I remember there has been a (way to) short note/discussion about standard/advanced UI somewhere in the forum.

Good Luck

[Ludvik Koutny]

Well, actually if majority of people would be for to have checkboxes to activate dropdowns that have currently "none" or "disabled" option, it would be reasonable to do it, but it would have to be done everywhere, so UI is consistent across all corona windows and panels. This is not nVidia forum where you get banned for feedback, here, everything is always open for discussion. In the end, it's the userbase who use the renderer on daily basis :)

[Juraj]

Standard/Advanced version of GUI is rabit hole. It creates the effect that even the most clueless beginners feel like they're missing out on "better controls".

Just look at the amount of people still asking for "best settings" on forum :- ). Advanced division would simply amplify this effect, Advanced would become de-facto the new default anyway.

[maru]

Just a quick mockup, so names of the categories should probably be changed. What do you think? My goal was better distribution of the UI elements and reduction of the height of the rollouts.
-start interactive and show vfb switched places - who uses "show vfb" more often than start ir?
-limits arranged in some more eye-pleasing manner (hopefully)
-"render elements" and "reset settings" moved to "render" (worktitle) category
-overrides merged to the "render" category

[Ludvik Koutny]

Not sure about reset settings being in render category. It doesn't render anything. I think it belongs into system tab to be honest :)

[maru]

"Reset settings" applies to render settings. It's just an idea, though. System tab would be a good place too. ;)

[lacilaci]

why not just make a radio button switch for denoiser off, firefly only, full.... like with exposure (simple vs photographic) forget checkboxes and dropdowns... unless there are more options planned but still..

[Ludvik Koutny]

why not just make a radio button switch for denoiser off, firefly only, full.... like with exposure (simple vs photographic) forget checkboxes and dropdowns... unless there are more options planned but still..

Because radios take a lot of space, and visually clutter the most. You don't need to see all the options at one given point in time.

[lacilaci]

why not just make a radio button switch for denoiser off, firefly only, full.... like with exposure (simple vs photographic) forget checkboxes and dropdowns... unless there are more options planned but still..

Because radios take a lot of space, and visually clutter the most. You don't need to see all the options at one given point in time.

Really? You would place it all inline from left to right and a value parameter box at the end... single line all options exposed easy to memorize the position of buttons no need to read or open a menu... A menu dropdown you always have to read to know what is the current setup...

[Frood]

In the end, it's the userbase who use the renderer on daily basis :)

I´m sure almost every daily basis user would like to have even more controls than advanced UIs could ever deliver :) The downside is that you lose that new users "where are all the controls"-face when looking at corona for the first time (and I´ve enjoyed a few of them :). Even if it´s only for a day before activating the "i want it all" checkbox.

This first impression is/was so important because it generates a (founded) feeling that it´s simply just f* working! (something everyone using products from the you-know-who-company misses from time to time).

It creates the effect that even the most clueless beginners feel like they're missing out on "better controls".

Yes but this is ok when one has got the first impression and has been working/testing for a while with the simple UI, isn´t it? As for the "best settings": Until now the very elegant anwer was: "the default settings" which is true for most situations. And if it´s another case, that user isn´t any more a beginner :) I don´t want to defend standard/advanced UI at all costs, i just feel it could serve in two directions.

It´s goal conflict: Simple interface: more new users (and thus $), voracious power users, extended interface: satisfied userbase, possibly confused new users. I only presume that of course. A poll would be interesting if the current userbase would benefit a simple UI to gain more/quicker control (but I think I can take a guess).


Good Luck and thanks for reading


P.S.: Could we have generally a dedicated thread/sections for UI discussions/mockups? This Daily builds thread is just a mess...

[Juraj]

I´m sure almost every daily basis user

voracious power users

Where did you extrapolate this info from ? The original idea behind Corona was simplicity, so why would all those "power-users" want something else from it ?

More clutter was never an answer in this thread and yet suddenly it starts to pop-up again.

[Frood]

Where did you extrapolate this info from ?

Feature request and forum post in general, but this is presumably as I wrote.  And "voracious power users" was a ironic term - just in case. You want something else (actually "more", not else) because sooner or later you reach the the limits/drawbacks of simplicity (adding elements or exposing parameters to UI does not necessarily mean to complicate or "clutter" things anyway).

Good Luck

[lacilaci]

Where did you extrapolate this info from ?

adding elements or exposing parameters to UI does not necessarily mean to complicate or "clutter" things anyway.

Good Luck

Really? You don't think this would suddenly lead to "expert" tips for best settings and a lot of confusion and user errors?

I'd prefer if renderer would be present only in a form of single "render" button... Now of course there are situations a "renderer" cannot determine so there are some controls in place.. and they should be not simple as in simplified, but easy to use with as little possibility to create confusion and user error as it is possible.

[Juraj]

Where did you extrapolate this info from ?

Feature request and forum post in general, but this is presumably as I wrote.  And "voracious power users" was a ironic term - just in case. You want something else (actually "more", not else) because sooner or later you reach the the limits/drawbacks of simplicity (adding elements or exposing parameters to UI does not necessarily mean to complicate or "clutter" things anyway).

Good Luck

Request often come from victims of Stockholm syndrome.

Vray recently kept removing and removing. Their only one year old feature (Minimal Shading Rate), which made scattered samples into single parameter, is already worthless as well, because they implemented fully automatical sampling. 2-step simplification happened here, while the software grew in robustness.
It's about 95perc. perfect, so nothing absolute. But does those 5perc. case warrant fiddling ? For small minority of user, yes, perhaps. But it mostly warrants another automatization improvement.

You don't simply reach a limit, it just might be progressively harder keep things simple. Yet it happens in Corona constantly, and succesfully. UltraHDCache is more advanced, yet fully automatical. Before we had threads full of people asking for what settings to use thee.

Corona should not switch philosophy midway because it runs into small issues.

Rawalanche's suggestion to test adaptivity so single best parameter can be adopted, is much better than exposing the parameter, which would just lead to another headache of adjusting it per scene.

I honestly don't even touch GI/LSM anymore, even with more DOF and Motion blur, I don't see big difference to warrant fiddling with it. In time when my image is ready, they all converged almost identically with no benefit whatsover.



Artistic/Creative clutter (Framebuffer), that's another thing which is positive :- ) But not exposing more internalities. The first UI concept (by Raw) presented on previous page is fine imho.

[Frood]

Really? You don't think this would suddenly lead to "expert" tips for best settings and a lot of confusion and user errors?

Yes, maybe, so what? You will never be able to avoid this. And as long as you can explain what´s happening and you are able to point at the default settings button I don´t see why this should be much of a problem. Of course some users will put the cat in the microwave to make it dry as allways. If you look at my post(s) you´ll realize that I sign the rest of your answer.

Good Luck!

[Frood]

Corona should not switch philosophy midway because it runs into small issues.

I never proclaimed a paradigm shift away from simplicity and never will. Advanced vs. simple UI was just a discussion proposal because I see some conflicts.

[...] parameter, which would just lead to another headache of adjusting it per scene.

No headache if you leave it at default.

I honestly don't even touch GI/LSM anymore, even with more DOF and Motion blur, I don't see big difference to warrant fiddling with it. In time when my image is ready, they all converged almost identically with no benefit whatsover.

That surprises me in fact because until now it makes a significant difference for me depending on the scene. But it may lose relevance with adaptivity, let´s see.

Artistic/Creative clutter (Framebuffer), that's another thing which is positive :- ) But not exposing more internalities. The first UI concept (by Raw) presented on previous page is fine imho.

See, if internalities are not relevant - of course it makes no sense to expose them. I don´t know what you are refering to, but if it´s about for example adaptivityInterval: It´s some arbitrary number, maybe evaluated from test scenes. I don´t know how much cpu impact it´s calculation has, the system does not know how long "1 pass" will last and so on. But there is certainly a reason why it´s not calculated every pass (maybe it should be computed time dependend, not pass dependend?) This would be a example for simple vs. advanced UI while myself is pleased with a string option to control it as long as the possibility to do so exists.

Good Luck!

[Ondra]

Some time ago we promised that we will make Corona UI simpler, not more complicated. Right now we are almost certain that the max ray depth parameter will be removed in 1.4 as it is never necessary to change its value. Light samples multiplier might get removed as well because we are improving sampling of many lights. Additionally, I would like to remove GI/AA ratio in 1.5, when we introduce next level of adaptivity which sets this parameter automatically depending on scene. Max passes limit might get removed as well as the noise threshold option is more conventient. We also already removed internal resolution multiplier (will be replaced with some post-process option).

[racoonart]

Right now we are almost certain that the max ray depth parameter will be removed in 1.4 as it is never necessary to change its value.

Well... actually I used it quite a bit today ;) I've been rendering cloud panoramas using sss and reducing the max ray depth provided a big speedup in rendertimes without sacrificing too much quality. The "single bounce" option wasn't enough, 25 way too much, around 5 was perfect.
"Removing something will always break someone's workflow" :P

[antanas]

Right now we are almost certain that the max ray depth parameter will be removed in 1.4 as it is never necessary to change its value.

Well... actually I used it quite a bit today ;) I've been rendering cloud panoramas using sss and reducing the max ray depth provided a big speedup in rendertimes without sacrificing too much quality. The "single bounce" option wasn't enough, 25 way too much, around 5 was perfect.
"Removing something will always break someone's workflow" :P

 I totally agree with that, please do not remove\hide such things, of course I will agree that 99% of the time those settings are not needed but there might be that 1% which will spoil all the fun. Maybe it's true, and time has come for some ui split for something like Default\Physical(chuckle)\Photographic\Realistic(much louder chuckle) mode (and I think it's way better to call it that or some similar way than Basic as it could cause a lot of misunderstandings and advanced mode missuses by new users, as was stated by people in the above posts) and some sort of advanced mode.  Default mode could be simplified and new-user-friendly to the extreme and honestly 80% of the time I use corona I don't touch anything besides tonemapping controls too so it would be useful for me as well. But the advanced\expert\power-user\whatever mode could have much more tweakable settings for some special cases when those tweaks can be really helpful.

 A bit off-topic, but speaking of clouds, oh how much I miss VRayEnvironmentFog's step size parameters and subdivs for those, it would be invaluable if corona could have something like that, without some per material or per modifier (which could be even more useful) control of volumetric sampling density + some sort of quick interpolation between those samples, cause, strictly imo, without that, real sized clouds are totally impractical in those large scale scenes where those modelled or even procedurally generated clouds can be of tremendous value both for stills and animations alike.

 Same goes for per object density\quality\accuracy control of displacement which could be done per material or via CoronaDisplacementMod - as for now it's quite hard if not impossible to get, let's presume, some decent displaced close-up quality ground\tree bark\stones\tiles\bricks\etc + some way more sparse\less accurate displacement on some distant mountains\hills\sea\clouds\etc in the same scene as the ram consumption and rendertimes can skyrocket and currently one does not have any control over those parameters which are quite easy to tweak and understand even in the abovementioned vray.
 Those two are just some long time wishes which I brought up just as an example of that oversimplification (see Maxwell\Fryrender\Arion\Octane renderers and where that approach got them) is not allways the best way, while flexibility + ease of use + speed certainly are )
 And yeah as some poor attempt of some sad excuse for a joke - it's 3ds max plugin we are speaking of - simplicity was never 3ds max's way and probably will never be so why bother)

[Christa Noel]

Right now we are almost certain that the max ray depth parameter will be removed in 1.4 as it is never necessary to change its value.

Well... actually I used it quite a bit today ;) I've been rendering cloud panoramas using sss and reducing the max ray depth provided a big speedup in rendertimes without sacrificing too much quality. The "single bounce" option wasn't enough, 25 way too much, around 5 was perfect.
"Removing something will always break someone's workflow" :P

ondra, please don't completely remove it. I'm with deadclown for this max ray depth. I always adjust max ray depth to 10 when doing product shot. its only a simple scene with some objects and shadowcatcher plane and hdri lighting, simple but need good good details. just like deadclown said, reducing it makes rendering goes faster without affecting the quality too much.
for me, UI simplifying is always a good thing too eventhough it comes with removed some important things unless you plan to make it still reachable via maxscript or in devel/debug mode. power user need a room to keep their workflow.

[Nekrobul]

Some time ago we promised that we will make Corona UI simpler, not more complicated. Right now we are almost certain that the max ray depth parameter will be removed in 1.4 as it is never necessary to change its value. Light samples multiplier might get removed as well because we are improving sampling of many lights. Additionally, I would like to remove GI/AA ratio in 1.5, when we introduce next level of adaptivity which sets this parameter automatically depending on scene. Max passes limit might get removed as well as the noise threshold option is more conventient. We also already removed internal resolution multiplier (will be replaced with some post-process option).

NONONONONO

Hide it yes but not remove it. There are some scenarios wher it need to be pushed to the maximum. 2 mirror one in front of another and camera in between and if there is alot of refraction going on for example 10 plates of glass stacked.

[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.

[romullus]

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

[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.