VSE: Strips Design Tweaks #118288

Closed
opened 2024-02-14 18:55:20 +01:00 by Pablo Vazquez · 14 comments
Member

Following the discussion from #116821, it is clear that strips have multiple states that often clash with each other, and introducing yet another one (missing media) is making it worst.

This is not meant as a full re-design of strips (that could be part of the VSE 2.0 project #78986), it's intended to address these issues doing minimal changes, and serve as guideline for the future.

The following proposal has been discussed already with @fsiddi and @Sergey.


Strips have the following states:

  • Regular
  • Disabled
  • Locked
  • Missing Data-block
  • Missing Media (soon)

Plus all the usual selection (active, selected) states, and combinations of them.

Regular State

The overall design of strips in their regular state stays as it is. The only small tweaks that would help are:

  • Text labels always light, just a bit dim (75% in the mockup) when not selected or active. The current mix of black/white is confusing and hard to read, and the active status is already communicated by the bright outline.
  • The outline color of the strip follows the strip type (or a darker version of it, as in the mockup below).
  • Active/selected status is communicated with an additional outline and the labels at 100% opacity.

Proposal on the left, current main on the right:
regular proposal on the left, current main on the right

Anatomy of a Strip

A strip is divided in two non-overlapping sections:

  1. Header: A full-width band at the top of each strip, containing information as text and icons. Its height is defined by the label font size plus some padding. At the moment the header displays too much info by default: strip title, path, and length in frames. By default it should just show the strip title (which is often derived from the path anyway). Other info can be enabled back by the user of course.

  2. Preview: The bottom part of the strip, containing a preview the content such as image/video/scene thumbnail, waveform for sound strips, the content of a metastrip, etc. This is the section that reflects "missing media", or locked in time via diagonal lines as in the original mockups.

anatomy of a strip

State: Disabled/Muted

Currently, when a strip is disabled it becomes semi-transparent (except the thumbnails, which are drawn in full opacity).
disabled strips

This is not only hard to read, but also confusing when moving a disabled strip on top of others, you can see through which is unreadable and gets on the way.

The proposal is to draw disabled strips:

  • Fully opaque, like regular strips.
  • Override their color with gray (this will require changing the theme for Color strips, a separate patch).
  • Media/thumbnail and labels half transparent, as shown in the mockup below.

disabled strips proposal

State: Locked

Currently, locked strips draw diagonal lines over the entire strip, covering the labels which hurts readability.
current look of locked strip

Proposal is to keep the diagonal lines, but draw them below the header/labels:
locked strips proposal

State: Missing Media or Data-block

Currently, strips with missing data-block have a red header. Missing media is work-in-progress in #116869.

Both states have a similar outcome: content is not visible, requires attention. So both will be drawn similarly just with a different indicator.

Proposal is to:

  • Draw the header in dark red, and the media area in darker red.
  • Draw an icon to indicate missing media (ERROR) or missing data-block (LIBRARY_DATA_BROKEN).
  • Metastrips with missing content have a red header, and the problematic strips in red. Plus the corresponding icon.

Mockup:
missing data

Metastrips with both missing media and data-blocks show both icons:
metastrip with missing both media and data-blocks

Drawing an icon might not be enough when the strips are too narrow to fit, so we could also draw an indicator over the time topbar.

red line indicator over time

red line when strips are too small

Additionally, we could add new Select operators to find the problematic strips more easily:
Select Missing

Combined

Locked + Missing data-block
Locked, Missing Data-block

Disabled + Missing Media
Disabled, Missing Media


Conclusion

The idea is to help @aras_p land #116869 with as little cosmetic changes as possible. I know icons in strips are something new but hopefully @Harley can help Aras if needed.

Why not using magenta for missing data? Red is the universal hue for things that are wrong. Blender uses magenta only for missing textures/shaders when rendering, every other error/alert is red.

Following the discussion from #116821, it is clear that strips have multiple states that often clash with each other, and introducing yet another one (missing media) is making it worst. **This is not meant as a full re-design** of strips (that could be part of the VSE 2.0 project #78986), it's intended to address these issues doing minimal changes, and serve as guideline for the future. The following proposal has been discussed already with @fsiddi and @Sergey. ---- Strips have the following states: * Regular * Disabled * Locked * Missing Data-block * Missing Media (soon) Plus all the usual selection (active, selected) states, and combinations of them. ## Regular State The overall design of strips in their regular state stays as it is. The only small tweaks that would help are: * Text labels always light, just a bit dim (75% in the mockup) when not selected or active. The current mix of black/white is confusing and hard to read, and the active status is already communicated by the bright outline. * The outline color of the strip follows the strip type (or a darker version of it, as in the mockup below). * Active/selected status is communicated with an additional outline and the labels at 100% opacity. Proposal on the left, current main on the right: ![regular proposal on the left, current main on the right](/attachments/3298829f-888b-45f5-af07-f4b348c58389) ## Anatomy of a Strip A strip is divided in two non-overlapping sections: 1. **Header**: A full-width band at the top of each strip, containing information as text and icons. Its height is defined by the label font size plus some padding. At the moment the header displays too much info by default: strip title, path, and length in frames. By default it should just show the strip title (which is often derived from the path anyway). Other info can be enabled back by the user of course. 2. **Preview**: The bottom part of the strip, containing a preview the content such as image/video/scene thumbnail, waveform for sound strips, the content of a metastrip, etc. This is the section that reflects "missing media", or locked in time via diagonal lines as in the original mockups. ![anatomy of a strip](/attachments/5f27a9f9-df36-4529-8264-f3932f40e14a) ## State: Disabled/Muted Currently, when a strip is disabled it becomes semi-transparent (except the thumbnails, which are drawn in full opacity). ![disabled strips](/attachments/b9938569-c207-4610-9540-ccda2e0707e5) This is not only hard to read, but also confusing when moving a disabled strip on top of others, you can see through which is unreadable and gets on the way. The proposal is to draw disabled strips: * Fully opaque, like regular strips. * Override their color with gray (this will require changing the theme for Color strips, a separate patch). * Media/thumbnail and labels half transparent, as shown in the mockup below. ![disabled strips proposal](/attachments/c5e38724-e394-4ccf-bda2-ffd8dd15365a) ## State: Locked Currently, locked strips draw diagonal lines over the entire strip, covering the labels which hurts readability. ![current look of locked strip](/attachments/7e4eb295-60ec-4985-9e8e-d0a4beeb4943) Proposal is to keep the diagonal lines, but draw them below the header/labels: ![locked strips proposal](/attachments/008e772d-7998-4d47-a31f-ffeaffb41d08) ## State: Missing Media or Data-block Currently, strips with missing data-block have a red header. Missing media is work-in-progress in #116869. Both states have a similar outcome: content is not visible, requires attention. So both will be drawn similarly just with a different indicator. Proposal is to: * Draw the header in dark red, and the media area in darker red. * Draw an icon to indicate missing media (`ERROR`) or missing data-block (`LIBRARY_DATA_BROKEN`). * Metastrips with missing content have a red header, and the problematic strips in red. Plus the corresponding icon. Mockup: ![missing data](/attachments/210d0f7c-b347-4538-a81c-6aa804ea3c2d) Metastrips with both missing media and data-blocks show both icons: ![metastrip with missing both media and data-blocks](/attachments/5621e76f-732d-43a1-b341-69fe8e304e5c) Drawing an icon might not be enough when the strips are too narrow to fit, so we could also draw an indicator over the time topbar. ![red line indicator over time](/attachments/50512206-8c8d-46ef-b795-3c7fb205c05a) ![red line when strips are too small](/attachments/a1d3d274-5873-4c46-ba43-4e2a780edb6d) Additionally, we could add new Select operators to find the problematic strips more easily: ![Select Missing](/attachments/4489a248-669a-45ba-9e72-29c4e155df6b) ## Combined Locked + Missing data-block ![Locked, Missing Data-block](/attachments/d09614bd-d311-470d-af05-0798cb9c8d59) Disabled + Missing Media ![Disabled, Missing Media](/attachments/b2ccf3bd-1ee1-4801-acfb-99b1ec638081) ---- ## Conclusion The idea is to help @aras_p land #116869 with as little cosmetic changes as possible. I know icons in strips are something new but hopefully @Harley can help Aras if needed. Why not using magenta for missing data? Red is the universal hue for things that are wrong. Blender uses magenta only for missing textures/shaders when rendering, every other error/alert is red.
Pablo Vazquez added the
Interest
User Interface
Module
VFX & Video
Type
Design
labels 2024-02-14 18:55:20 +01:00
Pablo Vazquez added this to the Video Sequencer project 2024-02-14 18:55:23 +01:00

This looks great! But looking at the design mockups, my questions are about... the rounded corners lol :)

IMHO, the very slightly rounded corners do make the overall look much better. But, they are more complex to draw than just "a rectangle". So the question is, do we want these rounded corners? These might require some thinking, e.g. how do make it so that the thumbnail is properly "clipped" by the rounded corner, etc. And how to draw them efficiently (might need a new shader), etc. All of that is doable and probably Not Terribly Hard (famous last words), but the question is, do we want them.

This looks great! But looking at the design mockups, my questions are about... the rounded corners lol :) IMHO, the very slightly rounded corners *do* make the overall look much better. But, they are more complex to draw than just "a rectangle". So the question is, do we *want* these rounded corners? These might require some thinking, e.g. how do make it so that the thumbnail is properly "clipped" by the rounded corner, etc. And how to draw them efficiently (might need a new shader), etc. All of that is doable and probably Not Terribly Hard (famous last words), but the question is, do we want them.
Contributor

On the mockups I think rounding is only on outside line, inside thumbnails are still square. That could work.

On the mockups I think rounding is only on outside line, inside thumbnails are still square. That could work.

IMHO, the very slightly rounded corners do make the overall look much better. But, they are more complex to draw than just "a rectangle". So the question is, do we want these rounded corners?

My first (and last (incomplete (pretty raw)) ;) ) OpenGL program was UI with round rectangles. Don't want to say it is something so basic, but, for example, node editor is only round rectangles. What I'm afraid of is the padding for this new overlay.

EDIT: Doesn’t Blender already make the entire interface rounded?

> IMHO, the very slightly rounded corners do make the overall look much better. But, they are more complex to draw than just "a rectangle". So the question is, do we want these rounded corners? My first (and last (incomplete (pretty raw)) ;) ) OpenGL program was UI with round rectangles. Don't want to say it is something so basic, but, for example, node editor is only round rectangles. What I'm afraid of is the padding for this new overlay. EDIT: Doesn’t Blender already make the entire interface rounded?

@nickberckley @mod_moder rounded corners are possible to do, I'm just trying to clarify whether they are implied by this design (judging from the screenshots), or not (since the text never mentions them).

@nickberckley @mod_moder rounded corners are possible to do, I'm just trying to clarify whether they are implied by this design (judging from the screenshots), or not (since the text never mentions them).

@pablovazquez another question I have, how/if does this interact with the strip resizing "handles". Right now these are just "wider" rectangles on either side of the strip. With the proposed very-slightly-rounded corners, and the active outline that goes beyond the strip rectangle, does it affect the resizing handles in any way? Should they continue to be where they are, or be drawn in the space between strip and the outline?

And/or does that interact with the WIP handle drawing visual change over at #109522 ?

@pablovazquez another question I have, how/if does this interact with the strip resizing "handles". Right now these are just "wider" rectangles on either side of the strip. With the proposed very-slightly-rounded corners, and the active outline that goes beyond the strip rectangle, does it affect the resizing handles in any way? Should they continue to be where they are, or be drawn in the space between strip and the outline? And/or does that interact with the WIP handle drawing visual change over at #109522 ?
Author
Member

This looks great! But looking at the design mockups, my questions are about... the rounded corners lol :)

Knew this would come up, should’ve clarified :D

the very slightly rounded corners do make the overall look much better. But, they are more complex to draw than just "a rectangle"

For the sake of getting #116869 in main soon, let’s forget about rounded corners for now.

That being said…

I do think that rounded corners have a benefit other than just looking pretty, they communicate more clearly where a strip starts and ends, and allows for “breaking” that to communicate other elements such as transitions.

rounded corners with transition

how do make it so that the thumbnail is properly "clipped" by the rounded corner

Ideally yes, images would be masked by the rounded corner, but even without, if the image is slightly smaller then the gap between the thumbnail and the strip background could serve as outline?

smaller thumbnail

So to sum up, for the time being and even in the future if they affect performance in any way, let's just forget about it. I'd much rather have a responsive ugly timeline than a sluggish but slightly prettier one.


does it affect the resizing handles in any way?

I'm hoping we can couple this with #109522. Removing the dark overlay strips currently have and replace it with changing the mouse cursor on hover. With an indicator when the handle is active.

Should they continue to be where they are, or be drawn in the space between strip and the outline?

It'd probably have to be inside, outside looks good:
strip handles outside

...but it gets tricky when there are two handles of adjacent strips selected.

For the time being and to move forward with the patch, they can continue as is. If we find the motivation it'd be great to look into drawing it between the strip and outline, perhaps as part of #109522 or a larger re-design?

strip handles

> This looks great! But looking at the design mockups, my questions are about... the rounded corners lol :) Knew this would come up, should’ve clarified :D > the very slightly rounded corners do make the overall look much better. But, they are more complex to draw than just "a rectangle" For the sake of getting #116869 in main soon, let’s forget about rounded corners for now. That being said… I do think that rounded corners have a benefit other than just looking pretty, they communicate more clearly where a strip starts and ends, and allows for “breaking” that to communicate other elements such as transitions. ![rounded corners with transition](/attachments/d9ab23ad-dace-4812-b09e-c1d2ee0f1263) > how do make it so that the thumbnail is properly "clipped" by the rounded corner Ideally yes, images would be masked by the rounded corner, but even without, if the image is slightly smaller then the gap between the thumbnail and the strip background could serve as outline? ![smaller thumbnail](/attachments/8893c23f-1e3b-4736-99b6-843afbd02e3e) So to sum up, for the time being and even in the future if they affect performance in any way, let's just forget about it. I'd much rather have a responsive ugly timeline than a sluggish but slightly prettier one. ---- > does it affect the resizing handles in any way? I'm hoping we can couple this with #109522. Removing the dark overlay strips currently have and replace it with changing the mouse cursor on hover. With an indicator when the handle is active. > Should they continue to be where they are, or be drawn in the space between strip and the outline? It'd probably have to be inside, outside looks good: ![strip handles outside](/attachments/9dcc155b-064a-484f-807e-2cfb79b44285) ...but it gets tricky when there are two handles of adjacent strips selected. For the time being and to move forward with the patch, they can continue as is. If we find the motivation it'd be great to look into drawing it between the strip and outline, perhaps as part of #109522 or a larger re-design? ![strip handles](/attachments/b8b04e7e-79d7-4839-8a3c-752338207108)
Aras Pranckevicius self-assigned this 2024-02-19 15:52:13 +01:00

@pablovazquez I have a question about this:

Currently, when a strip is disabled it becomes semi-transparent (except the thumbnails, which
are drawn in full opacity). <...> This is not only hard to read, but also confusing when moving a disabled
strip on top of others, you can see through which is unreadable and gets on the way.

Bbbbut... you yourself added "when overlapping other strips, draw the content transparent" three years ago (https://projects.blender.org/blender/blender/commit/f5cc34861076), with "It's convenient to see what's underneath" reasoning.

Did you change your mind? :P

@pablovazquez I have a question about this: > Currently, when a strip is disabled it becomes semi-transparent (except the thumbnails, which > are drawn in full opacity). <...> This is not only hard to read, but also confusing when moving a disabled > strip on top of others, you can see through which is unreadable and gets on the way. Bbbbut... you yourself added "when overlapping other strips, draw the content transparent" three years ago (https://projects.blender.org/blender/blender/commit/f5cc34861076), with "It's convenient to see what's underneath" reasoning. Did you change your mind? :P
Author
Member

@aras_p

Did you change your mind? :P

Short answer: Yes :D

Long answer: Kind of! While transparency helps a bit to see what's underneath, making the entire strip transparent ends up being not readable at all.

Then I thought okay the title/header should never be transparent, just the media, but a quick mockup proves it wrong:

transparent strips

So no, no transparency. Sorry for the confusion.

@aras_p > Did you change your mind? :P Short answer: Yes :D Long answer: Kind of! While transparency helps a bit to see what's underneath, making the entire strip transparent ends up being not readable at all. Then I thought okay the title/header should **never** be transparent, just the media, but a quick mockup proves it wrong: ![transparent strips](/attachments/8ff07887-5b0b-4c93-860a-527b5d2e92fe) So no, no transparency. Sorry for the confusion.

@pablovazquez question wrt "Metastrips with missing content have a red header, and the problematic strips in red. Plus the corresponding icon":

Today meta strips do not have a "header area", i.e. they do display the title (name), but the actual background of "strips contained within it" is drawn across the whole strip rectangle, not below the "header". Should that be changed so it is drawn below the header?

Screenshot 2024-03-01 at 10.45.25.png

@pablovazquez question wrt "Metastrips with missing content have a red header, and the problematic strips in red. Plus the corresponding icon": Today meta strips do not have a "header area", i.e. they do display the title (name), but the actual background of "strips contained within it" is drawn across the whole strip rectangle, not below the "header". Should that be changed so it is drawn below the header? ![Screenshot 2024-03-01 at 10.45.25.png](/attachments/de29d5c2-7b74-4469-91a4-fab9ff6e646e)
Contributor

@aras_p It's something I forgot to fix. The meta strip got a title area in #109472 but the visual change was accidentally reverted iirc in this commit.

@aras_p It's something I forgot to fix. The meta strip got a title area in #109472 but the visual change was accidentally reverted iirc in [this commit](https://projects.blender.org/blender/blender/commit/4d668e6825ac35b189b1bc4699aa1a43b42fcc03).
Author
Member

Today meta strips do not have a "header area", i.e. they do display the title (name), but the actual background of "strips contained within it" is drawn across the whole strip rectangle, not below the "header".
Should that be changed so it is drawn below the header?

Yes, the way I see it is that the "anatomy" of a strip is divided in two non-overlapping sections:

  1. Header: A full-width band at the top of each strip, containing information as text and icons. Its height is defined by the label font size plus some padding. At the moment the header displays too much info by default: strip title, path, and length in frames. By default it should just show the strip title (which is often derived from the path anyway). Other info can be enabled back by the user of course.

  2. Preview: The bottom part of the strip, containing a preview the content such as image/video/scene thumbnail, waveform for sound strips, the content of a metastrip, etc. This is the section that reflects "missing media", or locked in time via diagonal lines as in the original mockups.

anatomy of a strip

These two sections never overlap, the background of the header should not be see-through, in order to preserve readability.

> Today meta strips do not have a "header area", i.e. they do display the title (name), but the actual background of "strips contained within it" is drawn across the whole strip rectangle, not below the "header". > Should that be changed so it is drawn below the header? Yes, the way I see it is that the "anatomy" of a strip is divided in two non-overlapping sections: 1. **Header**: A full-width band at the top of each strip, containing information as text and icons. Its height is defined by the label font size plus some padding. At the moment the header displays too much info by default: strip title, path, and length in frames. By default it should just show the strip title (which is often derived from the path anyway). Other info can be enabled back by the user of course. 2. **Preview**: The bottom part of the strip, containing a preview the content such as image/video/scene thumbnail, waveform for sound strips, the content of a metastrip, etc. This is the section that reflects "missing media", or locked in time via diagonal lines as in the original mockups. ![anatomy of a strip](/attachments/5f27a9f9-df36-4529-8264-f3932f40e14a) These two sections never overlap, the background of the header should not be see-through, in order to preserve readability.

In this design, how does the user know what strip is the active strip (w. exposed values in the sidebar), if no strips are selected, and therefore have no outline?

In this design, all strips have white texts, previously only the active strip had a white text and thereby indicated which strip was the active strip.
image

In this design, how does the user know what strip is the active strip (w. exposed values in the sidebar), if no strips are selected, and therefore have no outline? In this design, all strips have white texts, previously only the active strip had a white text and thereby indicated which strip was the active strip. ![image](/attachments/80a2675d-37bf-412d-aea4-a217036b13c3)

Looking at the saturation levels of @aras_p latest update, as the most saturated elements gets the most attention. And IMHO should the active/selected elements get the most attention.

saturation.gif

  • Looking at this, it seems to me that the selection outlines(active+selected), needs to be the most saturated, and they're not.
  • The selected-outline(orange) is less saturated than the texts of unselected strips and tag colors, they shouldn't.
  • The color tag colors are far too saturated. (NB. if changed, the source strips have one saturation level and the effect strips have another, so the color tags saturation levels need to stay clear of those)
  • The waveforms and thumbnails are the most saturated, we properly can't make the thumbnails less saturated, maybe the waveforms could be less saturated than selection outlines, or the waveforms could get more saturated when selected/active?
Looking at the saturation levels of @aras_p latest update, as the most saturated elements gets the most attention. And IMHO should the active/selected elements get the most attention. ![saturation.gif](/attachments/74fbe7c4-8bf3-46eb-b6e1-b4d5734826f2) - Looking at this, it seems to me that the selection outlines(active+selected), needs to be the most saturated, and they're not. - The selected-outline(orange) is less saturated than the texts of unselected strips and tag colors, they shouldn't. - The color tag colors are far too saturated. (NB. if changed, the source strips have one saturation level and the effect strips have another, so the color tags saturation levels need to stay clear of those) - The waveforms and thumbnails are the most saturated, we properly can't make the thumbnails less saturated, maybe the waveforms could be less saturated than selection outlines, or the waveforms could get more saturated when selected/active?
Author
Member

In this design, how does the user know what strip is the active strip (w. exposed values in the sidebar), if no strips are selected, and therefore have no outline?

Good point, thanks! Addressed via !121029

  • The color tag colors are far too saturated. (NB. if changed, the source strips have one saturation level and the effect strips have another, so the color tags saturation levels need to stay clear of those)
  • The waveforms and thumbnails are the most saturated, we properly can't make the thumbnails less saturated, maybe the waveforms could be less saturated than selection outlines, or the waveforms could get more saturated when selected/active?

I agree. This could be tackled as its own task, since it's related mostly to theme (except the waveforms). The default values for color tags need to be revisited, that issue was highlighted in the re-design PR.

I will close this since most of the issues have been tackled and are now part of main (yay!)

Thanks Aras and everyone for the feedback!

> In this design, how does the user know what strip is the active strip (w. exposed values in the sidebar), if no strips are selected, and therefore have no outline? Good point, thanks! Addressed via !121029 > - The color tag colors are far too saturated. (NB. if changed, the source strips have one saturation level and the effect strips have another, so the color tags saturation levels need to stay clear of those) > - The waveforms and thumbnails are the most saturated, we properly can't make the thumbnails less saturated, maybe the waveforms could be less saturated than selection outlines, or the waveforms could get more saturated when selected/active? I agree. This could be tackled as its own task, since it's related mostly to theme (except the waveforms). The default values for color tags need to be revisited, that issue was highlighted in the re-design PR. I will close this since most of the issues have been tackled and are now part of main (yay!) Thanks Aras and everyone for the feedback!
Blender Bot added the
Status
Archived
label 2024-04-24 20:01:45 +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
6 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#118288
No description provided.