Sculpt: Add stroke stabilization to lasso tools #122062

Merged
Sean Kim merged 12 commits from Sean-Kim/blender:lasso-stabilize into main 2024-06-27 01:32:26 +02:00
Member

This PR adds stroke stabilization settings for the Sculpt mode lasso tools:

  • Mask
  • Hide
  • Trim
  • Face Set

Only Sculpt tools have a user facing change, even though this was implemented in WM_gesture_lasso_modal and related methods. Other modes may choose to add these settings and toggles.

stabilize_lasso_v4.gif

Implementation

The implemented functionality is similar to the Annotate tool in both interpolation of the new point and drawing the UI hint that stabilization is happening.

The radius and factor properties have similar bounds as the same Brush properties. All values are stored on a per-operator level, not on a scene or otherwise global tool level.

Revision History

  • Removed Shift-S keybind for toggling the stabilization - will be added in a future patch after more design questions are ironed out.
  • Fixed factor calculation

Part of #80390

Based off of this RCS request.

This PR adds stroke stabilization settings for the Sculpt mode lasso tools: * Mask * Hide * Trim * Face Set Only Sculpt tools have a user facing change, even though this was implemented in `WM_gesture_lasso_modal` and related methods. Other modes may choose to add these settings and toggles. ![stabilize_lasso_v4.gif](/attachments/c1c1c5a9-b553-435d-8030-57c764600bbc) ## Implementation The implemented functionality is similar to the Annotate tool in both interpolation of the new point and drawing the UI hint that stabilization is happening. The `radius` and `factor` properties have similar bounds as the same Brush properties. All values are stored on a per-operator level, not on a scene or otherwise global tool level. ## Revision History * Removed Shift-S keybind for toggling the stabilization - will be added in a future patch after more design questions are ironed out. * Fixed `factor` calculation Part of #80390 Based off of [this RCS request](https://blender.community/c/rightclickselect/ZWG5/).
Sean Kim added this to the Sculpt, Paint & Texture project 2024-05-21 19:20:38 +02:00
Sean Kim reviewed 2024-05-29 08:25:18 +02:00
@ -510,6 +510,7 @@ class WM_OT_context_toggle(Operator):
return {'PASS_THROUGH'}
exec("base.{:s} = not (base.{:s})".format(data_path, data_path))
context.area.tag_redraw()
Author
Member

I don't know if there's a more appropriate way of achieving what this line does - without this, after Shift-S is pressed, the value in the header does not update until the cursor moves over the toolbar or outside of Blender's window.

I don't know if there's a more appropriate way of achieving what this line does - without this, after `Shift-S` is pressed, the value in the header does not update until the cursor moves over the toolbar or outside of Blender's window.

This looks like a bug that should be fixed elsewhere.

Could you report this? (it looks like it should be possible to redo without the patch).

This looks like a bug that should be fixed elsewhere. Could you report this? (it looks like it should be possible to redo without the patch).
Author
Member

When I was doing some testing, this only seemed to occur specifically for the new use_smooth_stroke property on the operator. I couldn't replicate this for a handful of WM_OT_context_toggle entries I tried. I'll do a bit more testing and see if I can replicate it on something other than this new functionality.

When I was doing some testing, this only seemed to occur specifically for the new `use_smooth_stroke` property on the operator. I couldn't replicate this for a handful of `WM_OT_context_toggle` entries I tried. I'll do a bit more testing and see if I can replicate it on something other than this new functionality.
Sean-Kim marked this conversation as resolved
Author
Member

I'm planning on extracting the bpy_types.py and wm.py changes to a separate PR / commit, since it's more core functionality and shouldn't be bundled with this, but I think the context of the larger change is valuable for seeing how it would be used.

I'm planning on extracting the `bpy_types.py` and `wm.py` changes to a separate PR / commit, since it's more core functionality and shouldn't be bundled with this, but I think the context of the larger change is valuable for seeing how it would be used.
Sean Kim changed title from WIP: Sculpt: Add stroke stabilization to lasso tools to Sculpt: Add stroke stabilization to lasso tools 2024-05-29 08:27:51 +02:00
Sean Kim requested review from Campbell Barton 2024-05-29 08:27:59 +02:00
Sean Kim requested review from Hans Goudey 2024-05-29 08:28:06 +02:00
Sean Kim requested review from Daniel Bystedt 2024-05-29 08:28:11 +02:00
Author
Member

@blender-bot package

@blender-bot package
Member

Package build started. Download here when ready.

Package build started. [Download here](https://builder.blender.org/download/patch/PR122062) when ready.
Author
Member

Only just noticed that the build failed, Looking into the test failures now...

Only just noticed that the build failed, Looking into the test failures now...
Sean Kim force-pushed lasso-stabilize from 7ca99c0147 to 9d1271965f 2024-05-30 02:16:36 +02:00 Compare
Author
Member

@blender-bot package

@blender-bot package
Member

Package build started. Download here when ready.

Package build started. [Download here](https://builder.blender.org/download/patch/PR122062) when ready.
Campbell Barton requested changes 2024-05-30 04:31:48 +02:00
@ -108,0 +122,4 @@
cls = ToolSelectPanelHelper._tool_class_from_space_type(space_type)
_, tool, _ = cls._tool_get_active(self, space_type, mode, with_icon=False)
class TempMappable:

This is based on some sample code of mine but was meant to show this is possible.

I don't think the TempMappable class is acceptable in it's current form and having a mappable type workaround WM_OT_context_* inability to include function calls in data paths is inherently awkward.

One issue is the mappable type has no length/keys/value which is typically expected for a dictionary like Python object.
Further, passing in any operator will work, it just creates the operator properties on demand. Failure to create operator properties (if key is an integer for example) should raise a KeyError.

This part of the PR is more of a design task and could be a PR on it's own because the functionality raises quite a few questions.

  • How to handle accessor types, try to make them more "complete" or document as a workaround which only supports __getitem__.
  • Could the mapping type be limited to operator the tool uses? (allowing at least __len__ keys() to be implemented).
  • Would we have the same functionality for gizmo_group_properties?
This is based on some sample code of mine but was meant to show this is possible. I don't think the `TempMappable` class is acceptable in it's current form and having a mappable type workaround `WM_OT_context_*` inability to include function calls in data paths is inherently awkward. One issue is the mappable type has no length/keys/value which is typically expected for a dictionary like Python object. Further, passing in any operator will work, it just creates the operator properties on demand. Failure to create operator properties (if `key` is an integer for example) should raise a `KeyError`. This part of the PR is more of a design task and could be a PR on it's own because the functionality raises quite a few questions. - How to handle accessor types, try to make them more "complete" or document as a workaround which only supports `__getitem__`. - Could the mapping type be limited to operator the tool uses? (allowing at least `__len__` `keys()` to be implemented). - Would we have the same functionality for `gizmo_group_properties`?
Author
Member

I can spin off a separate design task for the points you've listed here. I appreciate the feedback on the next steps for it. For this to be in a shippable state, do you think the only areas that need to be addressed are the dictionary-like attributes & the handling of keys correctly, or are the remaining three bullet points something that should be handled before any of this is committed?

I can spin off a separate design task for the points you've listed here. I appreciate the feedback on the next steps for it. For this to be in a shippable state, do you think the only areas that need to be addressed are the dictionary-like attributes & the handling of keys correctly, or are the remaining three bullet points something that should be handled before any of this is committed?
Author
Member

I created a design task here: #122521 with the points you've brought up & removed the sample code from this PR.

I created a design task here: https://projects.blender.org/blender/blender/issues/122521 with the points you've brought up & removed the sample code from this PR.
Sean-Kim marked this conversation as resolved
@ -595,2 +595,4 @@
/** Optional, draw the active side of the straight-line gesture. */
bool draw_active_side;
/** Latest mouse position relative to area. */
blender::float2 current_mouse_position;

It looks like this is part of a refactor to remove use of gesture->winrct, is this needed for the PR or is it a more general refactor?


This is only used by the lasso gesture, the doc-string should note this.


Region relative pointer coordinates are typically called mval (this is historic) but at least makes it clear when region/window relative coordinates are mixed incorrectly.

These coordinates are also typically stored a int's, blender::int2 mval;

It looks like this is part of a refactor to remove use of `gesture->winrct`, is this needed for the PR or is it a more general refactor? --- This is only used by the lasso gesture, the doc-string should note this. --- Region relative pointer coordinates are typically called `mval` (this is historic) but at least makes it clear when region/window relative coordinates are mixed incorrectly. These coordinates are also typically stored a int's, `blender::int2 mval;`
Author
Member

This is needed inside draw_lasso_smooth_stroke_indicator for the current mouse position, as we don't have a handle to the wmEvent in the wm_gesture_draw_* methods to get the current mouse position, I didn't see a way to access it from the top level wm_gesture_draw function via wmWindow either. As for it's usage across the operators, it would make some code in the wm_operator_polyline code cleaner too, as it was needed in that draw function too, I just found a way around it when implementing those methods.

This is needed inside `draw_lasso_smooth_stroke_indicator` for the current mouse position, as we don't have a handle to the `wmEvent` in the `wm_gesture_draw_*` methods to get the current mouse position, I didn't see a way to access it from the top level `wm_gesture_draw` function via `wmWindow` either. As for it's usage across the operators, it would make some code in the `wm_operator_polyline` code cleaner too, as it was needed in that draw function too, I just found a way around it when implementing those methods.
Sean Kim added 1 commit 2024-05-31 01:20:36 +02:00
Sean Kim added 1 commit 2024-05-31 02:40:53 +02:00
Rename variable and change to int2
All checks were successful
buildbot/vexp-code-patch-darwin-x86_64 Build done.
buildbot/vexp-code-patch-darwin-arm64 Build done.
buildbot/vexp-code-patch-lint Build done.
buildbot/vexp-code-patch-linux-x86_64 Build done.
buildbot/vexp-code-patch-windows-amd64 Build done.
buildbot/vexp-code-patch-coordinator Build done.
544114aa54
Author
Member

@blender-bot package

@blender-bot package
Member

Package build started. Download here when ready.

Package build started. [Download here](https://builder.blender.org/download/patch/PR122062) when ready.
Sean Kim requested review from Campbell Barton 2024-05-31 02:44:42 +02:00
Daniel Bystedt approved these changes 2024-06-01 01:27:05 +02:00
Dismissed
Daniel Bystedt left a comment
Member

Works with and without multires modifier. Thanks for the PR! :-)

Works with and without multires modifier. Thanks for the PR! :-)
First-time contributor

Great functionality... 👍

Quick question tho... Did a quick test and I noticed some "stepping" on the stroke, specially on higher radius value...

image

Is there a way to have a smoother stroke when using higher radius value? I guess that's the job of the factor slider? But even at the lowest value there's still some "stepping" on the stroke...

By the way, the factor slider's tooltip says "higher values gives a smoother stroke", but it kinda works the opposite, lower values are giving me a smoother stroke (less stepping).. 🤔

Great functionality... 👍 Quick question tho... Did a quick test and I noticed some "stepping" on the stroke, specially on higher radius value... ![image](/attachments/31fd7f58-7f8b-47cc-8817-66eda05a8e18) Is there a way to have a smoother stroke when using higher radius value? I guess that's the job of the factor slider? But even at the lowest value there's still some "stepping" on the stroke... By the way, the factor slider's tooltip says "higher values gives a smoother stroke", but it kinda works the opposite, lower values are giving me a smoother stroke (less stepping).. 🤔
Author
Member

Great functionality... 👍

Quick question tho... Did a quick test and I noticed some "stepping" on the stroke, specially on higher radius value...

Is there a way to have a smoother stroke when using higher radius value? I guess that's the job of the factor slider? But even at the lowest value there's still some "stepping" on the stroke...

By the way, the factor slider's tooltip says "higher values gives a smoother stroke", but it kinda works the opposite, lower values are giving me a smoother stroke (less stepping).. 🤔

Ah, I've found the issue here, thanks for reporting it. The core issue is the factor not working as intended.

> Great functionality... 👍 > > Quick question tho... Did a quick test and I noticed some "stepping" on the stroke, specially on higher radius value... > > Is there a way to have a smoother stroke when using higher radius value? I guess that's the job of the factor slider? But even at the lowest value there's still some "stepping" on the stroke... > > By the way, the factor slider's tooltip says "higher values gives a smoother stroke", but it kinda works the opposite, lower values are giving me a smoother stroke (less stepping).. 🤔 Ah, I've found the issue here, thanks for reporting it. The core issue is the factor not working as intended.
Author
Member

Though, fixing the factor calculation seems to expose a deeper issue when using high values (> 0.9), at the moment I think the gist of the problem is that everything is translated back down into short, losing fractional precision for the next resulting entry. This might need to go back to the drawing board for a bit since changing the underlying type is a fairly wide-reaching change.

Though, fixing the factor calculation seems to expose a deeper issue when using high values (> 0.9), at the moment I think the gist of the problem is that everything is translated back down into `short`, losing fractional precision for the next resulting entry. This might need to go back to the drawing board for a bit since changing the underlying type is a fairly wide-reaching change.
First-time contributor

@Sean-Kim Alright, thank you...
This issue is not super critical by the way... this PR is fine as it is.. 👍

@Sean-Kim Alright, thank you... This issue is not super critical by the way... this PR is fine as it is.. 👍
Sean Kim added 1 commit 2024-06-03 23:13:46 +02:00
Fix factor application in algorithm
All checks were successful
buildbot/vexp-code-patch-lint Build done.
buildbot/vexp-code-patch-darwin-x86_64 Build done.
buildbot/vexp-code-patch-darwin-arm64 Build done.
buildbot/vexp-code-patch-linux-x86_64 Build done.
buildbot/vexp-code-patch-windows-amd64 Build done.
buildbot/vexp-code-patch-coordinator Build done.
308742e8fa
Requires updating internal type from short to float for the point array,
the RNA value was always float so this should have no unwanted side
effects
Author
Member

@blender-bot package

@blender-bot package
Member

Package build started. Download here when ready.

Package build started. [Download here](https://builder.blender.org/download/patch/PR122062) when ready.
Sean Kim reviewed 2024-06-03 23:24:52 +02:00
@ -76,3 +76,2 @@
gesture->points_alloc = 1024;
gesture->customdata = lasso = static_cast<short int *>(
MEM_mallocN(sizeof(short[2]) * gesture->points_alloc, "lasso points"));
gesture->customdata = lasso = static_cast<float *>(
Author
Member

I'm not sure if this change is too wide-reaching to be included as part of this single PR, I included it here since it shouldn't have any external implications as the RNA loc property on the operator is already stored as float and not short or int. If there are concerns with bundling this change inside this PR, I can extract it to a separate one.

I'm not sure if this change is too wide-reaching to be included as part of this single PR, I included it here since it shouldn't have any external implications as the RNA `loc` property on the operator is already stored as `float` and not `short` or `int`. If there are concerns with bundling this change inside this PR, I can extract it to a separate one.
First-time contributor

@Sean-Kim I tested the latest build and I can see that you fixed the factor issue, so it's working great now... 👍
Awesome work, thank you...

@Sean-Kim I tested the latest build and I can see that you fixed the factor issue, so it's working great now... 👍 Awesome work, thank you...
Sean Kim added 1 commit 2024-06-06 22:05:21 +02:00
Merge branch 'main' of projects.blender.org:blender/blender into lasso-stabilize
Some checks failed
buildbot/vexp-code-patch-lint Build done.
buildbot/vexp-code-patch-darwin-arm64 Build done.
buildbot/vexp-code-patch-darwin-x86_64 Build done.
buildbot/vexp-code-patch-linux-x86_64 Build done.
buildbot/vexp-code-patch-windows-amd64 Build done.
buildbot/vexp-code-patch-coordinator Build done.
9b34d995df
Author
Member

@blender-bot package

@blender-bot package
Member

Package build started. Download here when ready.

Package build started. [Download here](https://builder.blender.org/download/patch/PR122062) when ready.
Daniel Bystedt approved these changes 2024-06-08 09:48:17 +02:00
First-time contributor

any ETA on this? 🙏

any ETA on this? 🙏
Author
Member

@ThinkingPolygons - No ETA at the moment, currently pending code review, but there are competing priorities for time on the reviewers side. I'm keeping an eye on this in the meantime so that it doesn't get lost and abandoned though.

@ThinkingPolygons - No ETA at the moment, currently pending code review, but there are competing priorities for time on the reviewers side. I'm keeping an eye on this in the meantime so that it doesn't get lost and abandoned though.
First-time contributor

@ThinkingPolygons - No ETA at the moment, currently pending code review, but there are competing priorities for time on the reviewers side. I'm keeping an eye on this in the meantime so that it doesn't get lost and abandoned though.

ok, thank you
i hope it lands soon. this is a massive improvement
cant wait 👍

> @ThinkingPolygons - No ETA at the moment, currently pending code review, but there are competing priorities for time on the reviewers side. I'm keeping an eye on this in the meantime so that it doesn't get lost and abandoned though. ok, thank you i hope it lands soon. this is a massive improvement cant wait 👍
Sean Kim added 1 commit 2024-06-20 01:06:01 +02:00
Hans Goudey reviewed 2024-06-20 20:45:48 +02:00
@ -1408,2 +1408,4 @@
)
@staticmethod
def draw_lasso_settings(layout, props):
Member

How about drawing these settings in a popover? That grouping could help to make the relation between them more obvious (and to avoid clutter in the header (though I know not everyone agrees with me about that!). Or is there precedent for drawing them this way?

How about drawing these settings in a popover? That grouping could help to make the relation between them more obvious (and to avoid clutter in the header (though I know not everyone agrees with me about that!). Or is there precedent for drawing them this way?
Author
Member

As far as I'm aware, the only other case that has the options displayed in the toolbar in this same way is the Annotation tool. I think it would be fine to group these under a "Stroke" popover to mirror the placement for brushes, but I don't have a strong opinion on this.

As far as I'm aware, the only other case that has the options displayed in the toolbar in this same way is the Annotation tool. I think it would be fine to group these under a "Stroke" popover to mirror the placement for brushes, but I don't have a strong opinion on this.
Member

Any grouping would be great I think. Otherwise the horizontal properties in the tool settings header are pretty unstructured.

Any grouping would be great I think. Otherwise the horizontal properties in the tool settings header are pretty unstructured.
Author
Member

After doing a bit of investigation, I believe this isn't possible currently for the same reasons that the Shift-S keybind isn't possible:

Classes that subclass Panel have a draw(self, context) method. To edit operator properties, we need to be able to access the current tool's properties, which isn't really exposed in a nice way through the python API at the moment.

After doing a bit of investigation, I believe this isn't possible currently for the same reasons that the `Shift-S` keybind isn't possible: Classes that subclass `Panel` have a `draw(self, context)` method. To edit operator properties, we need to be able to access the current tool's properties, which isn't really exposed in a nice way through the python API at the moment.
Member

I remembered we do this for some tool headers like bevel. There's some code for it in TOPBAR_PT_tool_settings_extra. And maybe this actually shows how to retrieve operator properties for an active tool!

        space_type, mode = ToolSelectPanelHelper._tool_key_from_context(context)
        cls = ToolSelectPanelHelper._tool_class_from_space_type(space_type)
        item, tool, _ = cls._tool_get_active(context, space_type, mode, with_icon=True)
        props = tool.operator_properties("node.select_box")
I remembered we do this for some tool headers like bevel. There's some code for it in `TOPBAR_PT_tool_settings_extra`. And maybe this actually shows how to retrieve operator properties for an active tool! ``` space_type, mode = ToolSelectPanelHelper._tool_key_from_context(context) cls = ToolSelectPanelHelper._tool_class_from_space_type(space_type) item, tool, _ = cls._tool_get_active(context, space_type, mode, with_icon=True) props = tool.operator_properties("node.select_box") ```
Author
Member

Oh, interesting! I'll try this out. I don't think this would work for the keymap case since that's just using a "path"

Oh, interesting! I'll try this out. I don't think this would work for the keymap case since that's just using a "path"
Sean-Kim marked this conversation as resolved
Sean Kim added 2 commits 2024-06-22 01:28:30 +02:00
Merge branch 'main' of projects.blender.org:blender/blender into lasso-stabilize
All checks were successful
buildbot/vexp-code-patch-lint Build done.
buildbot/vexp-code-patch-darwin-x86_64 Build done.
buildbot/vexp-code-patch-darwin-arm64 Build done.
buildbot/vexp-code-patch-linux-x86_64 Build done.
buildbot/vexp-code-patch-windows-amd64 Build done.
buildbot/vexp-code-patch-coordinator Build done.
a6b7d1b3fe
Author
Member

@blender-bot package

@blender-bot package
Member

Package build started. Download here when ready.

Package build started. [Download here](https://builder.blender.org/download/patch/PR122062) when ready.
Author
Member

stabilize_popover.gif

An example of the popover. Most other tool popovers use ... for the text, but I thought Stroke was more appropriate here due to the comparisons with the brush tools.

![stabilize_popover.gif](/attachments/668980ff-c4fd-4c2b-b6a6-a730a0cdc536) An example of the popover. Most other tool popovers use *...* for the text, but I thought *Stroke* was more appropriate here due to the comparisons with the brush tools.
Hans Goudey approved these changes 2024-06-22 14:00:49 +02:00
First-time contributor

An example of the popover.

The popover looks great... 👍

One quick question about those settings in the properties editor..
Thinking about consistency, what do you think about matching the layout of the brush settings and put those under subpanels (Stroke > Stabilize Stroke) ?

Little mockup:

image

Overkill? 😄

> An example of the popover. The popover looks great... 👍 One quick question about those settings in the properties editor.. Thinking about consistency, what do you think about matching the layout of the brush settings and put those under subpanels (Stroke > Stabilize Stroke) ? Little mockup: ![image](/attachments/738f0105-3eb1-45cb-b44f-0275f2a952bb) Overkill? 😄
Author
Member

The popover looks great... 👍

One quick question about those settings in the properties editor..
Thinking about consistency, what do you think about matching the layout of the brush settings and put those under subpanels (Stroke > Stabilize Stroke) ?

Little mockup:

image

Overkill? 😄

I think nesting settings under multiple subpanels like that is a bit overkill, since aside from Lasso Trim, the other existing tools only have a single option. If anything, I think having a single panel would be better like below. I may tackle this nesting in a subsequent patch though instead of putting it onto this one.

  [ ] Front Faces Only
> [ ] Stabilize Stroke
    Radius
    Factor
> The popover looks great... 👍 > > One quick question about those settings in the properties editor.. > Thinking about consistency, what do you think about matching the layout of the brush settings and put those under subpanels (Stroke > Stabilize Stroke) ? > > Little mockup: > > ![image](/attachments/738f0105-3eb1-45cb-b44f-0275f2a952bb) > > Overkill? 😄 I think nesting settings under multiple subpanels like that is a bit overkill, since aside from Lasso Trim, the other existing tools only have a single option. If anything, I think having a single panel would be better like below. I may tackle this nesting in a subsequent patch though instead of putting it onto this one. ``` [ ] Front Faces Only > [ ] Stabilize Stroke Radius Factor ```
Sean Kim merged commit 9d4d1aea98 into main 2024-06-27 01:32:26 +02:00
Sean Kim deleted branch lasso-stabilize 2024-06-27 01:32:30 +02:00
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset System
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
Asset Browser Project
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 Assignees
7 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#122062
No description provided.