Rework Renderer Menu #37742

Closed
opened 2013-12-08 23:12:20 +01:00 by William Reynish · 52 comments

Renderer_menu.png

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
![Renderer_menu.png](https://archive.blender.org/developer/F37577/Renderer_menu.png) **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
Author
Member

Changed status to: 'Open'

Changed status to: 'Open'
Author
Member

Added subscriber: @billrey

Added subscriber: @billrey

Added subscriber: @brecht

Added subscriber: @brecht

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.

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.
Author
Member

@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

@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)
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)
Author
Member

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.

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.
Author
Member

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

renderer_dropdown.png

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

It might make sense to put the renderer menu in the render properties, like so: ![renderer_dropdown.png](https://archive.blender.org/developer/F38001/renderer_dropdown.png) With the Render, Animarion, Audio and Play buttons removed, we could put the 'Feature Set' menu under the renderer menu too.

Added subscriber: @ThomasDinges

Added subscriber: @ThomasDinges

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

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
Author
Member

@ThomasDinges: 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.

@ThomasDinges: 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.
Author
Member

Perhaps something like this?

Renderer_layout.png

Perhaps something like this? ![Renderer_layout.png](https://archive.blender.org/developer/F38649/Renderer_layout.png)

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.

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.

Added subscriber: @JonathanWilliamson

Added subscriber: @JonathanWilliamson

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.

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.

@brecht: Agreed, looks better :)

[ F39026]

@brecht: Agreed, looks better :) [ [F39026](https://archive.blender.org/developer/F39026/renderer_ui_2.jpg)]
Author
Member

@ThomasDinges: 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?

@ThomasDinges: 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. :)

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

@ThomasDinges: 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.

@ThomasDinges: 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.

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

Added subscriber: @zeauro

Added subscriber: @zeauro

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.

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.
Author
Member

@ThomasDinges: 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.

@ThomasDinges: 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.

Added subscriber: @BartekMoniewski

Added subscriber: @BartekMoniewski

Added subscriber: @Luarvik

Added subscriber: @Luarvik

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.

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.
Author
Member

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

@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".

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".
Author
Member

@BartekMoniewski: Good point. 'Render Current Frame' / 'Render Sequence' is very clear. Bit verbose though.

Perhaps

Render:
Frame / Sequence
@BartekMoniewski: Good point. 'Render Current Frame' / 'Render Sequence' is very clear. Bit verbose though. Perhaps ``` Render: Frame / Sequence ```

Added subscriber: @Paul.Brachmann

Added subscriber: @Paul.Brachmann

I think the render buttons should be left where they are. I also think the buttons should be renamed as @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.

I think the render buttons should be left where they are. I also think the buttons should be renamed as @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.

@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).

@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).

Added subscriber: @Brachi

Added subscriber: @Brachi

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.

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.

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.
Added subscriber: @JoseMariaRichardsonRebellodeAndrade

Added subscriber: @drekryan

Added subscriber: @drekryan

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.

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.

Added subscriber: @PawelLyczkowski-1

Added subscriber: @PawelLyczkowski-1

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.

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.

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.

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.

@PawelLyczkowski-1 That is not a valid concern imho, for this we have i18 support, so people with basic English can use their native language.

@PawelLyczkowski-1 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.

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.

Added subscriber: @robertltux

Added subscriber: @robertltux

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

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!

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

Added subscriber: @mont29

Added subscriber: @mont29

Added subscriber: @ideasman42

Added subscriber: @ideasman42

Changed status from 'Open' to: 'Archived'

Changed status from 'Open' to: 'Archived'
Campbell Barton self-assigned this 2016-03-10 06:31:07 +01:00

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

No resolution or activity in over 3 months, archiving, listed in [the wiki ](http://wiki.blender.org/index.php?title=Dev:Source/Development/Todo/UserInterface#Archived_Design_Tasks). Can re-open when we have time to handle this one.
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
15 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#37742
No description provided.