Multires #73317

Closed
opened 2020-01-22 15:53:01 +01:00 by Dalai Felinto · 68 comments

Status: Multires algorithms are implemented, need work on Undo to allow sculpt on non-top level


Team

Commissioner: @PabloDobarro
Project leader: @Sergey
Project members: @brecht

Description
Big picture: Support non-destructive sculpting in different levels of detail for skinned characters preserving a base mesh for baking and animation.

Use cases:

  • Sculptor working in different resolution levels.
  • Animation and playback of base meshes, in fully sculpted characters.

Design:

All the operations (Sculpting, Apply Base, Subdivide, propagation) should be using the same tangent space of the base mesh. This way there will be no inducted artifacts caused by differences between the way how old algorithms were calculating tangent space and how it's happening in the new subdivision surface code.

Propagation should be using Catmull-Clark smoothing of sculpted mesh and propagate changes to the top level.

Engineer plan:

  • Memory/performance optimization
  • Enable optimal display by default in subsurf and multires modifiers
  • Don't allow editing Quality after subdivision is done
  • Don't allow editing simple/catmull-clark and quality after subdivision is done
  • Remove simple mode, and replace with a way to apply simple subdivision as an operation (modifying multires or a base mesh)
  • Fix undo bugs for switching between multires levels
  • Re-enable editing of intermediate sculpt levels
  • Always auto apply base when sculpting, instead of having a button for it
  • Investigate if propagation is need for edits in edit mode
  • Investigate how to support "Apply Base" for meshes with shapekeys

Work plan

Time estimate: 1 month


Relevant links:

  • studio/blender-studio#58473 (Multires: changes not smoothly propagated from low to high, for example with apply base)
  • #76769 (MultiRes cannot "Apply Base" when ShapeKey have been added)
  • #73047 (Sculpt Mode Multires Design)
**Status:** Multires algorithms are implemented, need work on Undo to allow sculpt on non-top level --- **Team** **Commissioner:** @PabloDobarro **Project leader:** @Sergey **Project members:** @brecht **Description** **Big picture:** Support non-destructive sculpting in different levels of detail for skinned characters preserving a base mesh for baking and animation. **Use cases**: * Sculptor working in different resolution levels. * Animation and playback of base meshes, in fully sculpted characters. **Design:** All the operations (Sculpting, Apply Base, Subdivide, propagation) should be using the same tangent space of the base mesh. This way there will be no inducted artifacts caused by differences between the way how old algorithms were calculating tangent space and how it's happening in the new subdivision surface code. Propagation should be using Catmull-Clark smoothing of sculpted mesh and propagate changes to the top level. **Engineer plan:** - [ ] Memory/performance optimization - [x] Enable optimal display by default in subsurf and multires modifiers - [x] Don't allow editing Quality after subdivision is done - [x] Don't allow editing simple/catmull-clark and quality after subdivision is done - [ ] Remove simple mode, and replace with a way to apply simple subdivision as an operation (modifying multires or a base mesh) - [ ] Fix undo bugs for switching between multires levels - [ ] Re-enable editing of intermediate sculpt levels - [x] Always auto apply base when sculpting, instead of having a button for it - [ ] Investigate if propagation is need for edits in edit mode - [ ] Investigate how to support "Apply Base" for meshes with shapekeys **Work plan** **Time estimate:** 1 month --- **Relevant links**: * studio/blender-studio#58473 (Multires: changes not smoothly propagated from low to high, for example with apply base) * #76769 (MultiRes cannot "Apply Base" when ShapeKey have been added) * #73047 (Sculpt Mode Multires Design)
Sergey Sharybin was assigned by Dalai Felinto 2020-01-22 15:53:01 +01:00
Author
Owner

Added subscribers: @PabloDobarro, @Sergey, @brecht, @dfelinto

Added subscribers: @PabloDobarro, @Sergey, @brecht, @dfelinto

Added subscriber: @unumex-4

Added subscriber: @unumex-4

Added subscriber: @616

Added subscriber: @616

Added subscriber: @Andruxa696

Added subscriber: @Andruxa696

Added subscriber: @Teds

Added subscriber: @Teds

Added subscriber: @BartekMoniewski

Added subscriber: @BartekMoniewski

Added subscriber: @AlbertoVelazquez

Added subscriber: @AlbertoVelazquez

Added subscriber: @vr_sebas

Added subscriber: @vr_sebas

Added subscriber: @kfir

Added subscriber: @kfir
Member

Added subscriber: @JulienKaspar

Added subscriber: @JulienKaspar

Added subscriber: @AditiaA.Pratama

Added subscriber: @AditiaA.Pratama

Added subscriber: @ucupumar

Added subscriber: @ucupumar

Added subscriber: @Pipeliner

Added subscriber: @Pipeliner

Added subscriber: @SpectreFirst

Added subscriber: @SpectreFirst
Member

Changed status from 'Needs Triage' to: 'Confirmed'

Changed status from 'Needs Triage' to: 'Confirmed'

Added subscriber: @dlc17

Added subscriber: @dlc17

Added subscriber: @alfredbaudisch

Added subscriber: @alfredbaudisch

Added subscriber: @ckohl_art

Added subscriber: @ckohl_art

Added subscriber: @martinium

Added subscriber: @martinium

Removed subscriber: @martinium

Removed subscriber: @martinium

Added subscriber: @martinium

Added subscriber: @martinium

Added subscriber: @item412

Added subscriber: @item412

Added subscriber: @PetterLundh

Added subscriber: @PetterLundh
Contributor

Added subscriber: @aryeramaty

Added subscriber: @aryeramaty

Added subscriber: @YegorSmirnov

Added subscriber: @YegorSmirnov

Added subscriber: @sid350

Added subscriber: @sid350

Added subscriber: @kosirm-2

Added subscriber: @kosirm-2

Added subscriber: @wevon-2

Added subscriber: @wevon-2

I was going to post a bug but it is already solved. In version 2.82 a vertex with 2 egdes generated a hole when deforming with Subsurf, but not with Multires.
When trying to report this error I have noticed that in version 2.83 the same model is not smoothed in the same way with Subsurf as in Multires. I thought the algorithm was the same.
I upload the file in case you want to investigate.
Bug.png
Bug2.png
Bug.blend

I was going to post a bug but it is already solved. In version 2.82 a vertex with 2 egdes generated a hole when deforming with Subsurf, but not with Multires. When trying to report this error I have noticed that in version 2.83 the same model is not smoothed in the same way with Subsurf as in Multires. I thought the algorithm was the same. I upload the file in case you want to investigate. ![Bug.png](https://archive.blender.org/developer/F8414553/Bug.png) ![Bug2.png](https://archive.blender.org/developer/F8414555/Bug2.png) [Bug.blend](https://archive.blender.org/developer/F8414559/Bug.blend)

Multires = Subsurf Modifier + displacement. So in this regard yes, the subdivision algorithm is exactly the same, and it works on the same input mesh.

The tricky part is that "Subdivide" button on multires modifier is intended to preserve all details, and keep them smooth. This is done by applying subdivision surface on the currently top level you are subdividing from. This generates nice smooth displacement (there is an extra step is involved to have the new smooth displacement to work from the original multires base mesh, but that's details).

You can think of it as if you temporary add subsurf modifier with subdivision level one and then "merge" it into the multires modifier.
So algorithm is not the same since the endgoal of it is different.

Multires = Subsurf Modifier + displacement. So in this regard yes, the subdivision algorithm is exactly the same, and it works on the same input mesh. The tricky part is that "Subdivide" button on multires modifier is intended to preserve all details, and keep them smooth. This is done by applying subdivision surface on the currently top level you are subdividing from. This generates nice smooth displacement (there is an extra step is involved to have the new smooth displacement to work from the original multires base mesh, but that's details). You can think of it as if you temporary add subsurf modifier with subdivision level one and then "merge" it into the multires modifier. So algorithm is not the same since the endgoal of it is different.

You can think of it as if you temporary add subsurf modifier with subdivision level one and then "merge" it into the multires modifier.

True. If the quality parameters are the same, the two meshes coincide, when applying each step of the subdivision. Thanks for the explanation.

> You can think of it as if you temporary add subsurf modifier with subdivision level one and then "merge" it into the multires modifier. True. If the quality parameters are the same, the two meshes coincide, when applying each step of the subdivision. Thanks for the explanation.
Member

Some notes about the engineering plan:

  • I think we should focus on having the unsubdivide operator available as soon as possible when working on the development of sculpting across multiple levels. The issue is that we almost have no production Blender files sculpted from start to finish in Multies, so we can't really validate if the propagation is working as it should in real use cases. With unsubdivide, we can import high poly sculpted meshes with surface detail that were subdivided in any other sculpting software and rebuild all levels inside Blender Multires. Also, once we are able to import sculpting projects, we can evaluate a lot better what is the status of the sculpting system in general (can that file be edited without lag, does it work with a reasonable amount of memory, how much time does it take to switch between modes...)
  • I would left all Shape Keys related features for later after we have a more clear design for Multires sculpting layers in #68898. Shape Keys and sculpt layers are fundamentally the same concept, so maybe we can solve those problem with a conversion operator from a shape key to a sculpt layer instead of adding more complexity to Multires to be able to work with shape keys directly.
Some notes about the engineering plan: - I think we should focus on having the unsubdivide operator available as soon as possible when working on the development of sculpting across multiple levels. The issue is that we almost have no production Blender files sculpted from start to finish in Multies, so we can't really validate if the propagation is working as it should in real use cases. With unsubdivide, we can import high poly sculpted meshes with surface detail that were subdivided in any other sculpting software and rebuild all levels inside Blender Multires. Also, once we are able to import sculpting projects, we can evaluate a lot better what is the status of the sculpting system in general (can that file be edited without lag, does it work with a reasonable amount of memory, how much time does it take to switch between modes...) - I would left all Shape Keys related features for later after we have a more clear design for Multires sculpting layers in #68898. Shape Keys and sculpt layers are fundamentally the same concept, so maybe we can solve those problem with a conversion operator from a shape key to a sculpt layer instead of adding more complexity to Multires to be able to work with shape keys directly.

The list isn't really in order. Is more like a set of things to be tackled to cut off all the loose ends.
Extra features can surely be added, but this can happen as regular development and not necessarily by me. We can have a separate task with a wider look and roadmap of features we want and plan to implement.

The list isn't really in order. Is more like a set of things to be tackled to cut off all the loose ends. Extra features can surely be added, but this can happen as regular development and not necessarily by me. We can have a separate task with a wider look and roadmap of features we want and plan to implement.

For importing sculpts, you may be able to export a base mesh and vector displacement map in another app. The add a subdivision modifier, displacement modifier RGB to XYZ, and reshape.

For importing sculpts, you may be able to export a base mesh and vector displacement map in another app. The add a subdivision modifier, displacement modifier RGB to XYZ, and reshape.
Member

But for that you need UVs in all objects of the model, and probably not all high poly meshes have UVs inside of the sculpting software if they were intended to be baked in another software (basically, all models made for game assets). I think we should try to make the importing process as straightforward as possible to get as many reports from users with production files as we can before the release.

But for that you need UVs in all objects of the model, and probably not all high poly meshes have UVs inside of the sculpting software if they were intended to be baked in another software (basically, all models made for game assets). I think we should try to make the importing process as straightforward as possible to get as many reports from users with production files as we can before the release.

Is there any particular reason for removing Apply Base? This can be very problematic since Blender lost its ability to bake displacement maps from two different objects and the only way to bake a displacement map right now is to use "Bake from Multires": when you, for example, baking a height map for a landscape, you need the difference between an initial flat plane and a final landscape but with Apply Base permanently applied you will only get the difference between the lowpoly version and highpoly version which is not suitable for landscape heightmaps. The same problem can arise with characters – you may need to get the difference between an initial model without deformations and a sculpted one, Multires can also be used for small touch-ups on a static model without deforming an initial mesh so unless there are very good reasons for removing that option I think it should be left as it is or at the very least there must be an option somewhere like “Apply Base by default”.

Is there any particular reason for removing Apply Base? This can be very problematic since Blender lost its ability to bake displacement maps from two different objects and the only way to bake a displacement map right now is to use "Bake from Multires": when you, for example, baking a height map for a landscape, you need the difference between an initial flat plane and a final landscape but with Apply Base permanently applied you will only get the difference between the lowpoly version and highpoly version which is not suitable for landscape heightmaps. The same problem can arise with characters – you may need to get the difference between an initial model without deformations and a sculpted one, Multires can also be used for small touch-ups on a static model without deforming an initial mesh so unless there are very good reasons for removing that option I think it should be left as it is or at the very least there must be an option somewhere like “Apply Base by default”.

Added subscriber: @pawel.palenica

Added subscriber: @pawel.palenica

@SpectreFirst, There are two things here I guess.

First, the displacement baking is to be brought back.

Second, I also not sure completely loosing ability to sculpt on multires without affecting base mesh is the way to go. Just need to find a way to allow both workflows in a non-confusing manner.

@SpectreFirst, There are two things here I guess. First, the displacement baking is to be brought back. Second, I also not sure completely loosing ability to sculpt on multires without affecting base mesh is the way to go. Just need to find a way to allow both workflows in a non-confusing manner.

Added subscriber: @Frozen_Death_Knight

Added subscriber: @Frozen_Death_Knight

@SpectreFirst The reason why it needs to always be automatic is because it is a giant time waster for people who actually work on sculpts. Coming from ZBrush it is incredibly jarring that the 0 subdivs mesh is not reflecting the changes done on the higher subdivs, especially when the entire point of a subdiv system is to quickly jump from subdiv to subdiv, often to the lowest subdiv, and make the necessary adjustments. When it is done automatically, you don't have to think much about moving an arm or a leg to a certain position and how it will look in higher subdivs, but with the manual approach you always have to Apply Base when having done major changes so that the placements of your limbs and other body parts reflect on the original model. Especially with the improvements done to the Pose brush it is crucial that the 0 subdiv model is always in sync with the other subdivs.

Even with the improved MultiRes no longer breaking like the old one it still isn't up to the standards that professional sculpting tools provide like ZBrush because of design decisions like Apply Base. Displacement map baking can be added to solve your problem, but for sculptors we can't compromise on this feature since we need it to work efficiently. If the devs somehow can provide automatic (default) Apply Base and the manual (non-default) Apply Base without any issues, then fine, but if they can't, then the manual approach has to go. MultiRes is primarily a tool for sculptors and should be designed as such. I would much prefer if MultiRes got split into two separate modifiers with automatic and manual Apply Base if you have any intentions of keeping the latter.

@SpectreFirst The reason why it needs to always be automatic is because it is a giant time waster for people who actually work on sculpts. Coming from ZBrush it is incredibly jarring that the 0 subdivs mesh is not reflecting the changes done on the higher subdivs, especially when the entire point of a subdiv system is to quickly jump from subdiv to subdiv, often to the lowest subdiv, and make the necessary adjustments. When it is done automatically, you don't have to think much about moving an arm or a leg to a certain position and how it will look in higher subdivs, but with the manual approach you always have to Apply Base when having done major changes so that the placements of your limbs and other body parts reflect on the original model. Especially with the improvements done to the Pose brush it is crucial that the 0 subdiv model is always in sync with the other subdivs. Even with the improved MultiRes no longer breaking like the old one it still isn't up to the standards that professional sculpting tools provide like ZBrush because of design decisions like Apply Base. Displacement map baking can be added to solve your problem, but for sculptors we can't compromise on this feature since we need it to work efficiently. If the devs somehow can provide automatic (default) Apply Base and the manual (non-default) Apply Base without any issues, then fine, but if they can't, then the manual approach has to go. MultiRes is primarily a tool for sculptors and should be designed as such. I would much prefer if MultiRes got split into two separate modifiers with automatic and manual Apply Base if you have any intentions of keeping the latter.

Added subscriber: @ClinToch

Added subscriber: @ClinToch

Added subscriber: @DirSurya

Added subscriber: @DirSurya
Member

Added subscriber: @DanielBystedt

Added subscriber: @DanielBystedt

Added subscriber: @DanieleViagi

Added subscriber: @DanieleViagi

In #73317#900955, @Frozen_Death_Knight wrote:
@SpectreFirst The reason why it needs to always be automatic is because it is a giant time waster for people who actually work on sculpts. Coming from ZBrush it is incredibly jarring that the 0 subdivs mesh is not reflecting the changes done in the higher subdivs, especially when the entire point of a subdiv system is to quickly jump from subdiv to subdiv, often to the lowest subdiv, and make the necessary adjustments. When it is done automatically, you don't have to think much about moving an arm or a leg to a certain position and how it will look in higher subdivs, but with the manual approach you always have to Apply Base when having done major changes so that the placements of your limbs and other body parts reflect on the original model. Especially with the improvements done to the Pose brush it is crucial that the 0 subdiv model is always in sync with the other subdivs.

Even with the improved MultiRes no longer breaking like the old one it still isn't up to the standards that professional sculpting tools provide like ZBrush because of design decisions like Apply Base. Displacement map baking can be added to solve your problem, but for sculptors we can't compromise on this feature since we need it to work efficiently. If the devs somehow can provide automatic (default) Apply Base and the manual (non-default) Apply Base without any issues, then fine, but if they can't, then the manual approach has to go. MultiRes is primarily a tool for sculptors and should be designed as such. I would much prefer if MultiRes got split into two separate modifiers with automatic and manual Apply Base if you have any intentions of keeping the latter.

I totally agree, apply base should be default behavior, or at least an activatable checkbox option in the multires modifier.

> In #73317#900955, @Frozen_Death_Knight wrote: > @SpectreFirst The reason why it needs to always be automatic is because it is a giant time waster for people who actually work on sculpts. Coming from ZBrush it is incredibly jarring that the 0 subdivs mesh is not reflecting the changes done in the higher subdivs, especially when the entire point of a subdiv system is to quickly jump from subdiv to subdiv, often to the lowest subdiv, and make the necessary adjustments. When it is done automatically, you don't have to think much about moving an arm or a leg to a certain position and how it will look in higher subdivs, but with the manual approach you always have to Apply Base when having done major changes so that the placements of your limbs and other body parts reflect on the original model. Especially with the improvements done to the Pose brush it is crucial that the 0 subdiv model is always in sync with the other subdivs. > > Even with the improved MultiRes no longer breaking like the old one it still isn't up to the standards that professional sculpting tools provide like ZBrush because of design decisions like Apply Base. Displacement map baking can be added to solve your problem, but for sculptors we can't compromise on this feature since we need it to work efficiently. If the devs somehow can provide automatic (default) Apply Base and the manual (non-default) Apply Base without any issues, then fine, but if they can't, then the manual approach has to go. MultiRes is primarily a tool for sculptors and should be designed as such. I would much prefer if MultiRes got split into two separate modifiers with automatic and manual Apply Base if you have any intentions of keeping the latter. I totally agree, apply base should be default behavior, or at least an activatable checkbox option in the multires modifier.

Added subscriber: @KidTempo

Added subscriber: @KidTempo

Added subscriber: @DarkKnight

Added subscriber: @DarkKnight

Added subscriber: @Regnas

Added subscriber: @Regnas

No "Delete Lower" movement here? 👀

No "Delete Lower" movement here? 👀

Permanently applied base is a great way to permanently destroy your model because if you'll sculpt on a Multires and remove the modifier later your mesh will stay permanently deformed and there will be no way to restore it to its original state. Only a handful of people actually need this because in my experience most people never even use the “Apply Base” button, if you need to pose something you can just press the button once in a while and again, if something goes wrong you can just remove the modifier and apply it again. Applying base into a shape key would be a possible solution but as far as I can see, Multires cannot do that yet.

Permanently applied base is a great way to permanently destroy your model because if you'll sculpt on a Multires and remove the modifier later your mesh will stay permanently deformed and there will be no way to restore it to its original state. Only a handful of people actually need this because in my experience most people never even use the “Apply Base” button, if you need to pose something you can just press the button once in a while and again, if something goes wrong you can just remove the modifier and apply it again. Applying base into a shape key would be a possible solution but as far as I can see, Multires cannot do that yet.

In #73317#940272, @SpectreFirst wrote:
Permanently applied base is a great way to permanently destroy your model because if you'll sculpt on a Multires and remove the modifier later your mesh will stay permanently deformed and there will be no way to restore it to its original state. Only a handful of people actually need this because in my experience most people never even use the “Apply Base” button

True. Aren't modifiers designed for non-destructive workflow? This point is right there in the description of the task.

> In #73317#940272, @SpectreFirst wrote: > Permanently applied base is a great way to permanently destroy your model because if you'll sculpt on a Multires and remove the modifier later your mesh will stay permanently deformed and there will be no way to restore it to its original state. Only a handful of people actually need this because in my experience most people never even use the “Apply Base” button True. Aren't modifiers designed for non-destructive workflow? This point is right there in the description of the task.

Perhaps the easiest way to deal with Apply Base is to turn it into a checkbox "Automatically Apply Base" that will let you apply Multires, manually check it and start working, checkbox will also inform you that everything you do will be permanent on a base level.

Perhaps the easiest way to deal with Apply Base is to turn it into a checkbox "Automatically Apply Base" that will let you apply Multires, manually check it and start working, checkbox will also inform you that everything you do will be permanent on a base level.
Member

I suggest a

  • checkbox for "auto update base" (BoolProperty)

  • drop down menu (EnumProperty) for choosing either
    1. Apply base ("cage" workflow where base (subdiv 0) resembles shape of high res sculpt when subdiv is applied.)
    2. Fit base (workflow where base (subdiv 0) is resembling the shape of the highres sculpt. This is the best workflow when creating realtime/game assets.

  • Keep the button/operator for "Apply base", but rename the label to "Update base"

I suggest a - checkbox for "auto update base" (BoolProperty) - drop down menu (EnumProperty) for choosing either 1. Apply base ("cage" workflow where base (subdiv 0) resembles shape of high res sculpt when subdiv is applied.) 2. Fit base (workflow where base (subdiv 0) is resembling the shape of the highres sculpt. This is the best workflow when creating realtime/game assets. - Keep the button/operator for "Apply base", but rename the label to "Update base"

@Regnas Its currently waiting for review. Here: https://developer.blender.org/D7582

And yes auto update base should be optional to be automatic.

@Regnas Its currently waiting for review. Here: https://developer.blender.org/D7582 And yes auto update base should be optional to be automatic.

Added subscriber: @NanoGlyph

Added subscriber: @NanoGlyph

The problem with automatic Apply Base for me is if I remove the modifier and replace with subdivision, the result is noticeably different (a bit inflated) if Apply Base has been used, even without any other modifications to any part of the model. Would automatic Apply Base work differently than the current Apply Base beyond being automatic? I don't want my entire mesh permanently deformed I before I've even start sculpting just because Multires is in the modifier stack. I'd also like it if only areas that have been sculpted are modified by Apply Base.

The problem with automatic Apply Base for me is if I remove the modifier and replace with subdivision, the result is noticeably different (a bit inflated) if Apply Base has been used, even without any other modifications to any part of the model. Would automatic Apply Base work differently than the current Apply Base beyond being automatic? I don't want my entire mesh permanently deformed I before I've even start sculpting just because Multires is in the modifier stack. I'd also like it if only areas that have been sculpted are modified by Apply Base.

Added subscriber: @ErickNyanduKabongo

Added subscriber: @ErickNyanduKabongo

Added subscriber: @Quargzon

Added subscriber: @Quargzon

Added subscriber: @Cyberart

Added subscriber: @Cyberart

Added subscriber: @pauanyu_blender

Added subscriber: @pauanyu_blender

Added subscriber: @mcolinp

Added subscriber: @mcolinp

Added subscriber: @WCN

Added subscriber: @WCN

Added subscriber: @JohanTriHandoyo

Added subscriber: @JohanTriHandoyo

Added subscriber: @skarkkai

Added subscriber: @skarkkai

This comment was removed by @wevon-2

*This comment was removed by @wevon-2*

@wevon-2, The issue you're describing is not related to a planning task for Multires. Please submit a bug report with all the information requested in the submission form.

@wevon-2, The issue you're describing is not related to a planning task for Multires. Please submit a bug report with all the information requested in the submission form.

Changed status from 'Confirmed' to: 'Resolved'

Changed status from 'Confirmed' to: 'Resolved'

I've been working on a different projects, and a lot of things got fixed/changed/improved for sculpting+multires at the meantime.
Suggest calling this one a wrap-up, and handle the remaining parts as a regular module work and bugfixes.

I've been working on a different projects, and a lot of things got fixed/changed/improved for sculpting+multires at the meantime. Suggest calling this one a wrap-up, and handle the remaining parts as a regular module work and bugfixes.
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
47 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#73317
No description provided.