Now in header-less panel at the top, and slightly bigger than default
size.
Even though this was intentionally removed (rB1cf17b257dd50), IMHO it's still reasonable to have it there.
Differential D3982
Add back render buttons to render settings Authored by Julian Eisel (Severin) on Nov 24 2018, 12:13 AM.
Details Now in header-less panel at the top, and slightly bigger than default Even though this was intentionally removed (rB1cf17b257dd50), IMHO it's still reasonable to have it there.
Diff Detail
Event TimelineComment Actions If this is added at all, it should go in the Output Properties. The Render Properties are for setting up the look and feel of your scene, all of which applies to viewport rendering. Output Properties are for resolution and export paths etc, everything to do with hitting F12 and outputting your work. Also, I think we should put these in the bottom, as an area that's always visible and doesn't scroll away. Otherwise you have to scroll up and down constantly to re-render after tweaking settings. Comment Actions I would propose putting the render buttons on top to the right of scene and view layer buttons. It has the following advantages:
Here is a quick mockup of the proposal: Render button group from left to right: Choose render engine, Choose to render preset, Render animation and render frame. Comment Actions I'd remove the presets button. Even the Render Animation there is not ideal, Rendering Animation is not something you do repeteadly all the time, since it's a time-consuming process that it's often done command line for speed and so on. About the Engine, the issue with showing it there is that it's not always relevant, for example when Video Editing, but it is kind of a corner case. Test just with the Render and Render Animation, no engine: With engine: In an actual blend file: Comment Actions I think that is too much clutter in the top bar, where we already have a Render menu in the same bar. Even having it as a permanent region in the render settings is too much in my opinion, just put it at the top of the render and output properties. Many users don't need to render often, and those that do will learn the F12 shortcut, use the menu, or the potential properties buttons. Comment Actions Well, in 2.7x, it’s very clumsy to use these buttons, because they will always scroll out of view. Think of a typical export dialog box - you’ll have a bunch of scrollable settings, and then an export button (following the workflow from top to bottom) at the bottom that is always accessible. So if we add this back, we should make it nicer than before. Until then, we have the Render menu and F12. Comment Actions Although I initially agreed with Brecht that the permanent region is a bit overkill, the idea has grown on me since then, here is why: So far there's almost no other place where we have such an extra region just to place some execution buttons in there (you could argue the file browser does). However, I think it could be nice to introduce such a design in more places - you setup some settings in one region, and there is a separate region to apply/execute an action based on those settings. Like a dialog but non-blocking. Cases where we could do this:
The reason to choose a separate region rather than just a bottom alignment of the buttons is to give them independent scrolling. But also, users could hide and theme the regions as they like it. Again, the concept would be: Setup settings in one region, execute an action based on those settings in another. Note that in the userpref_redesign branch, I've already added a new region type for this (RGN_TYPE_EXECUTE). Comment Actions The other thing about the Render Image/Animation buttons, is that they are a sort of exception anyway. We have no analog to these buttons inside Object Properties, ObData Properties etc, so to me it seems ok for the Render Properties be be a bit different in this way. We could also add something similar to other places where it makes sense to execute something, such as ObData (in the future with parametric objects you might need a place to 'freeze' the mesh) or with physics we might need a place to bake the physics too. Aside from that, the main practical advantages of the separated section are:
I agree with @Julian Eisel (Severin) that this could be nice in these various contexts, and it seems most of the legwork has been done already for the Preferences. Comment Actions Another place where @Julian Eisel (Severin) 's exec area could be nice is the Text Editor. There isn't really space for the path in the header, and the makes more sense to put Run Script in bottom right: Comment Actions I still disagree, it's too many UI regions and too much stuff you can't scroll off screen or get out of the way. There's already too much clutter like that in 2.8, with the topbar, statusbar, separate navigation/header buttons, .. all together. It makes things harder to scan and slower to use. Users who render often learn the shortcut, we don't need to clutter the UI with permanent buttons. Comment Actions Well, yes and no. My main point is, that if we are to add these kinds of buttons, we should do it in a way that makes them nice to use. We already have the F12 shortcut, and we already have the Render menu with Render Image and Render Animation. The old buttons what would scroll away and were at the very top weren’t very nice. You would have to scroll up and down, or add your own clumsy extra Render Properties Editor with the Render Image/Animation buttons constantly in view, below your main Properties Editor. To me it seems the subsection at the bottom of the Properties solved the issues with the old buttons, and will stay in place without moving around when you scroll through the list of Render settings. Like other areas in Blender I guess it can be made to be hidden too Comment Actions Here's where I would put the render buttons, and by adding it her, you will not miss click it, and it fit that place, and make it easy to see and use. |