Sculpt Trim tools are very slow #84229

Open
opened 2020-12-29 02:02:17 +01:00 by Kuzey · 40 comments

System Information
Operating system: macOS Mojave 10.14.6
Graphics card:

Blender Version
Broken: Version 2.91.0 (2.91.0 2020-11-25) & Version 2.92.0 (2.92.0 2020-12-27)
Worked: n/a

Short description of error
Using Box Trim is very slow. If you use the tool and then switch to another program like a web browser before the task is done, Blender becomes unresponsive and you have to force quit it.

Exact steps for others to reproduce the error
See video of the slowness.

boxtrim.mov

**System Information** Operating system: macOS Mojave 10.14.6 Graphics card: **Blender Version** Broken: Version 2.91.0 (2.91.0 2020-11-25) & Version 2.92.0 (2.92.0 2020-12-27) Worked: n/a **Short description of error** Using Box Trim is very slow. If you use the tool and then switch to another program like a web browser before the task is done, Blender becomes unresponsive and you have to force quit it. **Exact steps for others to reproduce the error** See video of the slowness. [boxtrim.mov](https://archive.blender.org/developer/F9534762/boxtrim.mov)
Author

Added subscriber: @kuzey

Added subscriber: @kuzey

#95189 was marked as duplicate of this issue

#95189 was marked as duplicate of this issue

#83078 was marked as duplicate of this issue

#83078 was marked as duplicate of this issue

#97295 was marked as duplicate of this issue

#97295 was marked as duplicate of this issue

Added subscriber: @rjg

Added subscriber: @rjg

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

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

It is a memory intensive operation. Depending on the complexity of your mesh, your operating system may have to use the page file, because you are using more memory than RAM is available, which is quite slow. You can check this by opening the task manager and monitoring the memory usage.

While we always try to improve performance, potential areas that could be optimized aren't triaged as bugs.

It is a memory intensive operation. Depending on the complexity of your mesh, your operating system may have to use the page file, because you are using more memory than RAM is available, which is quite slow. You can check this by opening the task manager and monitoring the memory usage. While we always try to improve performance, potential areas that could be optimized aren't triaged as bugs.
Member

Added subscribers: @PabloDobarro, @howardt, @Sergey, @lichtwerk

Added subscribers: @PabloDobarro, @howardt, @Sergey, @lichtwerk
Member

Changed status from 'Archived' to: 'Needs Developer To Reproduce'

Changed status from 'Archived' to: 'Needs Developer To Reproduce'
Member

We already had #83078 (Box Trim Causes Crash) reported for this (but that one never got an answer from @PabloDobarro -- and was also closed for the wrong reason).

The thing here is that it uses new exact booleans under the hood [which can be very slow].
So unless you are saying that this is performing worse than regular booleans, I would assume this has little chance to be classified as bug.

That being said, it does feel weird having to wait 100 seconds for a tool like this in sculpting [where a higher poly count is to be expected]

CC @howardt
CC @Sergey

We already had #83078 (Box Trim Causes Crash) reported for this (but that one never got an answer from @PabloDobarro -- and was also closed for the wrong reason). The thing here is that it uses new exact booleans under the hood [which can be very slow]. So unless you are saying that this is performing worse than regular booleans, I would assume this has little chance to be classified as bug. That being said, it does feel weird having to wait **100 seconds** for a tool like this in sculpting [where a higher poly count is to be expected] CC @howardt CC @Sergey
Member

Performance should be a little bit worse than regular booleans (it need to perform the boolean operation, a mesh ->bmesh -> mesh conversion and a PBVH rebuild. Parts of this can be optimized, like avoiding the mesh -> bmesh conversion if the boolean code supports that in the future. After that, the speed of the tool will completely depend on the speed of the boolean code.
I don't think this is a bug, more like an optimization TODO.

Performance should be a little bit worse than regular booleans (it need to perform the boolean operation, a mesh ->bmesh -> mesh conversion and a PBVH rebuild. Parts of this can be optimized, like avoiding the mesh -> bmesh conversion if the boolean code supports that in the future. After that, the speed of the tool will completely depend on the speed of the boolean code. I don't think this is a bug, more like an optimization TODO.
Member

OKi, thanx checking @PabloDobarro , will set to TODO then

OKi, thanx checking @PabloDobarro , will set to TODO then
Member

Changed status from 'Needs Developer To Reproduce' to: 'Confirmed'

Changed status from 'Needs Developer To Reproduce' to: 'Confirmed'
Member

I am working right now on code that avoids trip in and out of BMesh for Exact Booleans. That may help some. After I do that, I still have a number of places in the code where I can use multithreading. and intend to do that.

Exact Boolean uses a lot of memory. I haven't paid any attention to memory optimization. I may do that too. It is quite possible that as Robert Guetzkow speculated above, the example shown here is a case where it is using more memory than the user has available, and so it is paging.

The other place where Exact Boolean is unreasonably slow right now is when the input is not "PWN" (piecewise-constant-winding number) -- which approximately means: when both operands are not closed volumes, and the only non-manifold edges are "touching" kind (think: two cubes touching along a shared edge). I imagine the cutting shape that Pablo is using is always PWN, but I can't tell from the video whether the other shape is too. I need to do something different when the inputs are not PWN, as the current method is clearly too slow. So I will work on that too.

I am working right now on code that avoids trip in and out of BMesh for Exact Booleans. That may help some. After I do that, I still have a number of places in the code where I can use multithreading. and intend to do that. Exact Boolean uses a lot of memory. I haven't paid any attention to memory optimization. I may do that too. It is quite possible that as Robert Guetzkow speculated above, the example shown here is a case where it is using more memory than the user has available, and so it is paging. The other place where Exact Boolean is unreasonably slow right now is when the input is not "PWN" (piecewise-constant-winding number) -- which approximately means: when both operands are not closed volumes, and the only non-manifold edges are "touching" kind (think: two cubes touching along a shared edge). I imagine the cutting shape that Pablo is using is always PWN, but I can't tell from the video whether the other shape is too. I need to do something different when the inputs are not PWN, as the current method is clearly too slow. So I will work on that too.

Added subscriber: @muhuk

Added subscriber: @muhuk

Added subscriber: @AdamJanz

Added subscriber: @AdamJanz

Yes, I noticed this is unusually slow. In this video by Zach Reinhardt, the lasso trim tool appears to work quite fast compared to on my system. Same in both Blender 2.92 official and 2.93 alpha. I'm using i7-5930K 6 core @ 3.5 GHz (3.7 boost), a GTX 970 with 4 GB, and 32 GB RAM, and Zach is using a i7-7700 4 core @ 4.2 GHz , a GTX 1070 ti with 8 GB, and 64 GB RAM. However, the operation in both cases is ultra-simple: using the lasso tool to cut the default rounded cube, which has a mere 24,578 vertices. Is this operation heavily dependent on CUDA cores (1664 vs 2432), because judging by the monitors on my system, the simple operation barely touches my GPU RAM, GPU load, or system RAM? Link to Zach's video: https://youtu.be/tQfFlzHJJ88?t=289 (The same operation hangs for 7 seconds on my system). Thanks for looking into this.

Yes, I noticed this is unusually slow. In this video by Zach Reinhardt, the lasso trim tool appears to work quite fast compared to on my system. Same in both Blender 2.92 official and 2.93 alpha. I'm using i7-5930K 6 core @ 3.5 GHz (3.7 boost), a GTX 970 with 4 GB, and 32 GB RAM, and Zach is using a i7-7700 4 core @ 4.2 GHz , a GTX 1070 ti with 8 GB, and 64 GB RAM. **However, the operation in both cases is ultra-simple:** using the lasso tool to cut the default rounded cube, which has a mere 24,578 vertices. Is this operation heavily dependent on **CUDA cores (1664 vs 2432)**, because judging by the monitors on my system, the simple operation **barely touches my GPU RAM, GPU load, or system RAM**? Link to Zach's video: https://youtu.be/tQfFlzHJJ88?t=289 (The same operation hangs for 7 seconds on my system). Thanks for looking into this.

Added subscriber: @Zsolt-Kantor

Added subscriber: @Zsolt-Kantor

It quickly ate up 5 GB of system RAM on a mesh of 24k faces. First I thought maybe symmetry caused the cutter shape to be too complex but that's not the case. The two cuts are applied separately. 2.93 LTS and the newest 3.0 master alpha.

It quickly ate up 5 GB of system RAM on a mesh of 24k faces. First I thought maybe symmetry caused the cutter shape to be too complex but that's not the case. The two cuts are applied separately. 2.93 LTS and the newest 3.0 master alpha.

Added subscriber: @lictex_1

Added subscriber: @lictex_1
Member

Added subscribers: @Stephen_Sensei, @PratikPB2123

Added subscribers: @Stephen_Sensei, @PratikPB2123
Member

Added subscribers: @mike.cairns86, @iss, @Foaly

Added subscribers: @mike.cairns86, @iss, @Foaly

Added subscriber: @Bun

Added subscriber: @Bun

In #84229#1084186, @howardt wrote:
I am working right now on code that avoids trip in and out of BMesh for Exact Booleans. That may help some. After I do that, I still have a number of places in the code where I can use multithreading. and intend to do that.

Exact Boolean uses a lot of memory. I haven't paid any attention to memory optimization. I may do that too. It is quite possible that as Robert Guetzkow speculated above, the example shown here is a case where it is using more memory than the user has available, and so it is paging.

The other place where Exact Boolean is unreasonably slow right now is when the input is not "PWN" (piecewise-constant-winding number) -- which approximately means: when both operands are not closed volumes, and the only non-manifold edges are "touching" kind (think: two cubes touching along a shared edge). I imagine the cutting shape that Pablo is using is always PWN, but I can't tell from the video whether the other shape is too. I need to do something different when the inputs are not PWN, as the current method is clearly too slow. So I will work on that too.

Curious to know what's changed on this front as this is a feature I'm deeply interested in as a sculptor and the inability to rapidly combine, separate or trim meshes makes a lot of the tried and true workflows many are used to coming from other tools essentially impossible.

Around 30% of the power in a sculpting workflow is locked behind curved trims and curved separations of meshes or the recombination of elements.

> In #84229#1084186, @howardt wrote: > I am working right now on code that avoids trip in and out of BMesh for Exact Booleans. That may help some. After I do that, I still have a number of places in the code where I can use multithreading. and intend to do that. > > Exact Boolean uses a lot of memory. I haven't paid any attention to memory optimization. I may do that too. It is quite possible that as Robert Guetzkow speculated above, the example shown here is a case where it is using more memory than the user has available, and so it is paging. > > The other place where Exact Boolean is unreasonably slow right now is when the input is not "PWN" (piecewise-constant-winding number) -- which approximately means: when both operands are not closed volumes, and the only non-manifold edges are "touching" kind (think: two cubes touching along a shared edge). I imagine the cutting shape that Pablo is using is always PWN, but I can't tell from the video whether the other shape is too. I need to do something different when the inputs are not PWN, as the current method is clearly too slow. So I will work on that too. Curious to know what's changed on this front as this is a feature I'm deeply interested in as a sculptor and the inability to rapidly combine, separate or trim meshes makes a lot of the tried and true workflows many are used to coming from other tools essentially impossible. Around 30% of the power in a sculpting workflow is locked behind curved trims and curved separations of meshes or the recombination of elements.
Member

I did do the thing I referred to in Dec 2020 (avoiding the round trip in and out of BMesh) but realize that doesn't help much of the case of large numbers of faces. I need a new approach. Either one that avoids doing exact arithmetic most of the time, like in the paper "Interactive and Robust Mesh Booleans by Cherchi et al., or something that isolates the calculations to only those parts of the mesh near the intersection, like in the paper "EMBER: exact mesh booleans via efficient & robust local arrangements" by Trettner, Nehring-Wirxel, Kobbelt. I think I'll try one or the other of these approaches, or maybe a combination. But since I'm working on Bevel V2 right now, it will be a number of months before I can get to that.

I did do the thing I referred to in Dec 2020 (avoiding the round trip in and out of BMesh) but realize that doesn't help much of the case of large numbers of faces. I need a new approach. Either one that avoids doing exact arithmetic most of the time, like in the paper "Interactive and Robust Mesh Booleans by Cherchi et al., or something that isolates the calculations to only those parts of the mesh near the intersection, like in the paper "EMBER: exact mesh booleans via efficient & robust local arrangements" by Trettner, Nehring-Wirxel, Kobbelt. I think I'll try one or the other of these approaches, or maybe a combination. But since I'm working on Bevel V2 right now, it will be a number of months before I can get to that.

Thank-you and I appreciate the response. This is pretty much the one complaint I hear from a lot of ZBrush mains (sick of the general pain of the tool) who want to jump ship to Blender fulltime so to know its on your mind fills me with enormous hope. Best of luck with the work on Bevel V2 and best wishes. We all want to jump ship to Blender for our entire workflows not just most of the workflow.

Thank-you and I appreciate the response. This is pretty much the one complaint I hear from a lot of ZBrush mains (sick of the general pain of the tool) who want to jump ship to Blender fulltime so to know its on your mind fills me with enormous hope. Best of luck with the work on Bevel V2 and best wishes. We all want to jump ship to Blender for our entire workflows not just most of the workflow.
Philipp Oeser changed title from Box Trim tool is very slow to Sculpt Trim tools are very slow 2022-11-16 13:08:41 +01:00
Member

Added subscribers: @Limarest, @JulienKaspar, @Garek

Added subscribers: @Limarest, @JulienKaspar, @Garek

Added subscriber: @s12a

Added subscriber: @s12a

Added subscriber: @feefity

Added subscriber: @feefity

Any word on even incremental changes (eg, trip-avoidance in and out of exact bools before multi-threading support)?

I'm wondering if dropping the mesh precision as the polycount increases would make sense, given it seems like a precision tradeoff is ideal given that as the polycount goes up, the relative polygon size to the model goes down in a way which is typically proportional and if this principle can be taken advantage of.

As the polycount goes up, the perceptible gains of precision become marginal and then eventually imperceivable.

That very small difference could then be compensated with a cheaper operation, such as projecting the new polygons along the normal of the cutting surface, assuming it is even needed at all whatsoever.

Any word on even incremental changes (eg, trip-avoidance in and out of exact bools before multi-threading support)? I'm wondering if dropping the mesh precision as the polycount increases would make sense, given it seems like a precision tradeoff is ideal given that as the polycount goes up, the relative polygon size to the model goes down in a way which is typically proportional and if this principle can be taken advantage of. As the polycount goes up, the perceptible gains of precision become marginal and then eventually imperceivable. That very small difference could then be compensated with a cheaper operation, such as projecting the new polygons along the normal of the cutting surface, assuming it is even needed at all whatsoever.
Julien Kaspar added this to the Sculpt, Paint & Texture project 2023-02-08 10:48:53 +01:00

I'm here to make someone remember again. Need quick(er) Trim! I really am ready it to be less precise but faster!

I'm here to make someone remember again. Need quick(er) Trim! I really am ready it to be less precise but faster!
Philipp Oeser removed the
Interest
Sculpt, Paint & Texture
label 2023-02-10 09:12:04 +01:00

Another friendly reminder: Quicker trim. Lower precision, higher speed, just like MaximTkachenko said a month ago.

This still is a workflow breaking problem at the moment.

Some users have had success using "mask slice to new object", though the problem is that this is first extremely tedious, and second a new object isn't actually needed. This also better aligns with what the trim tool's expected behavior is during a sculpting workflow

the fact this isn't on a roadmap or this isn't even a quick fix slid into the sculpting workflow to make do until something better comes along for the short term with suggestions like this to make this faster is kinda sad cuz users (see above link) are finding ways to sort-of make do but they are incredibly awkward to actually do since the tools are designed for other totally different tasks.

Looking at the old trim tool, I can sort of see something interesting

The way the existing trim tool bottoms out/flattens along a normal to produce a flat pizza-geometry with overlapping polygons at its base. This really is not fit for purpose and isn't what trimming "is" in a sculpting workflow, at all, even if it is "adequate" in some very limited edge-casees where the trimmed geometry has a smaller profile than the host geometry.

https://d3a2gvihmbqfjo.cloudfront.net/8b/8b069a553603c7594d610cf6185c803e/8b069a553603c7594d610cf6185c803e.png

This isn't supposed to happen, at all which makes me wonder if the spec itself was at fault and didn't adequately describe the function of the tool in precise enough terms during its design? In which case, whoever's designing the spec needs someone who uses tools like this so the edgecases get caught early.

Its weird considering most of the sculpting tools in Blender so far have been exceptionally good too.

The generally agreed upon function of a trim tool is:

  1. The variable-precision removal and closure of masked geometry via boolean process
  2. where precision drops as the polycount in the selected area increases
  3. The used mask itself is volumetric, rather than being a projection and should pass through geometry along a given view
  4. The mask can be geometry, or an infinite or curve with optional limited controlled depth relative to the cursor or mask origin
  5. The curve should be made rapidly, and have either infinite or limited length where a closed shape is inferred
  6. The mask should take into account existing masks prior to the tool activating
  7. The trim tool should be something which can used in rapid succession to make continued adjustment in a subtractive process

In doing so, you sorta get the capacity to very rapidly produce very complex shapes with very little action. The sacrifice is the percieved precision being high, while the actual precision is kinda low and the precision level itself adapts, getting less precise as polycounts get higher to help keep stuff speedy.

In one of these subtractive workflows, masking and trimming like this is a great way to search for shapes inside a volume with rapid operations in sequence.

I hope two years from now Blender has one. A lot of folks really wanna get off the ZBrush train, especially given the new pricing plans.

Another friendly reminder: Quicker trim. Lower precision, higher speed, just like MaximTkachenko said a month ago. This still is a workflow breaking problem at the moment. [Some users have had success using "mask slice to new object", though the problem is that this is first extremely tedious, and second a new object isn't actually needed. This also better aligns with what the trim tool's expected behavior is during a sculpting workflow](https://blender.community/c/rightclickselect/8M02/?sorting=hot) the fact this isn't on a roadmap or this isn't even a quick fix slid into the sculpting workflow to make do until something better comes along for the short term with suggestions like this to make this faster is kinda sad cuz users (see above link) are finding ways to sort-of make do but they are incredibly awkward to actually do since the tools are designed for other totally different tasks. Looking at the old trim tool, I can sort of see something interesting The way the existing trim tool bottoms out/flattens along a normal to produce a flat pizza-geometry with overlapping polygons at its base. This really is not fit for purpose and isn't what trimming "is" in a sculpting workflow, at all, even if it is "adequate" in some very limited edge-casees where the trimmed geometry has a smaller profile than the host geometry. ![https://d3a2gvihmbqfjo.cloudfront.net/8b/8b069a553603c7594d610cf6185c803e/8b069a553603c7594d610cf6185c803e.png](https://d3a2gvihmbqfjo.cloudfront.net/8b/8b069a553603c7594d610cf6185c803e/8b069a553603c7594d610cf6185c803e.png) This isn't supposed to happen, at all which makes me wonder if the spec itself was at fault and didn't adequately describe the function of the tool in precise enough terms during its design? In which case, whoever's designing the spec needs someone who uses tools like this so the edgecases get caught early. Its weird considering most of the sculpting tools in Blender so far have been exceptionally good too. The generally agreed upon function of a trim tool is: 1. The variable-precision removal and closure of masked geometry via boolean process 2. where precision drops as the polycount in the selected area increases 3. The used mask itself is volumetric, rather than being a projection and should pass through geometry along a given view 4. The mask can be geometry, or an infinite or curve with optional limited controlled depth relative to the cursor or mask origin 5. The curve should be made rapidly, and have either infinite or limited length where a closed shape is inferred 6. The mask should take into account existing masks prior to the tool activating 7. The trim tool should be something which can used in rapid succession to make continued adjustment in a subtractive process In doing so, you sorta get the capacity to very rapidly produce very complex shapes with very little action. The sacrifice is the percieved precision being high, while the actual precision is kinda low and the precision level itself adapts, getting less precise as polycounts get higher to help keep stuff speedy. In one of these subtractive workflows, masking and trimming like this is a great way to search for shapes inside a volume with rapid operations in sequence. I hope two years from now Blender has one. A lot of folks really wanna get off the ZBrush train, especially given the new pricing plans.
Member

@Bun Thanks a lot for the thoughtful feedback! We'll add this to the notes for when this feature gets some development time again 👍

@Bun Thanks a lot for the thoughtful feedback! We'll add this to the notes for when this feature gets some development time again 👍

Is there any progress in this problem? I'm using blender 3.2 right now, and the 1kk poly mesh trim operation just ate 26gb of RAM and 99% of CPU in seconds and froze blender.

AMD Ryzen 5 3600, 32gb ddr4, nvidia geforce RTX 3070TI.

Is there any progress in this problem? I'm using blender 3.2 right now, and the 1kk poly mesh trim operation just ate 26gb of RAM and 99% of CPU in seconds and froze blender. AMD Ryzen 5 3600, 32gb ddr4, nvidia geforce RTX 3070TI.
Member

The good news is that I have actively started implementing the Ember boolean algorithm that I mentioned about 9 months ago in this conversation. It promises to be maybe 100x faster than the current Exact Boolean. However, doing a new boolean is a major undertaking, so don't expect this for probably 6 months (sorry), unless I find a lot of spare time (I'm a volunteer Blender developer, with another full-time job that takes up my days). I may have found a partner to help, and that partner has much more free time, so if I am successful there, this may go faster.

The good news is that I have actively started implementing the Ember boolean algorithm that I mentioned about 9 months ago in this conversation. It promises to be maybe 100x faster than the current Exact Boolean. However, doing a new boolean is a major undertaking, so don't expect this for probably 6 months (sorry), unless I find a lot of spare time (I'm a volunteer Blender developer, with another full-time job that takes up my days). I may have found a partner to help, and that partner has much more free time, so if I am successful there, this may go faster.

@howardt That sounds great, Howard! I'm glad it's on the radar. You all are doing a fantastic job and I realize there are other priorities with day-to-day work. Hopefully the Blender Foundation will take you on full time someday. Have a great week ahead! :-)

@howardt That sounds great, Howard! I'm glad it's on the radar. You all are doing a fantastic job and I realize there are other priorities with day-to-day work. Hopefully the Blender Foundation will take you on full time someday. Have a great week ahead! :-)

It seems a problem with the trim implementation and no with the boolean algorithm, you can try to use the boolean modifier in a 500k mesh, in my computer it takes less than 10 seconds to compute the operation and to apply the modier and it is more or less same time with the carver addon but it takes several minutes to trim the same mesh with the sculpt tool.

It seems a problem with the trim implementation and no with the boolean algorithm, you can try to use the boolean modifier in a 500k mesh, in my computer it takes less than 10 seconds to compute the operation and to apply the modier and it is more or less same time with the carver addon but it takes several minutes to trim the same mesh with the sculpt tool.
Member

You probably tried the modifier with the "fast" mode, not the "exact" mode that I believe the sculpt tool uses.
Am a still actively working on the very fast Ember exact algorithm implementation, but unfortunately it is taking longer that I had hoped. Probably another couple of months at least before I might be able to release even an experimental version of it.

You probably tried the modifier with the "fast" mode, not the "exact" mode that I believe the sculpt tool uses. Am a still actively working on the very fast Ember exact algorithm implementation, but unfortunately it is taking longer that I had hoped. Probably another couple of months at least before I might be able to release even an experimental version of it.

Yes sorry, i was using the exact mode, with fast it takes a couple of seconds, I suppose carver uses the exact mode because it takes almost the same time too, to me the problem with the modifier starts with more dense meshes, >10M could take more than a minute to compute in exact mode, more than 30 minutes with the trim tool.

Yes sorry, i was using the exact mode, with fast it takes a couple of seconds, I suppose carver uses the exact mode because it takes almost the same time too, to me the problem with the modifier starts with more dense meshes, >10M could take more than a minute to compute in exact mode, more than 30 minutes with the trim tool.
Contributor

While work is continuing on Howard's side for the EMBER exact algorithm, I'm starting to look at some short-term fixes to make the tool more usable. I have a PR to add the option of choosing to use the Fast solver for trim operations linked above. I'm also planning on taking a look at the overall performance of the Trim tools outside of the boolean solvers to see if there's further areas to improve.

While work is continuing on Howard's side for the EMBER exact algorithm, I'm starting to look at some short-term fixes to make the tool more usable. I have a PR to add the option of choosing to use the Fast solver for trim operations linked above. I'm also planning on taking a look at the overall performance of the Trim tools outside of the boolean solvers to see if there's further areas to improve.
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 Assignees
18 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#84229
No description provided.