Page MenuHome

Rework Renderer Menu
Closed, ArchivedPublic

Description

Outline
Blender has number of rendering subsystems, including Cycles, Internal, Game, OpenGL and FreeStyle. The problem is that work inconsistently, they clutter up the UI in unnecessary ways and have a confusing relationship to one another.

Current issues

  • OpenGL & FreeStyle are currently hard to find and illogically placed (FreeStyle settings are found inside the Internal render properties)
  • It's hard to combine FreeStyle with anything other than Internal because it lives inside the Internal renderer
  • OpenGL rendering acts differently from Cycles or Internal because it defaults to rendering the current view rather than the active camera.
  • OpenGL renderer settings live inside a strange panel inside the Cycles or Internal render properties

Proposed solution
Consolidate all the renderers in a single menu and simplify the structure, so that each renderer's settings only appear in the render properties when active.

Advantages

  • Cleans up 3D View headers, and render properties, only showing settings for the active renderer
  • Makes all the renderers consistent in their behaviour
  • Decouples FreeStyle from Internal so it can be better combined with any other renderer
  • Makes it easy to deal with adding more renders (e.g. Lux Render), when each renderer doesn't have to deal with the OpenGL or FreeStyle render settings

Details

Type
Design

Event Timeline

William Reynish (billrey) set Type to Design.
William Reynish (billrey) raised the priority of this task from to Needs Triage by Developer.
Brecht Van Lommel (brecht) triaged this task as Normal priority.

I fear this won't work. OpenGL render can be different for each render engine, for Cycles it will approximate Cycles materials, for Blender Internal it will approximate Blender materials, etc. For solid draw mode it doesn't matter much but with textures and GLSL they are very different, and it's not clear what should happen when you select OpenGL as renderer.

For Freestyle, putting it in the menu makes decoupling from Blender Internal harder? It's not clear which renderer should be used for shading if Freestyle is already set as the renderer.

@Brecht Van Lommel (brecht): I guess this is the sort of thing that goes fairly deep.

For FreeStyle, having it connected to BI is a bit of a shame. I guess the nicest thing might be to integrate FreeStyle into the compositor - that way you could combine it with any renderer, and you wouldn't have to re-render the shading in the scene for the rather complicated FreeStyle settings to take effect. But I'm sure it'd require a large re-design of FreeStyle

Freestyle can't be done in the compositor, it's using the scene database, meshes, marked edges, etc. to figure out where to put lines. So it needs to be somewhere in the rendering process. It's possible in principle to make it work with Cycles, but from a design point of view it doesn't seem to help to have it as a renderer then.

I think the OpenGL and Freestyle concepts are just different than a renderer, they are something that you use along with one.

Somewhat related, I thought about some other changes:

  • Move the renderer picking to the Render menu, not always visible.
  • Remove the Render/Animation/Audio/Play from the properties editor and put only in the Render menu.
  • Remove OpenGL render from the 3D view header and put it in the Render menu also (will need some way to pick which viewport if there are multiple)

Those would be nice too. Having the OpenGL render buttons always on the 3D View header seems overly intrusive.

Although I realize the usefulness of OpenGL rendering (primarily animators use it for quick playblasts) I don't think it warrents such prominent placement, and it's confusing because it looks like buttons for doing actual final renders, not playblasts.

As for the renderer being in the menu, I agree with that too. Once you set the renderer (and it being set to Cycles by default), you'd rarely ever be changing it while working on a project.

It might make sense to put the renderer menu in the render properties, like so:

With the Render, Animarion, Audio and Play buttons removed, we could put the 'Feature Set' menu under the renderer menu too.

I think something needs to be done here for sure, I am really not happy with the current look of the "Render" panel, since Audio button was added it looks really cluttered.

I agree with moving the Render menu from Info header to Properties editor

@Thomas Dinges (dingto): Yes, agreed, it does look a bit messy there, esp with the Display and Feature Set menus misaligned. But of those are removed, it should clean up things nicely again.

Perhaps something like this?

I performed the Render changes, see attached screenshot and patch.

I decided to have the Engine in its own panel (without header, so always pinned at the top), as this option is still more important than Display etc.

Personally I prefer to have the render engine choice inside the panel, and also in Render menu, maybe expanded with layout.props_enum for quick switching.

@Thomas Dinges (dingto): nice, starting to look good.

I can see the argument for putting the renderer above the rest of the controls, outside the panels as in your original version. It's a bit like the datablock controls that are outside the regular panes in other properties areas. Conceptually, the renderer is the 'parent' of the rest of the items in the Render properties.

But then the Feature Set and Display menus feel a bit lonely :) Display I feel is more a preference anyway, we could move that there. That leaves Feature Set. Could put it in the Render menu?

Edit: Oh, I see you already removed Display and OSL controls. Where'd they go?

In my latest screenshot I have Blender Internal selected. Feature set and OSL would just come beneath. :)

@Thomas Dinges (dingto): If we do keep it, perhaps the render panel should be renamed to 'Engine' or 'Renderer'? Since you can longer render using this panel, we should no longer use a verb here.

The menu improvements look great but I don't think I agree about removing the Render / Animation buttons from the properties. All of the render settings affect the result of pressing Render, and so only having Render in the menu creates a disconnect between the settings and the action.

I moved the "Play" button now away, is only available inside the "Render" menu anymore. This already fixes the stupid misalignment.

I guess we could move "Audio" away to where it was (scene buttons) or add to render menu.

Then the only remaining decision would be on the Engine selector. If we keep the Render/Animation buttons, I would move the engine selector to a headerless panel.

I agree with carter2422. Buttons should be kept in the panel.
Maybe misalignement and cluttering could be avoïded by keeping one line of icons only buttons. icons meaning is explained in Render Menu.

Engine selector in Info header is helpfull for custom screens with 3DView or node editor and no properties editor.
Even if selector is removed, I think info should still be present in info header.

@Thomas Dinges (dingto): Agreed. Sounds like a good plan to put Audio Mixdown into the Render menu, as well as the Scene Properties. Then Image/Animation/Play can be put back on the single tidy line, and as you say, the engine selector can go in a headerless panel.

How about renaming Render / Animation buttons to Image / Sequence? Currently it looks like "render Render"/ "render Animation" which is a bit confusing. Or as an alternative there could be a switch between Image/Sequence and one big Render button. What do you think?
P.S. And in case of second option, that Render button could be placed in the info panel where currently renderer engine menu located, so you can always reach it, even if properties panel is not visible.

@Sergei Smyslov (Luarvik): Yes, semantically it makes no sense to call it Render/Animation. Clicking 'Animation' also starts a render, and 'Render' does not communicate that it's a single image at all. Render what? The current wording makes no sense whatsoever.

Here are some variations that'd all work better

Render:
Image / Animation

_

The word 'image' isn't 100% optimal either, because animation sequences are also series of images. The singular form 'image' (as opposed to 'images') might be ok, but it's still a bit ambiguous.

This I think is clear:

Render: 
Still / Sequence

or

Render: 
Still / Animation

The term 'Animation' I'm not sure about. It is sometimes used to mean more specific things than moving pictures. It can mean character animation, bringing dead things to life, etc.

From my perspective "Still" not only stands for single static frame but also specific approach in creative process. Whereas people often render single frames as previews of animation. I suggest to use just "Frame" or "Current Frame".

@Bartosz Moniewski (monio): Good point. 'Render Current Frame' / 'Render Sequence' is very clear. Bit verbose though.

Perhaps

Render:
Frame / Sequence

I think the render buttons should be left where they are. I also think the buttons should be renamed as @William Reynish (billrey) said.
The audio mixdown button should be moved to the scene tab or the complete audio settings menu should be moved to the render tab (but I think thats too much for one tab).
Also the audio button should be renamed to 'Audio Mixdown'.
Thats my opinion, I hope it helped.

@William Reynish (billrey)
Yes, "Frame / Sequence" sounds perfect to me!

Would it be an off-topic to also propose moving Active Camera option from Scene tab to Render tab (maybe to Render or Dimensions panel)? In my opinion it's one of those very basic things which fundamentally affects a rendering process and it's results, so I think it would be very convenient and logical to have it together with other render settings. (Basically, you can't render at all if there is no camera set).

I agree that Active Camera is a basic thing that fundamentally affects a rendering process and i's results.
But Renderlayers too and they have their own tab.

They are defined as scene properties like active camera.
The advantage is that logic is respected when you use camera override option of a scene strip in VSE to change active camera. You just change a scene property.
When you are mixing too renderlayer input nodes with same scenes with same assets but different active camera; it is just different scenes properties that are defined. You don't have to reset things in Render Tab.

And if you take under consideration the convention to avoïd animatable properties in Render Tab; it implies several non minor changes to move active camera option to Render Tab.
In brief, for complex set up, I don't think it is pertinent.

In multiview branch for stereoscopic rendering; you have to precise two active cameras.
And a "Views" panel was added to Renderlayers Tab in this branch.

Thank you for your comment, it has some new and valuable information for me.
But I disagree that "render layers" is a basic rendering option. I think it's rather an advanced tool more related to post processing.
I am just an artist, and not a programmer, so I apologize if my comments are technically out of sense, but I was proposing to change only the UI location of Active Camera setting, not VSE or any other functionality. Internally it may stay as scene property and continue to work well for all complex setups, but also gives us ability to quickly change camera between multiple renders. Of course, if that's impossible and this change in UI affects other Blender functions in a negative way, I will vote for functionality over convenience.

I think having some of the render modes be renamed would really make things a lot of technical and confusing for new users. Renaming "Cycles Render" to "Cycles" would be a welcome change in my opinion. Thats just one example but I think the biggest issue with blender is the language and wording it uses is never clearly understandable.

Renaming Render to Frame has some disadvantages I'm afraid. It is associated with animation, so when a simple artist want to render an image, he can assume that Frame is not what he is looking for. Render: Image/Animation does not have this problem.

I think as mentioned in the previous comments that Render "Still" / "Sequence" would be pretty clear. I do agree with the previous comment that Frame may not be so clear.

Render Still/Sequence on the other hand could be problematic for amateurs and people with only basic English. It's still better than Frame though.

@Paweł Łyczkowski (plyczkowski) That is not a valid concern imho, for this we have i18 support, so people with basic English can use their native language.

There's always going to be a trade off that needs to be considered. Sometimes you have to sacrifice one thing for another. There is no perfect solution in my opinion. I think the common goal we should be aiming for is a term that is clear for a majority (keyword majority) of users. Blender has always been pretty confusing to those first getting into it so I think reworking the language and terms used could really help it be more user friendly. But like I said in some cases it may be unclear to someone but sometimes there's no way around that and that's where to internet and documentation come into play along with the thousands of written and video tutorials. Just my two cents.

Could somebody contact me about the Blender Internal renderer possibly being BROKEN?? I need somebody to either help sort out BI or help me figure out Cycles.

I am using an atom based netbook with intel graphics running win7 32 bit.

One thing that would help is for an error message to be given when you have BI materials and Cycles set to the renderer (or the reverse).

Robert, please report a regular bug report on this site instead of posting this here, that is off topic!

Campbell Barton (campbellbarton) closed this task as Archived.

No resolution or activity in over 3 months, archiving, listed in the wiki.
Can re-open when we have time to handle this one.