Smooth shading usabilty #68893

Open
opened 2019-08-20 20:20:20 +02:00 by Dalai Felinto · 33 comments

When adding a mesh primitive in Blender, it is by default flat-shaded without subdivision surfaces. This means that after adding a new object with a smooth surface (like a sphere or monkey mesh), the user almost always has to change some settings.

We could change the default mesh settings to avoid that. However there are two distinct use cases which require different settings.

  • Meshes with autosmooth and/or custom normals. This could be either a low poly model for games, or a high poly model imported from CAD software.
  • Subdivision surfaces with creases to define sharp areas of the model. Custom normals are lost in the subdivision process, and autosmooth can't be combined with GPU acceleration.

Once subdivision surface settings become part of the mesh (#68891 (Subdivision surface settings part of the Mesh)), we could handle these as more distinct cases in the user interface and implementation.

  • If a mesh is a subdivision surface, no autosmooth or custom normals would be available.
  • Subdivision surface mesh primitives could be in a separate submenu of the Add menu, with all faces smooth shaded by default.
  • Mesh primitives could have smooth shaded faces and autosmooth enabled by default when it makes sense.

Enabling autosmooth by default will negatively impact performance, particularly in edit mode. It's not obvious this is something we want to do. Further optimizations in this area are possible, but there will always be a cost.

When adding a mesh primitive in Blender, it is by default flat-shaded without subdivision surfaces. This means that after adding a new object with a smooth surface (like a sphere or monkey mesh), the user almost always has to change some settings. We could change the default mesh settings to avoid that. However there are two distinct use cases which require different settings. * Meshes with autosmooth and/or custom normals. This could be either a low poly model for games, or a high poly model imported from CAD software. * Subdivision surfaces with creases to define sharp areas of the model. Custom normals are lost in the subdivision process, and autosmooth can't be combined with GPU acceleration. Once subdivision surface settings become part of the mesh (#68891 (Subdivision surface settings part of the Mesh)), we could handle these as more distinct cases in the user interface and implementation. * If a mesh is a subdivision surface, no autosmooth or custom normals would be available. * Subdivision surface mesh primitives could be in a separate submenu of the Add menu, with all faces smooth shaded by default. * Mesh primitives could have smooth shaded faces and autosmooth enabled by default when it makes sense. Enabling autosmooth by default will negatively impact performance, particularly in edit mode. It's not obvious this is something we want to do. Further optimizations in this area are possible, but there will always be a cost.
Author
Owner

Added subscriber: @dfelinto

Added subscriber: @dfelinto

Added subscriber: @1D_Inc

Added subscriber: @1D_Inc
  • Subdivision surface mesh primitives could be in a separate submenu of the Add menu, with all faces smooth shaded by default.
    Can be a checkbox in creation parameters menu?
- Subdivision surface mesh primitives could be in a separate submenu of the Add menu, with all faces smooth shaded by default. Can be a checkbox in creation parameters menu?

Creating flatshaded allow to check up geometry polygonage (a "weight"). Indeed, it is very important for gamedev.
We solved autosmooth issue in a simple way - created Set Autosmooth operator that applies 70 degree autosmooth to selected models.

70 degrees allows to keep pentagonal cylinder as flat and hexagonal cylinder as smooth, so it very profound value for most cases we faced with.
So we has got very simple unified workflow:

  • Created flatshaded meshes allow to check up it's density.
  • Set Autosmooth operator (space menu - AU) allow to set proper autosmooth that fits most cases.
  • If it isn't somewhere enough we providing sharp edges.

Using it starting from architecture and ending with baroque modeling and lowpoly assets.

Creating flatshaded allow to check up geometry polygonage (a "weight"). Indeed, it is very important for gamedev. We solved autosmooth issue in a simple way - created Set Autosmooth operator that applies 70 degree autosmooth to selected models. 70 degrees allows to keep pentagonal cylinder as flat and hexagonal cylinder as smooth, so it very profound value for most cases we faced with. So we has got very simple unified workflow: - Created flatshaded meshes allow to check up it's density. - Set Autosmooth operator (space menu - AU) allow to set proper autosmooth that fits most cases. - If it isn't somewhere enough we providing sharp edges. Using it starting from architecture and ending with baroque modeling and lowpoly assets.

Added subscriber: @JonathanLampel-4

Added subscriber: @JonathanLampel-4

Enabling autosmooth by default will negatively impact performance, particularly in edit mode. It's not obvious this is something we want to do. Further optimizations in this area are possible, but there will always be a cost.

I think we could improve usability here quite a bit without any performance cost.

Let's say we hide the Auto Smooth toggle completely and only have one slider for the smooth shading angle. 0° is exactly the same as flat shaded in every scenario, so internally Auto Smooth would be off. This could be the default with no performance hit. 180° would be the same as smooth shaded, unless edges are marked as sharp. So if no edges are marked sharp, Auto Smooth is also off at 180°. If the angle is anywhere in between or if any sharp edges have been set, Auto Smooth could automatically come on behind the scenes. Setting smooth and flat shading would then not be setting a property of the object but setting a preset for the smooth shading angle.

The benefit of this is never having to think about whether something is set as smooth or flat shaded, or if auto smooth is off or on (warning signs in modifiers, setting sharp apparently doing nothing without any explanation, etc.) - it would all just work as expected and be a faster workflow.

> Enabling autosmooth by default will negatively impact performance, particularly in edit mode. It's not obvious this is something we want to do. Further optimizations in this area are possible, but there will always be a cost. I think we could improve usability here quite a bit without any performance cost. Let's say we hide the Auto Smooth toggle completely and only have one slider for the smooth shading angle. 0° is exactly the same as flat shaded in every scenario, so internally Auto Smooth would be off. This could be the default with no performance hit. 180° would be the same as smooth shaded, unless edges are marked as sharp. So if no edges are marked sharp, Auto Smooth is also off at 180°. If the angle is anywhere in between or if any sharp edges have been set, Auto Smooth could automatically come on behind the scenes. Setting smooth and flat shading would then not be setting a property of the object but setting a preset for the smooth shading angle. The benefit of this is never having to think about whether something is set as smooth or flat shaded, or if auto smooth is off or on (warning signs in modifiers, setting sharp apparently doing nothing without any explanation, etc.) - it would all just work as expected and be a faster workflow.

In #68893#788970, @JonathanLampel-4 wrote:
one slider for the smooth shading angle. 0° is exactly the same as flat shaded in every scenario.

Sounds similar to sketchup solution, also, as far as I remember, same behaviour were used in some shader nodes.
So why not, I can’t find cases in which this solution causes problems)
I will ask webgl modellers, such things are always fragile in gamedev/realtime.

> In #68893#788970, @JonathanLampel-4 wrote: > one slider for the smooth shading angle. 0° is exactly the same as flat shaded in every scenario. Sounds similar to sketchup solution, also, as far as I remember, same behaviour were used in some shader nodes. So why not, I can’t find cases in which this solution causes problems) I will ask webgl modellers, such things are always fragile in gamedev/realtime.

Asked webgl artists.
Indeed, smart autosmooth slider seems to be ok, if "shade flat" and "shade smooth" options will be available for mesh editing.
This way, placing smart autosmooth slider to adding object preferences with default=0 seems to be a nice solution both for usability and perfomance issues.

Asked webgl artists. Indeed, smart autosmooth slider seems to be ok, if "shade flat" and "shade smooth" options will be available for mesh editing. This way, placing smart autosmooth slider to adding object preferences with default=0 seems to be a nice solution both for usability and perfomance issues.

Added subscriber: @WilliamReynish

Added subscriber: @WilliamReynish

Some apps make it so Smooth Shading is always enabled when using Subdivision Surfaces. If we did that, or had a boolean to enable this in the modifier which was enabled by default, that would make the process of achieving smooth shapes simpler.

Some apps make it so Smooth Shading is always enabled when using Subdivision Surfaces. If we did that, or had a boolean to enable this in the modifier which was enabled by default, that would make the process of achieving smooth shapes simpler.

Indeed, a boolean can be a nice option.
For instance, in gamedev modeling subd flat shading will allow to percept mesh density, while in organic/hardsurface modeling subd smooth shading will allow to see smooth result immediately to check up for artifacts with zebra shading.

https://youtu.be/mIpJq9y_Qic?t=237

Indeed, a boolean can be a nice option. For instance, in gamedev modeling subd flat shading will allow to percept mesh density, while in organic/hardsurface modeling subd smooth shading will allow to see smooth result immediately to check up for artifacts with zebra shading. https://youtu.be/mIpJq9y_Qic?t=237

An excellent example of automotive modeling.
Car is made in flat/autosmooth shading, because it allows to feel an actual geometry, and subd with smooth shading option allow to see the final result of every part.

https://youtu.be/757ZnC7bPF4?t=639

Global checkbox that allows smooth shading for subd will be useful, as it's state depends on gamedev or hardsurface workflow type that artist performs.

An excellent example of automotive modeling. Car is made in flat/autosmooth shading, because it allows to feel an actual geometry, and subd with smooth shading option allow to see the final result of every part. https://youtu.be/757ZnC7bPF4?t=639 Global checkbox that allows smooth shading for subd will be useful, as it's state depends on gamedev or hardsurface workflow type that artist performs.

Added subscriber: @Bango

Added subscriber: @Bango

Wouldn't it be user-friendlier to implement a setting in the preferences where the user can preset the angle value of auto smooth for future projects/assets himself?

Wouldn't it be user-friendlier to implement a setting in the preferences where the user can preset the angle value of auto smooth for future projects/assets himself?

Added subscriber: @CobraA

Added subscriber: @CobraA

I have observed one thing with the autosmooth in comparison to another software, Blender seems to calculate it (realtime) all the time.

Here is Blender's example, while the other DCC the users have to "apply" autosmooth when they need it, it doesn't happen each time you change angle of the edges ...so is this what impacts the performance?

{F8350411 size = full}

I have observed one thing with the autosmooth in comparison to another software, Blender seems to calculate it (realtime) all the time. Here is Blender's example, while the other DCC the users have to "apply" autosmooth when they need it, it doesn't happen each time you change angle of the edges ...so is this what impacts the performance? {[F8350411](https://archive.blender.org/developer/F8350411/Smooth.gif) size = full}

In #68893#876084, @CobraA wrote:
I have observed one thing with the autosmooth in comparison to another software, Blender seems to calculate it (realtime) all the time.

This feature is used in organic surface modeling to set geometry angles to a specified autosmooth. It allow to see if surface have wrong tension and curvature and quickly set correct one.

DF.jpg

That's one of the reasons Blender is so good for optimized organic modeling.

изображение.png

> In #68893#876084, @CobraA wrote: > I have observed one thing with the autosmooth in comparison to another software, Blender seems to calculate it (realtime) all the time. This feature is used in organic surface modeling to set geometry angles to a specified autosmooth. It allow to see if surface have wrong tension and curvature and quickly set correct one. ![DF.jpg](https://archive.blender.org/developer/F8350870/DF.jpg) That's one of the reasons Blender is so good for optimized organic modeling. ![изображение.png](https://archive.blender.org/developer/F8350901/изображение.png)

In #68893#876132, @1D_Inc wrote:

In #68893#876084, @CobraA wrote:
I have observed one thing with the autosmooth in comparison to another software, Blender seems to calculate it (realtime) all the time.

This feature is used in organic surface modeling to set geometry angles to a specified autosmooth. It allow to see if surface have wrong tension and curvature and quickly set correct one.

DF.jpg

That's one of the reasons Blender is so good for optimized organic modeling.

изображение.png

I don't get your point, my question is about performance not where this feature is useful for, I assume everybody knows that already.

> In #68893#876132, @1D_Inc wrote: >> In #68893#876084, @CobraA wrote: >> I have observed one thing with the autosmooth in comparison to another software, Blender seems to calculate it (realtime) all the time. > > This feature is used in organic surface modeling to set geometry angles to a specified autosmooth. It allow to see if surface have wrong tension and curvature and quickly set correct one. > > ![DF.jpg](https://archive.blender.org/developer/F8350870/DF.jpg) > > That's one of the reasons Blender is so good for optimized organic modeling. > > > ![изображение.png](https://archive.blender.org/developer/F8350901/изображение.png) I don't get your point, my question is about performance not where this feature is useful for, I assume everybody knows that already.

In #68893#876348, @CobraA wrote:
I don't get your point, my question is about performance not where this feature is useful for, I assume everybody knows that already.

I think we both are not sure what this question is about)
Is it about removing a feature to increase perfomance to satisfy some users? This is how this question sounds like.
For sure, any kind of realtime calculations lowers perfomance, but in this case It depends on the workflow, we cannot accept removing this.

Also what is "DCC" by the way?

p.s. aw, Digital Content Creation from UE/gamedev.
Well, it seems you indeed just asked, sorry then.
We have had a lot of things spoiled recently due to such things, so we have to be careful.

> In #68893#876348, @CobraA wrote: > I don't get your point, my question is about performance not where this feature is useful for, I assume everybody knows that already. I think we both are not sure what this question is about) Is it about removing a feature to increase perfomance to satisfy some users? This is how this question sounds like. For sure, any kind of realtime calculations lowers perfomance, but in this case It depends on the workflow, we cannot accept removing this. Also what is "DCC" by the way? p.s. aw, Digital Content Creation from UE/gamedev. Well, it seems you indeed just asked, sorry then. We have had a lot of things spoiled recently due to such things, so we have to be careful.

In #68893#876385, @1D_Inc wrote:

In #68893#876348, @CobraA wrote:
I don't get your point, my question is about performance not where this feature is useful for, I assume everybody knows that already.

I think we both are not sure what this question is about)
Is it about removing a feature to increase perfomance to satisfy some users? This is how this question sounds like.
For sure, any kind of realtime calculations lowers perfomance, but in this case It depends on the workflow, we cannot accept removing this.

Also what is "DCC" by the way?

p.s. aw, Digital Content Creation from UE/gamedev.
Well, it seems you indeed just asked, sorry then.
We have had a lot of things spoiled recently due to such things, so we have to be careful.

Am i talking to a bot or something? because your replies don't read as human at all.

I think it's best to let a Dev answer this kind of questions, My point if this constant live update of smoothing is causing a huge performance slowdowns then maybe a different approch should be taken like the other DDC(Softwares)

I would take huge performance boost over fancy live update any day.

> In #68893#876385, @1D_Inc wrote: >> In #68893#876348, @CobraA wrote: >> I don't get your point, my question is about performance not where this feature is useful for, I assume everybody knows that already. > > I think we both are not sure what this question is about) > Is it about removing a feature to increase perfomance to satisfy some users? This is how this question sounds like. > For sure, any kind of realtime calculations lowers perfomance, but in this case It depends on the workflow, we cannot accept removing this. > > Also what is "DCC" by the way? > > p.s. aw, Digital Content Creation from UE/gamedev. > Well, it seems you indeed just asked, sorry then. > We have had a lot of things spoiled recently due to such things, so we have to be careful. Am i talking to a bot or something? because your replies don't read as human at all. I think it's best to let a Dev answer this kind of questions, My point if this constant live update of smoothing is causing a huge performance slowdowns then maybe a different approch should be taken like the other DDC(Softwares) I would take huge performance boost over fancy live update any day.

Added subscriber: @brecht

Added subscriber: @brecht

I think the idea by @CobraA in #68893#876084 is a good one. Autosmooth in general is not something you even want to change as you deform the mesh with modifiers, because then it pops in animation. If you do want it then an explicit edge split modifier should probably be used instead. So replacing autosmooth by a way to update sharp edge tags while in edit mode make sense to me (either manually or perhaps automatic for tools like transform if desired).

This helps with performance, but only in part. Autosmooth involves both detecting which edges are supposed to be smooth, and then computing normals based on that information. So to make it really low overhead, we may also need to reconsider how to store and update the normals.

I think the idea by @CobraA in #68893#876084 is a good one. Autosmooth in general is not something you even want to change as you deform the mesh with modifiers, because then it pops in animation. If you do want it then an explicit edge split modifier should probably be used instead. So replacing autosmooth by a way to update sharp edge tags while in edit mode make sense to me (either manually or perhaps automatic for tools like transform if desired). This helps with performance, but only in part. Autosmooth involves both detecting which edges are supposed to be smooth, and then computing normals based on that information. So to make it really low overhead, we may also need to reconsider how to store and update the normals.

In #68893#876725, @CobraA wrote:

I think it's best to let a Dev answer this kind of questions, My point if this constant live update of smoothing is causing a huge performance slowdowns then maybe a different approch should be taken like the other DDC(Softwares)

As it was already told by developers, there is nothing much to do with that perfomance issue whatever it is.
There always will be a cost.

Devs are not familiar with other software, so you can accidently trigger activity after a question, like removing realtime update, bringing down several workflows.

Can you, please, post some gifs from other software as well to clarify the solution you want to propose and avoid interpretations?

> In #68893#876725, @CobraA wrote: > I think it's best to let a Dev answer this kind of questions, My point if this constant live update of smoothing is causing a huge performance slowdowns then maybe a different approch should be taken like the other DDC(Softwares) As it was already told by developers, there is nothing much to do with that perfomance issue whatever it is. There always will be a cost. Devs are not familiar with other software, so you can accidently trigger activity after a question, like removing realtime update, bringing down several workflows. Can you, please, post some gifs from other software as well to clarify the solution you want to propose and avoid interpretations?

In #68893#876826, @brecht wrote:
I think the idea by @CobraA in #68893#876084 is a good one. Autosmooth in general is not something you even want to change as you deform the mesh with modifiers, because then it pops in animation. If you do want it then an explicit edge split modifier should probably be used instead. So replacing autosmooth by a way to update sharp edge tags while in edit mode make sense to me (either manually or perhaps automatic for tools like transform if desired).

This helps with performance, but only in part. Autosmooth involves both detecting which edges are supposed to be smooth, and then computing normals based on that information. So to make it really low overhead, we may also need to reconsider how to store and update the normals.

The problem is that autosmooth update is very workflow dependent feature.
As displayed on example above, it's realtime update is needed for organic modeling process.
Also, in some cases it is acceptable to freeze sharp edges with manual sharpness assigning + split edges modifier, some cases - not.
For instance, in architectural visualization a house with autosmooth may have 1mln vertices, but with edges splitted - about 2 mln, so it can make troubles for scenes with lots of such houses and also exports to other software, so we are using autosmooth for that cases.

For sure, it will be nice to have ability to bake/apply autosmooth normals calculation result without splitting edges (make it static with the ability to revive and edit it with autosmooth sessions, maybe in yavne addon style) or, for instance, the ability to convert autosmooth sharpness result to a sharp edges, and make special smooth mode that will support only assigned sharp edges, but, in general, it feels like a separate, huge and case-dependent task to design.

> In #68893#876826, @brecht wrote: > I think the idea by @CobraA in #68893#876084 is a good one. Autosmooth in general is not something you even want to change as you deform the mesh with modifiers, because then it pops in animation. If you do want it then an explicit edge split modifier should probably be used instead. So replacing autosmooth by a way to update sharp edge tags while in edit mode make sense to me (either manually or perhaps automatic for tools like transform if desired). > > This helps with performance, but only in part. Autosmooth involves both detecting which edges are supposed to be smooth, and then computing normals based on that information. So to make it really low overhead, we may also need to reconsider how to store and update the normals. The problem is that autosmooth update is very workflow dependent feature. As displayed on example above, it's realtime update is needed for organic modeling process. Also, in some cases it is acceptable to freeze sharp edges with manual sharpness assigning + split edges modifier, some cases - not. For instance, in architectural visualization a house with autosmooth may have 1mln vertices, but with edges splitted - about 2 mln, so it can make troubles for scenes with lots of such houses and also exports to other software, so we are using autosmooth for that cases. For sure, it will be nice to have ability to bake/apply autosmooth normals calculation result without splitting edges (make it static with the ability to revive and edit it with autosmooth sessions, maybe in yavne addon style) or, for instance, the ability to convert autosmooth sharpness result to a sharp edges, and make special smooth mode that will support only assigned sharp edges, but, in general, it feels like a separate, huge and case-dependent task to design.

Added subscriber: @AnityEx

Added subscriber: @AnityEx

suggestion:

add a check box called like "live autosmooth" on/off

on= realtime autosmooth (like always)
off= leave it with last autosmooth operation until you press a button again

then make live autosmooth on by default to not break any old file for users

suggestion: add a check box called like "live autosmooth" on/off on= realtime autosmooth (like always) off= leave it with last autosmooth operation until you press a button again then make live autosmooth on by default to not break any old file for users

Such a suggestion is far away from being complete - it is not even explained is it about scene or per object.

Such a suggestion is far away from being complete - it is not even explained is it about scene or per object.

Added subscriber: @MadMinstrel

Added subscriber: @MadMinstrel

I think the live sharp update and normal calculation is an excellent feature for low poly modelling (that is to say virtually all modelling before the model gets complicated), and I wouldn't like to see it go - until you hit the several-thousand-vertices threshold when performance starts to chug anyway.

The edge-split modifier as Brecht proposed would work of course, but it's a non-obvious solution to a problem that doesn't currently exist. Especially to newbies. I'd suggest to keep it working as it is by default, but allow it to be turned off.

I think the live sharp update and normal calculation is an excellent feature for low poly modelling (that is to say virtually all modelling before the model gets complicated), and I wouldn't like to see it go - until you hit the several-thousand-vertices threshold when performance starts to chug anyway. The edge-split modifier as Brecht proposed would work of course, but it's a non-obvious solution to a problem that doesn't currently exist. Especially to newbies. I'd suggest to keep it working as it is by default, but allow it to be turned off.

Added subscriber: @Znio.G

Added subscriber: @Znio.G

I was testing some mechanical rig and it seems that autosmooth impacts the performance greatly, if you disable it you get almost double the FPS back but without it you won't get proper sharp edges.
I think this is a breaking point for Blender as it's not only impactful in modeling but also in animation.
Basically you have to choose between performance or the visuals.
I personally wouldn't use it because of that but maybe it could be baked or a new manual option that doesn't halt peformance to this level.

I was testing some mechanical rig and it seems that autosmooth impacts the performance greatly, if you disable it you get almost double the FPS back but without it you won't get proper sharp edges. I think this is a breaking point for Blender as it's not only impactful in modeling but also in animation. Basically you have to choose between performance or the visuals. I personally wouldn't use it because of that but maybe it could be baked or a new manual option that doesn't halt peformance to this level.
Member

Added subscriber: @HooglyBoogly

Added subscriber: @HooglyBoogly
Member

I wanted to mention #93551 here, since it's very related. I think the changes here and in that task are somewhat compatible, but I do think the idea of moving auto smooth to an operation instead of a setting would be helpful here too.

I wanted to mention #93551 here, since it's very related. I think the changes here and in that task are somewhat compatible, but I do think the idea of moving auto smooth to an operation instead of a setting would be helpful here too.
Philipp Oeser removed the
Interest
Modeling
label 2023-02-09 15:29:38 +01:00
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
11 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#68893
No description provided.