Add Handlers to Operators. #86191

Open
opened 2021-03-02 13:45:07 +01:00 by Jaume Bellet · 44 comments

Motivation

I have found a needed to do something from python, when an operator is being executed.

Usage examples

  • an add-on is doing managing with geometry and needs to perform something when vertices are deleted.
  • an add-on could use translate operator to move something it controls, related to vertices positions.

Example code can be found on D10579

Design

See M2

Development steps

  • {icon check-square-o color=green} execute pre and post funtions on invoke
  • {icon check-square-o color=green} allow handlers removal
  • {icon check-square-o color=green} get the operator return code on py func
  • {icon check-square-o color=green} get the operator parameters on py func
  • {icon check-square-o color=green} loop only for operator self handlers
  • {icon check-square-o color=green} add modal handler
  • {icon check-square-o color=green} poll function
  • {icon check-square-o color=green} modal_end handler
  • {icon check-square-o color=green} context and event available on all handlers and poll function
  • {icon check-square-o color=green} delete all modal handlers from one owner in a single call

Know Issues

Feedback is welcome!

## Motivation I have found a needed to do something from python, when an operator is being executed. ## Usage examples * an add-on is doing managing with geometry and needs to perform something when vertices are deleted. * an add-on could use translate operator to move something it controls, related to vertices positions. Example code can be found on [D10579](https://archive.blender.org/developer/D10579) ## Design See M2 ## Development steps * {icon check-square-o color=green} execute pre and post funtions on invoke * {icon check-square-o color=green} allow handlers removal * {icon check-square-o color=green} get the operator return code on py func * {icon check-square-o color=green} get the operator parameters on py func * {icon check-square-o color=green} loop only for operator self handlers * {icon check-square-o color=green} add modal handler * {icon check-square-o color=green} poll function * {icon check-square-o color=green} modal_end handler * {icon check-square-o color=green} context and event available on all handlers and poll function * {icon check-square-o color=green} delete all modal handlers from one owner in a single call ## Know Issues Feedback is welcome!
Jaume Bellet self-assigned this 2021-03-02 13:45:07 +01:00
Author

Added subscribers: @JaumeBellet, @ideasman42

Added subscribers: @JaumeBellet, @ideasman42

Added subscriber: @rjg

Added subscriber: @rjg

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

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

Thank you for your report. Improvement suggestions and feature requests are off-topic on the bug tracker. Proposals can be posted on right-click select.

Thank you for your report. Improvement suggestions and feature requests are off-topic on the bug tracker. Proposals can be posted on [right-click select. ](https://blender.community/c/rightclickselect/)
Author

Removed subscriber: @ideasman42

Removed subscriber: @ideasman42
Author

i thought a task should be created first, just starting to implement it.

Created the diff

https://developer.blender.org/D10579

thanks!

i thought a task should be created first, just starting to implement it. Created the diff https://developer.blender.org/D10579 thanks!

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

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

I see, the ticket didn't seem like you intended to implement this yourself.

I see, the ticket didn't seem like you intended to implement this yourself.

Has this been discussed on DevTalk before and approved by one of the Python API module members?

Has this been discussed on DevTalk before and approved by one of the Python API module members?
Member

Added subscriber: @Imaginer

Added subscriber: @Imaginer
Author

In #86191#1122822, @rjg wrote:
Has this been discussed on DevTalk before and approved by one of the Python API module members?

No, it's a needed i found while trying to port what was done in the past in a fork (mechanical blender) to an addon.

> In #86191#1122822, @rjg wrote: > Has this been discussed on DevTalk before and approved by one of the Python API module members? No, it's a needed i found while trying to port what was done in the past in a fork (mechanical blender) to an addon.
Author

I've upload a Diff for tests. It still needs work, but would be great is some advice could be given before continuing.

Thanks!

I've upload a Diff for tests. It still needs work, but would be great is some advice could be given before continuing. Thanks!
Author

Seen https://developer.blender.org/D2052

the approach proposed here is less invasive

Seen https://developer.blender.org/D2052 the approach proposed here is less invasive
Member

Added subscriber: @Mets

Added subscriber: @Mets
Member

Some rigging use cases:

  • Add more "hacky" behaviour to the armature Symmetrize operator. (post-execute)
  • Entering weight paint mode would put the relevant armature and shading settings in the correct state automatically. (pre-execute)
  • Extruding a bone whose name already ends with a number would increment the number instead of adding .001. (post-execute)
  • Run newly added text datablocks with Register enabled on Append/Link.

Do you think these would already be possible to implement? If so, I might give it a try using your patch. Just let me know when you'd need some testing (And maybe give some more examples of the new python API calls that are possible with the patch).

I also think it would be nice to have this behave more like the current app handlers:

  • Adding a handler means appending it to a list. This is nice because it allows multiple addons to add functionality to an existing operator.
  • The name of the handler makes it abundantly clear when the code runs, eg. "frame_change_pre" runs before a frame change, and that's completely clear even when the name is in a vacuum. With a name like "handlers.invoke" it's unclear whether it runs before or after the operator's invoke function.

For example, I would expect
bpy.ops.mesh.primitive_cube_add.handlers.invoke_pre.append(my_func)
my_func() would be called before the operator's invoke()
Similarly, invoke_post, draw_pre, draw_post, execute_pre, execute_post, etc, etc.
What do you think about this?

Some rigging use cases: - Add more "hacky" behaviour to the armature Symmetrize operator. (post-execute) - Entering weight paint mode would put the relevant armature and shading settings in the correct state automatically. (pre-execute) - Extruding a bone whose name already ends with a number would increment the number instead of adding .001. (post-execute) - Run newly added text datablocks with Register enabled on Append/Link. Do you think these would already be possible to implement? If so, I might give it a try using your patch. Just let me know when you'd need some testing (And maybe give some more examples of the new python API calls that are possible with the patch). I also think it would be nice to have this behave more like the current app handlers: - Adding a handler means appending it to a list. This is nice because it allows multiple addons to add functionality to an existing operator. - The name of the handler makes it abundantly clear when the code runs, eg. "frame_change_pre" runs before a frame change, and that's completely clear even when the name is in a vacuum. With a name like "handlers.invoke" it's unclear whether it runs before or after the operator's invoke function. For example, I would expect `bpy.ops.mesh.primitive_cube_add.handlers.invoke_pre.append(my_func)` my_func() would be called before the operator's invoke() Similarly, invoke_post, draw_pre, draw_post, execute_pre, execute_post, etc, etc. What do you think about this?
Author

In #86191#1123946, @Mets wrote:
For example, I would expect
bpy.ops.mesh.primitive_cube_add.handlers.invoke_pre.append(my_func)
my_func() would be called before the operator's invoke()
Similarly, invoke_post, draw_pre, draw_post, execute_pre, execute_post, etc, etc.
What do you think about this?

In current Diff the handler is set as

bpy.ops.mesh.primitive_cube_add.handlers.invoke(owner,invoke_callback,(1,))

And is adding the callback on a list, so an operator can have multiple handlers. I added the owner because will be used for unregistering in a block (not already done).

Completely agree that your notation is better so i'll change it.

Thanks!

> In #86191#1123946, @Mets wrote: > For example, I would expect > `bpy.ops.mesh.primitive_cube_add.handlers.invoke_pre.append(my_func)` > my_func() would be called before the operator's invoke() > Similarly, invoke_post, draw_pre, draw_post, execute_pre, execute_post, etc, etc. > What do you think about this? In current Diff the handler is set as ``` bpy.ops.mesh.primitive_cube_add.handlers.invoke(owner,invoke_callback,(1,)) ``` And is adding the callback on a list, so an operator can have multiple handlers. I added the owner because will be used for unregistering in a block (not already done). Completely agree that your notation is better so i'll change it. Thanks!
Author

Uploaded a build for testing.

Graphicall Windows debug build

Uploaded a build for testing. [Graphicall Windows debug build ](https://blender.community/c/graphicall/vsbbbc/)
Member

Added subscriber: @ideasman42

Added subscriber: @ideasman42
Member

Before you burn too much time into this, it might also be good to have some devs from the PyAPI module take a look at the idea to make sure they're okay with it. @ideasman42 perhaps?

Before you burn too much time into this, it might also be good to have some devs from the PyAPI module take a look at the idea to make sure they're okay with it. @ideasman42 perhaps?
Author

@Mets Sure, thanks for your advice ;)

At this point until no response, I'll move onto an approximation for #86264 and later I'll continue my work on mechanicalblender add-on.

Have a nice weekend!

@Mets Sure, thanks for your advice ;) At this point until no response, I'll move onto an approximation for #86264 and later I'll continue my work on mechanicalblender add-on. Have a nice weekend!

Added subscriber: @TravisOBrien

Added subscriber: @TravisOBrien

Added subscriber: @wilBr

Added subscriber: @wilBr

@JaumeBellet this is a much have enhancement... thank you

another use cases....

. addon for viewport undo/redo view matrix changes

. with modal handler, unlock view navigation for standard transform tools/operators

. display warning while entering in edit mode (tab key) if object is procedurally builded or display window settings for adjust it rather than entry in edit mode

@JaumeBellet this is a much have enhancement... thank you another use cases.... . addon for viewport undo/redo view matrix changes . with modal handler, unlock view navigation for standard transform tools/operators . display warning while entering in edit mode (tab key) if object is procedurally builded or display window settings for adjust it rather than entry in edit mode

Added subscriber: @testure

Added subscriber: @testure

Personally I'd put this functionality on hold (IIRC this been proposed and rejected before).

It's allows for some odd situations.

  • functions may change the state so the operators poll function doesn't succeed anymore.
Even if this is accounted for with an extra check, it could result in scripts ending up in a poorly defined state where pre/post functions don't behave as expected.
  • 'pre' functions would run, even if the operator doesn't, as some operators check for spesific situations and return pass-through.

There are more general down-sides to wrapping operators too.

For example, script authors that want to respond to changes to selection, are likely to seek out all operators that change selection, then add handlers to all of them. This isn't good design since operators from add-ons might change selection which won't be included in this list.
In that case we would be better off to be able to know when the selection changed, instead of adding callbacks to every selection operator.

The same goes for mode switching. In that case it's possible to register a callback to the object mode using bpy.msgbus.

We could make sure notifications that Python developers find useful (such as selection) properly publish changes to bpy.msgbus, then script authors could use this as a reliable way to respond to selection changes.


There will still likely be some use-cases that can't be handled in a generic way.

This gets into a question of allowing script authors to do dangerous things. From a maintainers perspective this often doesn't seem worthwhile since we will here form users who run into bugs caused by features like this.

So personally I'd rather make sure bpy.msgbus is a reliable way to respond to changes to Blender data, which I think covers many of the cases this kind of feature would end up being used for.

Personally I'd put this functionality on hold (IIRC this been proposed and rejected before). It's allows for some odd situations. - functions may change the state so the operators poll function doesn't succeed anymore. ``` Even if this is accounted for with an extra check, it could result in scripts ending up in a poorly defined state where pre/post functions don't behave as expected. ``` - 'pre' functions would run, even if the operator doesn't, as some operators check for spesific situations and return pass-through. ---- There are more general down-sides to wrapping operators too. For example, script authors that want to respond to changes to selection, are likely to seek out all operators that change selection, then add handlers to all of them. This isn't good design since operators from add-ons might change selection which won't be included in this list. In that case we would be better off to be able to know when the selection changed, instead of adding callbacks to every selection operator. The same goes for mode switching. In that case it's possible to register a callback to the object mode using `bpy.msgbus`. We could make sure notifications that Python developers find useful (such as selection) properly publish changes to `bpy.msgbus`, then script authors could use this as a reliable way to respond to selection changes. ---- There will still likely be some use-cases that can't be handled in a generic way. This gets into a question of allowing script authors to do dangerous things. From a maintainers perspective this often doesn't seem worthwhile since we will here form users who run into bugs caused by features like this. So personally I'd rather make sure `bpy.msgbus` is a reliable way to respond to changes to Blender data, which I think covers many of the cases this kind of feature would end up being used for.
Author

Thanks for your comments!

In #86191#1125789, @ideasman42 wrote:
Personally I'd put this functionality on hold (IIRC this been proposed and rejected before).

It's allows for some odd situations.

  • functions may change the state so the operators poll function doesn't succeed anymore.

    Even if this is accounted for with an extra check, it could result in scripts ending up in a poorly defined state where pre/post functions don't behave as expected.

  • 'pre' functions would run, even if the operator doesn't, as some operators check for spesific situations and return pass-through.


The pre-invoke callback, could be moved before operator poll call, and also a callkback to get the poll result could be set, so developer could be aware of it. The past-through can be handled in post function, as is getting as operator result.

In #86191#1125789, @ideasman42 wrote:

There are more general down-sides to wrapping operators too.

For example, script authors that want to respond to changes to selection, are likely to seek out all operators that change selection, then add handlers to all of them. This isn't good design since operators from add-ons might change selection which won't be included in this list.
In that case we would be better off to be able to know when the selection changed, instead of adding callbacks to every selection operator.

The same goes for mode switching. In that case it's possible to register a callback to the object mode using bpy.msgbus.

We could make sure notifications that Python developers find useful (such as selection) properly publish changes to bpy.msgbus, then script authors could use this as a reliable way to respond to selection changes.


Of course bpy.msgbus is better handling needs that affects in general way, but for specific does not. In my case I'm looking for a way of selecting python scope objects in a seamless way, and also i would use to create default extra data depending on data created (eg, in my case could be default dimensions in a cube)

In #86191#1125789, @ideasman42 wrote:
There will still likely be some use-cases that can't be handled in a generic way.

This gets into a question of allowing script authors to do dangerous things. From a maintainers perspective this often doesn't seem worthwhile since we will here form users who run into bugs caused by features like this.

So personally I'd rather make sure bpy.msgbus is a reliable way to respond to changes to Blender data, which I think covers many of the cases this kind of feature would end up being used for.

by dangerous, do you refer "unexpected" ? I obviously can agree here, but allowing making thinks more seamless and automatized (without workarounds) worth in terms of add-ons quality and user performance.

Thanks for your comments! > In #86191#1125789, @ideasman42 wrote: > Personally I'd put this functionality on hold (IIRC this been proposed and rejected before). > > It's allows for some odd situations. > > - functions may change the state so the operators poll function doesn't succeed anymore. > > Even if this is accounted for with an extra check, it could result in scripts ending up in a poorly defined state where pre/post functions don't behave as expected. > > - 'pre' functions would run, even if the operator doesn't, as some operators check for spesific situations and return pass-through. > > ---- The pre-invoke callback, could be moved before operator poll call, and also a callkback to get the poll result could be set, so developer could be aware of it. The past-through can be handled in post function, as is getting as operator result. > In #86191#1125789, @ideasman42 wrote: > > There are more general down-sides to wrapping operators too. > > For example, script authors that want to respond to changes to selection, are likely to seek out all operators that change selection, then add handlers to all of them. This isn't good design since operators from add-ons might change selection which won't be included in this list. > In that case we would be better off to be able to know when the selection changed, instead of adding callbacks to every selection operator. > > The same goes for mode switching. In that case it's possible to register a callback to the object mode using `bpy.msgbus`. > > We could make sure notifications that Python developers find useful (such as selection) properly publish changes to `bpy.msgbus`, then script authors could use this as a reliable way to respond to selection changes. > > ---- Of course bpy.msgbus is better handling needs that affects in general way, but for specific does not. In my case I'm looking for a way of selecting python scope objects in a seamless way, and also i would use to create default extra data depending on data created (eg, in my case could be default dimensions in a cube) > In #86191#1125789, @ideasman42 wrote: > There will still likely be some use-cases that can't be handled in a generic way. > > This gets into a question of allowing script authors to do dangerous things. From a maintainers perspective this often doesn't seem worthwhile since we will here form users who run into bugs caused by features like this. > > So personally I'd rather make sure `bpy.msgbus` is a reliable way to respond to changes to Blender data, which I think covers many of the cases this kind of feature would end up being used for. by dangerous, do you refer "unexpected" ? I obviously can agree here, but allowing making thinks more seamless and automatized (without workarounds) worth in terms of add-ons quality and user performance.

In #86191#1125789, @ideasman42 wrote:
So personally I'd rather make sure bpy.msgbus is a reliable way to respond to changes to Blender data, which I think covers many of the cases this kind of feature would end up being used for.

It could be that I have just not found the correct use-case for msgbus, but from my own experiences I have never been able to use it for what I need it for. For example- if i want to subscribe to object.location, my callback doesn't fire if the user moved the object in the viewport because it doesn't go through RNA. I can't subscribe to object.data and get a callback when mesh data changed for a specific object because the user ran a bevel operation or whatever. Talking about script authors doing dangerous things- it's already happening because we're trying to work around bpy's lack of a proper event/subscriber system. Technical artists around the world are abusing modal operators and timers to get the results they need (which is usually notification that an event has happened, an operator has been triggered, etc)

> In #86191#1125789, @ideasman42 wrote: > So personally I'd rather make sure `bpy.msgbus` is a reliable way to respond to changes to Blender data, which I think covers many of the cases this kind of feature would end up being used for. It could be that I have just not found the correct use-case for msgbus, but from my own experiences I have never been able to use it for what I need it for. For example- if i want to subscribe to object.location, my callback doesn't fire if the user moved the object in the viewport because it doesn't go through RNA. I can't subscribe to object.data and get a callback when mesh data changed for a specific object because the user ran a bevel operation or whatever. Talking about script authors doing dangerous things- it's already happening because we're trying to work around bpy's lack of a proper event/subscriber system. Technical artists around the world are abusing modal operators and timers to get the results they need (which is usually notification that an event has happened, an operator has been triggered, etc)

@testure

In #86191#1126432, @testure wrote:

In #86191#1125789, @ideasman42 wrote:
So personally I'd rather make sure bpy.msgbus is a reliable way to respond to changes to Blender data, which I think covers many of the cases this kind of feature would end up being used for.

It could be that I have just not found the correct use-case for msgbus, but from my own experiences I have never been able to use it for what I need it for. For example- if i want to subscribe to object.location, my callback doesn't fire if the user moved the object in the viewport because it doesn't go through RNA.

Support for this should be added, while not exactly a bug, it should be possible to reliably subscribe to these kinds of events.

@testure > In #86191#1126432, @testure wrote: >> In #86191#1125789, @ideasman42 wrote: >> So personally I'd rather make sure `bpy.msgbus` is a reliable way to respond to changes to Blender data, which I think covers many of the cases this kind of feature would end up being used for. > > It could be that I have just not found the correct use-case for msgbus, but from my own experiences I have never been able to use it for what I need it for. For example- if i want to subscribe to object.location, my callback doesn't fire if the user moved the object in the viewport because it doesn't go through RNA. Support for this should be added, while not exactly a bug, it should be possible to reliably subscribe to these kinds of events.

added modal handlers.. great...

Can you do a, no debug, compiled blender version? I can't to run last graphicall version cause so many microsoft's debug DLL missing. (msvcp140d.dll, ucrtbaseD.dll, vcruntime140_1d.dll ......)

thank you.

added modal handlers.. great... Can you do a, no debug, compiled blender version? I can't to run last graphicall version cause so many microsoft's debug DLL missing. (msvcp140d.dll, ucrtbaseD.dll, vcruntime140_1d.dll ......) thank you.
Author

Sure!, also the uploaded one was uploded on first tests.

Sure!, also the uploaded one was uploded on first tests.
Author
updated! https://blender.community/c/graphicall/vsbbbc/
Author

Added subscriber: @DotBow

Added subscriber: @DotBow
Author

In D10579#270638, @DotBow wrote:
Hi!
Very interesting and helpful addition!
Does this mean that it will be possible to execute somethng in-between modal operators as well (i.e. detect start and finish)?
I already have some ideas where it can improve my workflow a lot! Thanks!

I reply here.

Yes, but i think in this case a modal_end callback should be added, because executing always a python callback for each modal operator loop would be unnecessary. Need to check that.

Also the return code on modal operator function should be bypassed to python callback (currently missing)

> In [D10579](https://archive.blender.org/developer/D10579)#270638, @DotBow wrote: > Hi! > Very interesting and helpful addition! > Does this mean that it will be possible to execute somethng in-between modal operators as well (i.e. detect start and finish)? > I already have some ideas where it can improve my workflow a lot! Thanks! I reply here. Yes, but i think in this case a modal_end callback should be added, because executing always a python callback for each modal operator loop would be unnecessary. Need to check that. Also the return code on modal operator function should be bypassed to python callback (currently missing)
Member

Accidently posted this in the patch instead of here first, but here is more relevant:

Are you still hoping to convince the devs that this is worth adding to blender? Or are you happy to continue development even if it doesn't get into master?

Accidently posted this in the patch instead of here first, but here is more relevant: Are you still hoping to convince the devs that this is worth adding to blender? Or are you happy to continue development even if it doesn't get into master?
Author

I think both!

After some expectations with add-ons i've seen, I have already assumed the project I am involved with will continue being a fork, more add-on focused. and I'll use this feature. All specific things will go over Python, i'll submit tasks and patches here for things that could benefit Blender and it's users. (may be some things more focused for mechanical engineering / arch users, but this does not mean could be great for all)

I can understand the point of view of core devs, as they are responsible of the most low level functionality, this means that any change here can affect lots and every where.

Not related to blender development people, can expand blender via add-ons, and this is great, but the workarounds (modals, abusive timers, compute things in drawing callbacks, etc) they are definitively not. (What happens with large scenes? or if you have a lot of addons on background?) And also the UI part of most addons is not "natural". This goes against user productivity. Would it be great if before selecting i must always think before what i want to select (face? vertex? edge?) ,select the specified tool and do the selection?

I Remember Ton said once time ago that if you consider something should be added, you should make noise, and explain your proposal to the world. If this development was stopped at first "put on hold proposal", others could not see the possible potential and benefits (or issues), so they could support it if they like and as a group, achieve to get it included on official releases, with the needed changes to meet blender quality, of course.

I think both! After some expectations with add-ons i've seen, I have already assumed the project I am involved with will continue being a fork, more add-on focused. and I'll use this feature. All specific things will go over Python, i'll submit tasks and patches here for things that could benefit Blender and it's users. (may be some things more focused for mechanical engineering / arch users, but this does not mean could be great for all) I can understand the point of view of core devs, as they are responsible of the most low level functionality, this means that any change here can affect lots and every where. Not related to blender development people, can expand blender via add-ons, and this is great, but the workarounds (modals, abusive timers, compute things in drawing callbacks, etc) they are definitively not. (What happens with large scenes? or if you have a lot of addons on background?) And also the UI part of most addons is not "natural". This goes against user productivity. Would it be great if before selecting i must *always* think before what i want to select (face? vertex? edge?) ,select the specified tool and do the selection? I Remember Ton said once time ago that if you consider something should be added, you should make noise, and explain your proposal to the world. If this development was stopped at first "put on hold proposal", others could not see the possible potential and benefits (or issues), so they could support it if they like and as a group, achieve to get it included on official releases, with the needed changes to meet blender quality, of course.
Member

Well, I really like your attitude, and am excited to see where this goes! :D

Well, I really like your attitude, and am excited to see where this goes! :D
Author

Things are clear with a flow diagram ;) Need to change diff to match it

Things are clear with a flow diagram ;) Need to change diff to match it

Added subscriber: @JoseConseco

Added subscriber: @JoseConseco

Added subscriber: @kadam

Added subscriber: @kadam

Added subscriber: @in10siv

Added subscriber: @in10siv
Author

D10852 allows to add data to existing enums, so it can be used to add new functionality on operators based on this new value checking the value on the handler for the operator.

[D10852](https://archive.blender.org/developer/D10852) allows to add data to existing enums, so it can be used to add new functionality on operators based on this new value checking the value on the handler for the operator.

Added subscriber: @ckohl_art

Added subscriber: @ckohl_art
Contributor

Added subscriber: @Raimund58

Added subscriber: @Raimund58
Philipp Oeser removed the
Interest
Core
label 2023-02-09 14:43:13 +01:00
Author

I have continued this development, on this branch

I have continued this development, on this [branch ](https://projects.blender.org/JaumeBellet/mblender/src/branch/mb-0011-operator-handlers)
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
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
13 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#86191
No description provided.