VSE: Strips Design Tweaks #118288

New Issue

Closed

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

Pablo Vazquez commented 2024-02-14 18:55:20 +01:00

Member

Copy Link

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:

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.

State: Disabled/Muted

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.

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.

State: Locked

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

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

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:

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

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.

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

Combined

Locked + Missing data-block

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:  ## 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.  ## State: Disabled/Muted 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. 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.  ## State: Locked Currently, locked strips draw diagonal lines over the entire strip, covering the labels which hurts readability.  Proposal is to keep the diagonal lines, but draw them below the header/labels:  ## 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:  Metastrips with both missing media and data-blocks show both icons:  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.   Additionally, we could add new Select operators to find the problematic strips more easily:  ## Combined Locked + Missing data-block  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.

image.png

98 KiB

image.png

571 KiB

image.png

165 KiB

image.png

458 KiB

image.png

207 KiB

image.png

31 KiB

image.png

113 KiB

image.png

63 KiB

image.png

38 KiB

image.png

103 KiB

image.png

1.3 MiB

image.png

36 KiB

👍 4 ❤️ 6

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

Aras Pranckevicius commented 2024-02-14 20:57:28 +01:00

Member

Copy Link

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.

Nika Kutsniashvili commented 2024-02-14 21:27:30 +01:00

Contributor

Copy Link

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.

Iliya Katushenock commented 2024-02-14 21:34:32 +01:00

Member

Copy Link

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?

Aras Pranckevicius commented 2024-02-15 05:58:05 +01:00

Member

Copy Link

@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).

Aras Pranckevicius commented 2024-02-15 08:21:57 +01:00

Member

Copy Link

@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 ?

👍 1

Pablo Vazquez commented 2024-02-15 12:47:07 +01:00

Author

Member

Copy Link

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.

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?

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:

...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?

> 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.  > 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?  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:  ...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? 

image.png

105 KiB

image.png

140 KiB

image.png

31 KiB

image.png

27 KiB

👍 2

Aras Pranckevicius self-assigned this 2024-02-19 15:52:13 +01:00

Aras Pranckevicius commented 2024-02-21 20:08:08 +01:00

Member

Copy Link

@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

Aras Pranckevicius referenced this issue 2024-02-21 20:37:53 +01:00

VSE: Timeline strip visual design updates #118581

Pablo Vazquez commented 2024-02-23 12:00:40 +01:00

Author

Member

Copy Link

@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:

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:  So no, no transparency. Sorry for the confusion.

Aras Pranckevicius commented 2024-03-01 09:47:00 +01:00

Member

Copy Link

@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?

@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

15 KiB

👍 1

ok what commented 2024-03-01 12:12:55 +01:00

Contributor

Copy Link

@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).

👍 1

Pablo Vazquez commented 2024-03-04 11:30:27 +01:00

Author

Member

Copy Link

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.

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.  These two sections never overlap, the background of the header should not be see-through, in order to preserve readability.

image.png

60 KiB

👍 2

tintwotin commented 2024-03-12 12:35:26 +01:00

Copy Link

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.

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.png

50 KiB

tintwotin commented 2024-03-18 06:56:45 +01:00

Copy Link

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.

• 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.  - 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?

saturation.gif

4.6 MiB

tintwotin referenced this issue 2024-03-31 06:21:14 +02:00

VSE: Timeline strip visual design updates #118581

Aras Pranckevicius referenced this issue from a commit 2024-04-24 12:37:49 +02:00

VSE: Timeline strip visual design updates

Aras Pranckevicius referenced this issue 2024-04-24 18:15:15 +02:00

VSE: indicate missing media in timeline/display #116869

Pablo Vazquez commented 2024-04-24 20:01:39 +02:00

Author

Member

Copy Link

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!

Pablo Vazquez closed this issue 2024-04-24 20:01:43 +02:00

Blender Bot added the

Status

Archived

label 2024-04-24 20:01:45 +02:00

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

main

brush-assets-project

fix-121021

blender-v4.1-release

blender-v3.3-release

blender-v3.6-release

universal-scene-description

blender-v3.6-temp_wmoss_animrig_public

temp-sculpt-dyntopo

gpencil-next

anim/animation-id-113594

blender-v4.0-release

blender-projects-basics

bridge-curves

sculpt-blender

asset-browser-frontend-split

asset-shelf

tmp-usd-python-mtl

tmp-usd-3.6

blender-v3.5-release

blender-v2.93-release

realtime-clock

sculpt-dev

bevelv2

xr-dev

v4.1.1

v3.6.11

v3.3.18

v4.1.0

v3.3.17

v3.6.10

v3.6.9

v3.3.16

v3.6.8

v3.6.7

v3.3.14

v4.0.2

v4.0.1

v4.0.0

v3.6.5

v3.3.12

v3.6.4

v3.6.3

v3.3.11

v3.6.2

v3.3.10

v3.6.1

v3.3.9

v3.6.0

v3.3.8

v3.3.7

v2.93.18

v3.5.1

v3.3.6

v2.93.17

v3.5.0

v2.93.16

v3.3.5

v3.3.4

v2.93.15

v2.93.14

v3.3.3

v2.93.13

v2.93.12

v3.4.1

v3.3.2

v3.4.0

v3.3.1

v2.93.11

v3.3.0

v3.2.2

v2.93.10

v3.2.1

v3.2.0

v2.83.20

v2.93.9

v3.1.2

v3.1.1

v3.1.0

v2.83.19

v2.93.8

v3.0.1

v2.93.7

v3.0.0

v2.93.6

v2.93.5

v2.83.18

v2.93.4

v2.93.3

v2.83.17

v2.93.2

v2.93.1

v2.83.16

v2.93.0

v2.83.15

v2.83.14

v2.83.13

v2.92.0

v2.83.12

v2.91.2

v2.83.10

v2.91.0

v2.83.9

v2.83.8

v2.83.7

v2.90.1

v2.83.6.1

v2.83.6

v2.90.0

v2.83.5

v2.83.4

v2.83.3

v2.83.2

v2.83.1

v2.83

v2.82a

v2.82

v2.81a

v2.81

v2.80

v2.80-rc3

v2.80-rc2

v2.80-rc1

v2.79b

v2.79a

v2.79

v2.79-rc2

v2.79-rc1

v2.78c

v2.78b

v2.78a

v2.78

v2.78-rc2

v2.78-rc1

v2.77a

v2.77

v2.77-rc2

v2.77-rc1

v2.76b

v2.76a

v2.76

v2.76-rc3

v2.76-rc2

v2.76-rc1

v2.75a

v2.75

v2.75-rc2

v2.75-rc1

v2.74

v2.74-rc4

v2.74-rc3

v2.74-rc2

v2.74-rc1

v2.73a

v2.73

v2.73-rc1

v2.72b

2.72b

v2.72a

v2.72

v2.72-rc1

v2.71

v2.71-rc2

v2.71-rc1

v2.70a

v2.70

v2.70-rc2

v2.70-rc

v2.69

v2.68a

v2.68

v2.67b

v2.67a

v2.67

v2.66a

v2.66

v2.65a

v2.65

v2.64a

v2.64

v2.63a

v2.63

v2.61

v2.60a

v2.60

v2.59

v2.58a

v2.58

v2.57b

v2.57a

v2.57

v2.56a

v2.56

v2.55

v2.54

v2.53

v2.52

v2.51

v2.50

v2.49b

v2.49a

v2.49

v2.48a

v2.48

v2.47

v2.46

v2.45

v2.44

v2.43

v2.42a

v2.42

v2.41

v2.40

v2.37a

v2.37

v2.36

v2.35a

v2.35

v2.34

v2.33a

v2.33

v2.32

v2.31a

v2.31

v2.30

v2.28c

v2.28a

v2.28

v2.27

v2.26

v2.25

Labels

Clear labels   

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

This issue affects/is about backward or forward 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

Issues relating to Wayland windowing support.

  

Interest

Workbench

  

Interest: X11

Issues relating to Xorg/X11 support.

  

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

Issues relating to security: https://wiki.blender.org/wiki/Process/Vulnerability_Reports

  

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 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

Milestone

Clear milestone

No items

No Milestone

Projects

Clear projects

No project

Video Sequencer

Assignees

Clear assignees

No Assignees

Aras Pranckevicius

6 Participants

Notifications

Subscribe

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.