I think that most of your suggestions are very good.
However, I am not sure if it is necessary to decouple the render editor from the image editor. I would much rather have the render editor in the same editor and make it possible to make it possible to use - for example - the paint function on the render.
Perhaps the render editor could be a context of the image editor, just like paint and mask are contexts of the image editor.
Interesting, for what reason would you rather have them in the same window? Simply to not have to switch to different windows, or do you utilize some of the image editor functions at the same time when tweaking your renders?
I imagine it would be easier to develop if it was in the same window and you want to use some of the same functions. For example you can allready paint over a “normal” image, so I guess it would not be that difficult to implement painting over a render. If it is the same editor it would probably be easier than if it was somewhere else.
I could be wrong of course.
Otherwise, the editor type selection thingy is allready getting crowded - especially with all the new node editors comming - and I have no problem with a couple of “dead” buttons around the UI. The textures being in the drop down don’t bother me either because you can just type in “render” and you’ll get the render result.
Since it is very similar to the other image editor contexts I think it fits there perfectly.
But this is a minor issue. If it is easier to implement a whole new editor or if others greatly prefer it then I’d have no problem with that either.
I totally agree with you, the task of rendering is so specific that it doesn’t fit in a general purpose image editor like we have today. The list of points you raise proves it easily. Having dead buttons and an unpredictable behavior on some others is the basis for a clumsy user experience, fitting a square peg in round hole.
One other aspect which could be interesting to investigate is how this window could be used with external render engines like LuxCoreRender, it can give some ideas on how the window relates to the selected render engine…
Preaching to the choir here…
Even after all this time using Blender, I find the rendering tools extremely annoying and archaic.
It often feels like rendering in Maya 3.0!
No dedicated render window, no multi scene/view layer batch rendering, no proper light management, no proper override system etc. These are things that -need- to be addressed for version 3.0 imho. Especially if they want to see Blender making in-roads into studios. Especially lighters/render artists don’t like to go -back- in functionality when switching apps. Especially when all the other applications -do- have these features in use.
So… rant over…
I do agree on a dedicated render window.
Comparing. For comparing I would like to see a A/B functionality, like in Nuke, the Vray Render Buffer window etc. No need for a doubled windows imho, but a slider for comparing renders. Sometimes the tweaks you’re doing are so subtle, a ‘wipe slider’ is better for seeing what’s happening.
Renders. Blender has a terrible file system, it’s all over the place. This shouldn’t be that hard, and there should be -at least- a dedicated folder for temporary renders, These temp renders should show up in a dropdown list, or a panel on the side. Like with Vray. Or have the slots as numbers, so you can quickly switch between them.
Also, get in a bleeping basic file naming structure for temp files by default.
Tweaks. There should be some tools to tweak the rendered image. For one RGBA channel selection.
This is great for quick checks on the rendered image.
In addition, some tools for quickly change gamma, levels, color etc.
Passes. And to top it off, a dropdown for the rendered passes, so I can see my diffuse, specular, SSS etc. They already implemented this in the render viewport, so the option is there.
Interactive. A button to sync up the render view and scene. Like with the rendered viewport, but for the render view. This also due to the fact that the rendered viewpoort & a F12 render can look different.
3rd Party. If there’s a dedicated window with the basic functionality above, it might help integrate 3rd party renderers more easily.
So… That’s me on this
I would advice you to move this to the developer forum, and try to get momentum there.
If the different render slots can be saved in the render window, and edit externally works to edit them in the specified image editor in the preferences, would you still want this temp drop-down list?
You can quickly switch between the slots by pressing their numbers on the keyboard. Would you implement it differently?
What would you add to the current display channels drop down?
That’s interesting and there are quite a few others that have requested more color grading tools in the render window. It raises the question of how much should be available in the render window and how much should be done in the compositor. I would assume there would be quite a few users that would rather not use the compositor.
You mean without the need to render them first? I can see how this can be useful, it is really cool how it is implemented in the viewport.
That’s very interesting! Something the developers could look into if they find that makes sense.
At beginning of 2.8 development, there was a dynamic enthusiasm to change rendering UI.
But it just stopped at improvements of Render Slots panel.
I think that nobody would be hostile to a way to compare render slots.
We have tools to compare images in Video Sequencer or Compositor but nothing for Render window.
You are right about the fact that Render Result should not re-employ templates and UI stuff made for Images.
Issue about window disappearing is not relative only to render.
Under some OS like linux : that is not a problem.
Under others : there are addons solving that.
And we have a Rendering workspace and can avoid to have a temporary window for rendering by changing a preference.
So, despite the fact this is not really an issue , Color Management panel in sidebar makes sense.
I am not sure about the flip button. Rendering happens at a final step of a long process. It probably makes more sense for Camera View in 3D Viewport. I think it is planned to do such thing.
About annotations, it is not necessary to have an Annotations datablock per render slot. I am more inclined to have a a restriction field to limit display of an annotation to a specific render slot.
That would allow to keep some general annotations visible through all render slots.
To sum-up, I think that we could have a Render Result/Viewer editor that would be a fake Image Editor like Timeline is a fake dopesheet.
Just few more operators with specific shortcuts and a different header.
In my opinion it’s unnecessary to make more windows.
But some of your points are valid to be added as a feature in the existing Image viewer.
Having something like Collection but for Images. Having this, you can hide textures in the drop down menu.
(BTW, what we really need!!! is an outliner/list viewer specifically for shaders and images) like in maya
It can be also be used later for import/export and management of libraries.
Compare and Split Screen? Yes!
Save Button, Yes!
Free slot button, and annotations per slot --Yes!
Color managing should be done in composer.
Perhaps, we can provide an interface to make some public variables from shaders and compositions. Which will make them editable in 3d, btw Image View. Like it’s done in Unreal.
@Steve_White: Not to rain on your parade, bur rightclick is a slow burning dumpster fire, where ideas go to die a slow death. There’s absolutely z.e.r.o. interaction with developers.
I stopped posting ideas and suggestions really quickly after ‘burned’ down by the mods.
Again, I suggest posting this on the developer forum to get more traction. On this forum it will not be noticed I’m afraid.
I checked the video, and I have to disagree with the author. I’d recommend to use embedded window for renders.
In my opinion image and uv workspaces are a bit similar, but it’s ok. But making another almost the same window with minor differences is a fail. It will overload Blender UI.
However there are several good assumptions, like annotations. But I think it’s better to put annotations to additional layer.