Outliner Visibility Update #61578

New Issue

Closed

opened 2019-02-15 14:33:21 +01:00 by William Reynish · 94 comments

William Reynish commented 2019-02-15 14:33:21 +01:00

Copy Link

(NOTE) Note: This topic is only about visibility toggling. The Outliner as a whole could use a lot of other improvements, but those are outside the scope of this task.

We have just concluded a UI-meeting in which we discussed the topic of the visibility states and how they relate to the Outliner in Blender 2.8. This task will attempt to communicate our conclusions.

Issues

We started by identifying the biggest current problems related to visibility states:

• It’s still not clear enough when to use our various visibility states
  • (Show/Hide vs Enable/Disable vs Include/Exclude vs Local View)
• Some useful toggles are too difficult to find
  • Namely how to set instanced visibility and how to include & exclude Collections)
• It’s too much of a hassle to make sure the viewport visibility matches the render visibility.
  • Users who just use the eye toggle are surprised when they hit Render, and they see a totally different list of items.’
• Some toggles affect the depsgraph performance and some not.
  • This is not clear, and should this even be the case?

(NOTE) Starting with the last issue related to the depsgraph: This can be solved in the depsgraph itself, so that using show/hide (eye icon) is as performant as when disabling(screen icon). It turns out this is not a fundamental problem, but simply something to be added to the depsgraph evaluation

The rest of the issues, we think we can solve them by making a few changes only on the UI layer:

Emphasis

Most of the issues can be solved simply by slightly changing the emphasis of which features we make more or less prominent for users. For example, the ability to completely enable or disable collections (include/exclude) is very generally useful. It’s akin to using the old layers in 2.7x and earlier, where toggling layers would affect both the viewport and the renderer. However, it's completely hidden behind the shortcuts E and Alt-E.

An opposite example would be the instanced visibility feature (Currently represented by the screen icon). This is a very obscure, advanced feature that is only applicable in in certain projects which make heavy use of linking.

We want to make sure Blender is clear and easy to use out of the box for simpler projects, while still including advanced features that more advanced users or complex projects.

Here’s what we would like to change:

• Make the Include/Exclude state discoverable and obvious. Currently the only way to use this is via the hidden shortcuts E and Alt-E.
• Add a more granular way to filter which restriction columns you see in the Outliner
  • By default, only show the most basic ones (probably Include/exclude (checkbox), selectability(cursor) and show/hide (eye)

In the Filter popover, we could add settings to enable each restriction column separately, like so:

Alternate, clearer popover UI:

By default, this is what we expect you will see in the Outliner:

The checkmarks (include/exclude) for enabling or disabling Collections completely. Selectability toggles and viewport toggles. This is all the vast majority of users will need to worry about.

However, you could enable all the restriction columns and get this:

Naming

A big part of what is confusing about the current system, is that the naming is unclear. Show/Hide only applies to the viewport, and the enabled/disabled states have to do with instancing, which is not communicated. Here are the name changes that should clarify what they do:

Old Names	New Names
Show/Hide	Viewport Visibility On/Off
Enable/Disable	Instance Visibility On/Off
Include/Exclude	Enable/Disable

This leaves us with the following:

• Enabled/Disabled
• Selectable On/Off
• Viewport Visibility On/Off
• Render Visibility On/Off
• Instance Visibility On/Off

Icons

To go with the above name clarifications, the icons should go along with those too. Here are some examples:
The only needed differences is the use of the checkmark for include/Exclude, and the link icon for instanced visibility:

Open questions:

• Should we make it possible to Include & exclude items (check mark) on the object level too?
• Instanced Visibility (previously Enable/Disable) currently affects both the instanced visibility, AND the local, non-instanced visibility too. This is actually a problem if you use it for its intended purpose, such as hiding an Armature in the instance but not in the source Collection. More appropriate would probably be to make it ONLY affect visibility in the instance, not the source.

(NOTE) *Note: This topic is only about visibility toggling. The Outliner as a whole could use a lot of other improvements, but those are outside the scope of this task.* We have just concluded a UI-meeting in which we discussed the topic of the visibility states and how they relate to the Outliner in Blender 2.8. This task will attempt to communicate our conclusions. ## Issues We started by identifying the biggest current problems related to visibility states: * It’s still not clear enough when to use our various visibility states * (Show/Hide vs Enable/Disable vs Include/Exclude vs Local View) * Some useful toggles are too difficult to find * Namely how to set instanced visibility and how to include & exclude Collections) * It’s too much of a hassle to make sure the viewport visibility matches the render visibility. * Users who just use the eye toggle are surprised when they hit Render, and they see a totally different list of items.’ * Some toggles affect the depsgraph performance and some not. * This is not clear, and should this even be the case? (NOTE) *Starting with the last issue related to the depsgraph: This can be solved in the depsgraph itself, so that using show/hide (eye icon) is as performant as when disabling(screen icon). It turns out this is not a fundamental problem, but simply something to be added to the depsgraph evaluation* The rest of the issues, we think we can solve them by making a few changes only on the UI layer: ## Emphasis Most of the issues can be solved simply by slightly changing the emphasis of which features we make more or less prominent for users. For example, the ability to completely enable or disable collections (include/exclude) is very generally useful. It’s akin to using the old layers in 2.7x and earlier, where toggling layers would affect both the viewport and the renderer. However, it's completely hidden behind the shortcuts E and Alt-E. An opposite example would be the instanced visibility feature (Currently represented by the screen icon). This is a very obscure, advanced feature that is only applicable in in certain projects which make heavy use of linking. We want to make sure Blender is clear and easy to use out of the box for simpler projects, while still including advanced features that more advanced users or complex projects. Here’s what we would like to change: * Make the Include/Exclude state discoverable and obvious. Currently the only way to use this is via the hidden shortcuts E and Alt-E. * Add a more granular way to filter which restriction columns you see in the Outliner * By default, only show the most basic ones (probably Include/exclude (checkbox), selectability(cursor) and show/hide (eye) In the Filter popover, we could add settings to enable each restriction column separately, like so:  Alternate, clearer popover UI:  By default, this is what we expect you will see in the Outliner:  The checkmarks (include/exclude) for enabling or disabling Collections completely. Selectability toggles and viewport toggles. This is all the vast majority of users will need to worry about. However, you could enable all the restriction columns and get this:  ## Naming A big part of what is confusing about the current system, is that the naming is unclear. Show/Hide only applies to the viewport, and the enabled/disabled states have to do with instancing, which is not communicated. Here are the name changes that should clarify what they do: | *Old Names* | *New Names* | | -- | -- | | Show/Hide | Viewport Visibility On/Off | | Enable/Disable | Instance Visibility On/Off | | Include/Exclude | Enable/Disable | This leaves us with the following: * Enabled/Disabled * Selectable On/Off * Viewport Visibility On/Off * Render Visibility On/Off * Instance Visibility On/Off ## Icons To go with the above name clarifications, the icons should go along with those too. Here are some examples: The only needed differences is the use of the checkmark for include/Exclude, and the link icon for instanced visibility:  ## Open questions: - Should we make it possible to Include & exclude items (check mark) on the object level too? - Instanced Visibility (previously Enable/Disable) currently affects both the instanced visibility, **AND** the local, non-instanced visibility too. This is actually a problem if you use it for its intended purpose, such as hiding an Armature in the instance but *not* in the source Collection. More appropriate would probably be to make it **ONLY** affect visibility in the instance, not the source.

William Reynish commented 2019-02-15 14:33:21 +01:00

Author

Copy Link

Added subscriber: @WilliamReynish

Added subscriber: @WilliamReynish

William Reynish commented 2019-02-15 14:34:37 +01:00

Author

Copy Link

Added subscribers: @brecht, @pablovazquez, @Sergey, @JulienKaspar, @dfelinto

Added subscribers: @brecht, @pablovazquez, @Sergey, @JulienKaspar, @dfelinto

William Reynish commented 2019-02-15 16:32:48 +01:00

Author

Copy Link

Added subscriber: @jendrzych

Added subscriber: @jendrzych

Brecht Van Lommel commented 2019-02-15 17:08:35 +01:00

Owner

Copy Link

Instance visibility UI

If we hide instance and render visibility by default, I think we should still communicate to the users when these settings are off. When instance visibility is off we can replace the viewport visibility icon as we do already.

I'm not sure that should be a read-only thing or if alt+click should be kept (might as well?). For instancing the instance visibility is still an important setting, and it's not that advanced a use case. So hiding it entirely by default is not ideal.

At least it should be clear that toggling the viewport visibility is not possible in that case.

Render/viewport visibility distinction

The main thing that bothers me still is render visibility. The distinction between viewport and render is a common source of confusion for users. It doesn't work well in a workflow where you do a lot of viewport rendering and then do F12 at the end, only to get a different result. Currently I'm thinking we can make instance visibility affect both viewport and render.

Render visibility could remain as an object only (not collection) option, equivalent to disabling all Cycles ray visibility options and available in the same place in the properties editor. This option would affect both Cycles/Eevee viewport and final renders, but not workbench. That render visibility would be for helper objects that are never useful in renders, like physics or rigging helper objects. Basically to make a mesh have visibility like a lattice or armature.

One use case that current render/viewport visibility distinction can serve is level of detail, to have a low and high poly version of a mesh. Maybe for faster animation playback, or to do layout with a low poly version or even bounding boxes. I suspect the right distinction there is not between viewport and final render however. But rather between workbench/rendered display mode and different view layers. With simplify settings, bounds/wire display for workbench and per-view layer collection exclude I think level of detail distinction between viewport and final render are already covered.

### Instance visibility UI If we hide instance and render visibility by default, I think we should still communicate to the users when these settings are off. When instance visibility is off we can replace the viewport visibility icon as we do already. I'm not sure that should be a read-only thing or if alt+click should be kept (might as well?). For instancing the instance visibility is still an important setting, and it's not that advanced a use case. So hiding it entirely by default is not ideal. At least it should be clear that toggling the viewport visibility is not possible in that case. ### Render/viewport visibility distinction The main thing that bothers me still is render visibility. The distinction between viewport and render is a common source of confusion for users. It doesn't work well in a workflow where you do a lot of viewport rendering and then do F12 at the end, only to get a different result. Currently I'm thinking we can make instance visibility affect both viewport and render. Render visibility could remain as an object only (not collection) option, equivalent to disabling all Cycles ray visibility options and available in the same place in the properties editor. This option would affect both Cycles/Eevee viewport and final renders, but not workbench. That render visibility would be for helper objects that are never useful in renders, like physics or rigging helper objects. Basically to make a mesh have visibility like a lattice or armature. One use case that current render/viewport visibility distinction can serve is level of detail, to have a low and high poly version of a mesh. Maybe for faster animation playback, or to do layout with a low poly version or even bounding boxes. I suspect the right distinction there is not between viewport and final render however. But rather between workbench/rendered display mode and different view layers. With simplify settings, bounds/wire display for workbench and per-view layer collection exclude I think level of detail distinction between viewport and final render are already covered.

Duarte Farrajota Ramos commented 2019-02-15 17:18:15 +01:00

Copy Link

Added subscriber: @DuarteRamos

Added subscriber: @DuarteRamos

Marcus Papathoma commented 2019-02-15 17:38:06 +01:00

Copy Link

Added subscriber: @machieb

Added subscriber: @machieb

Dalai Felinto commented 2019-02-15 20:33:31 +01:00

Owner

Copy Link

I would add to it an option to hide the disabled collections in the filter.
I second what @brecht said, we need a way to tell that a collection (and object?) is not rendered since this is a big deal.

Should we make it possible to Include & exclude items (check mark) on the object level too?

I would say, no. The least options we have per object the better I think.

I would add to it an option to hide the disabled collections in the filter. I second what @brecht said, we need a way to tell that a collection (and object?) is not rendered since this is a big deal. > Should we make it possible to Include & exclude items (check mark) on the object level too? I would say, no. The least options we have per object the better I think.

William Reynish commented 2019-02-16 13:47:33 +01:00

Author

Copy Link

@brecht

re. the render/viewport thing: That was also what the checkmark should solve - this applies to both the viewport and the render.
We can also just show the render visibility toggle by default, which will make the distinction clearer. Perhaps we should show check mark, viewport visibility and render visibility by default. Selectability and Instance visibility can then be hidden by default.

Also:
The more I think about it, the Instanced Visibility toggle should not actually make something invisible, unless it's being instanced. In the common use-cases of boolean objects and armatures, you want to be able to select and manipulate them inside the source Collection, but not be visible when instanced.

@brecht re. the render/viewport thing: That was also what the checkmark should solve - this applies to both the viewport and the render. We can also just show the render visibility toggle by default, which will make the distinction clearer. Perhaps we should show check mark, viewport visibility and render visibility by default. Selectability and Instance visibility can then be hidden by default. Also: The more I think about it, the Instanced Visibility toggle should not actually make something invisible, unless it's being instanced. In the common use-cases of boolean objects and armatures, you want to be able to select and manipulate them inside the source Collection, but not be visible when instanced.

Julien Kaspar commented 2019-02-16 16:43:38 +01:00

Member

Copy Link

@dfelinto

I would say, no. The least options we have per object the better I think.

I agree. We don't really need exclusion for objects so I think it can stay this way. Also if the eye improves the performance then there is really no need to add the checkmark for objects.

@WilliamReynish @brecht

I really like the idea to make the screen icon a kinda "instanced viewport visibility" toggle. It makes it clear what it's supposed to be used for. While thinking longer about it I have some questions/concerns though:

• Currently in Blender the screen icon (disable for viewport) & the camera icon (disable for render) are counterparts because they work very similarly (global & used for linking/instancing). If the eye & camera are supposed to be counterparts in this proposal then won't their different behaviour make things confusing? The eye is per view layer and is not used for linking to other files & instancing ... but the camera is.

The more I think about it, the Instanced Visibility toggle should not actually make something invisible, unless it's being instanced.

• I was thinking a lot over this one. There will need to be some restructuring of the Spring production files but only because a lot of the setups we use become a bit redundant. I think this might change things for the better.

In the asset files for Spring, this is a common setup right now (not the actual naming conventions):

We often keep the collections that we work on and the collections that we link/instance to other files separate. There are specific collections that we set to be disabled for the viewport or disabled for the render and we link the appropriate collections within them.
This way if you want to see how the asset will look when linked you can make the "Asset (for linking/instancing) visible and when you want to see or render the disabled collections you can make the "Asset (for working) visible.

If the screen is not overriding the eye icon anymore then it could become something more like this:

The only concern I have left about this change is the WYSIWYG. It's easy to know what will be disabled for the viewport when you already can't see it anymore.

• I think the link icon for "instanced visibility" is a bit confusing. What this icon tells me at a first glance is: "This object/collection won't be linked", instead of "This object/collection won't be visible in the viewport when used for instancing". The name "instanced visibility" at least implies the use for instancing but it doesn't specify that it will only hide things for the viewport and not the render. But this is more of a minor concern. Naming it something like "Instanced Viewport Visibility" might be long but more accurate. Good tooltips could also lift some confusion. I also don't know of a better icon so the link could be the best choice right now.

@dfelinto > I would say, no. The least options we have per object the better I think. I agree. We don't really need exclusion for objects so I think it can stay this way. Also if the eye improves the performance then there is really no need to add the checkmark for objects. @WilliamReynish @brecht I really like the idea to make the screen icon a kinda "instanced viewport visibility" toggle. It makes it clear what it's supposed to be used for. While thinking longer about it I have some questions/concerns though: - Currently in Blender the screen icon (disable for viewport) & the camera icon (disable for render) are counterparts because they work very similarly (global & used for linking/instancing). If the eye & camera are supposed to be counterparts in this proposal then won't their different behaviour make things confusing? The eye is per view layer and is not used for linking to other files & instancing ... but the camera is. > The more I think about it, the Instanced Visibility toggle should not actually make something invisible, unless it's being instanced. - I was thinking a lot over this one. There will need to be some restructuring of the Spring production files but only because a lot of the setups we use become a bit redundant. I think this might change things for the better. In the asset files for Spring, this is a common setup right now (not the actual naming conventions):  We often keep the collections that we work on and the collections that we link/instance to other files separate. There are specific collections that we set to be disabled for the viewport or disabled for the render and we link the appropriate collections within them. This way if you want to see how the asset will look when linked you can make the "Asset (for linking/instancing) visible and when you want to see or render the disabled collections you can make the "Asset (for working) visible. If the screen is not overriding the eye icon anymore then it could become something more like this:  The only concern I have left about this change is the WYSIWYG. It's easy to know what will be disabled for the viewport when you already can't see it anymore. - I think the link icon for "instanced visibility" is a bit confusing. What this icon tells me at a first glance is: "This object/collection won't be linked", instead of "This object/collection won't be visible in the viewport when used for instancing". The name "instanced visibility" at least implies the use for instancing but it doesn't specify that it will only hide things for the viewport and not the render. But this is more of a minor concern. Naming it something like "Instanced Viewport Visibility" might be long but more accurate. Good tooltips could also lift some confusion. I also don't know of a better icon so the link could be the best choice right now.

Albert commented 2019-02-17 12:21:19 +01:00

Copy Link

Added subscriber: @wevon-2

Added subscriber: @wevon-2

Albert commented 2019-02-17 12:21:19 +01:00

Copy Link

CollectionsResalte01.mp4
Because all the options of the collections are transferred to the objects inside, I suggest contrasting them with respect to the rest of the objects, and indicating their effect on their contents.
I guess the video is sufficiently explanatory. Although it is only a visual effect, I understand that it helps to understand the hierarchy of effects.

[CollectionsResalte01.mp4](https://archive.blender.org/developer/F6639275/CollectionsResalte01.mp4) Because all the options of the collections are transferred to the objects inside, I suggest contrasting them with respect to the rest of the objects, and indicating their effect on their contents. I guess the video is sufficiently explanatory. Although it is only a visual effect, I understand that it helps to understand the hierarchy of effects.

William Reynish commented 2019-02-17 12:33:44 +01:00

Author

Copy Link

@wevon-2 Yes, we should do proper greying out for all the toggles to help communicate the hierarchy. There are so many little details like this we should add.

@wevon-2 Yes, we should do proper greying out for all the toggles to help communicate the hierarchy. There are so many little details like this we should add.

Adriano Oliveira commented 2019-02-18 23:34:43 +01:00

Copy Link

Added subscriber: @AdrianoOliveira

Added subscriber: @AdrianoOliveira

Adriano Oliveira commented 2019-02-18 23:34:43 +01:00

Copy Link

I like the way this is going.

One big problem for most of the users is the "Unlink" collection/object from the Scene. It is like delleting it without a warning. You don't now to where it goes when unlinked, unless you have a deep understanding of Blender's data structure (most don't).

Unlink and Exclude are confusiong concepts too. I would prefere they are the same thing. I would prefere that an unlinked item from a Scene just shows in Outliner as Diseble.

If it is not possible, I would show a warning when a user tries to Unlink an item, like: "You are about to unlink this from the Scene. Are you shure?". Or a simple one, like when you are about to Delete.

I like the way this is going. One big problem for most of the users is the "Unlink" collection/object from the Scene. It is like delleting it without a warning. You don't now to where it goes when unlinked, unless you have a deep understanding of Blender's data structure (most don't). Unlink and Exclude are confusiong concepts too. I would prefere they are the same thing. I would prefere that an unlinked item from a Scene just shows in Outliner as Diseble. If it is not possible, I would show a warning when a user tries to Unlink an item, like: "You are about to unlink this from the Scene. Are you shure?". Or a simple one, like when you are about to Delete.

Harley Acheson commented 2019-02-19 00:21:31 +01:00

Member

Copy Link

Added subscriber: @Harley

Added subscriber: @Harley

Harley Acheson commented 2019-02-19 00:21:31 +01:00

Member

Copy Link

As a nitpic, I really don't like the way that the tree reads when you place the disabling checkmarks to the left of the branch arrows, as it muddles the visual relationships a bit. It would have to be thought through but I think you can get a more logical read by, in essence, making the checkmark the collection parent as far as the list is concerned.

Hard to explain in words. The following image shows your earlier example on the left and a quick reshuffling on the right. I find the left side inscrutable and the right side readable.

As a nitpic, I really don't like the way that the tree reads when you place the disabling checkmarks to the left of the branch arrows, as it muddles the visual relationships a bit. It would have to be thought through but I think you can get a more logical read by, in essence, making the checkmark the collection parent as far as the list is concerned. Hard to explain in words. The following image shows your earlier example on the left and a quick reshuffling on the right. I find the left side inscrutable and the right side readable. 

Duarte Farrajota Ramos commented 2019-02-19 00:40:02 +01:00

Copy Link

Agree, a lot more readable. Additionally with your proposed layout we gain collection icons aligned with child objects which also looks tidier and easier to follow.

If we could somehow combine the checkbox with the collection icon design such that the icon itself could alone clearly and unequivocally communicate the enabled/disabled state we could even ditch the checkbox altogether.

Agree, a lot more readable. Additionally with your proposed layout we gain collection icons aligned with child objects which also looks tidier and easier to follow. If we could somehow combine the checkbox with the collection icon design such that the icon itself could alone clearly and unequivocally communicate the enabled/disabled state we could even ditch the checkbox altogether.

Harley Acheson commented 2019-02-19 00:47:06 +01:00

Member

Copy Link

we gain collection icons aligned with child objects

That's technically a fault of my idea, in that the children icons are aligned with the icon of the parent. But they are still visually below the checkmark so it seems okay to me.

What I mostly like is that it looks we have "branches that can be disabled", which is actually what we are looking for I think.

Just a bit more tidying to that quick mockup to make it a bit more consistent and clearer.

> we gain collection icons aligned with child objects That's technically a fault of my idea, in that the children icons are aligned with the icon of the parent. But they are still visually below the checkmark so it seems okay to me. What I mostly like is that it looks we have "branches that can be disabled", which is actually what we are looking for I think. Just a bit more tidying to that quick mockup to make it a bit more consistent and clearer. 

Andrzej Ambroz commented 2019-02-19 01:04:09 +01:00

Member

Copy Link

@Harley
Your proposal looks tidier, but it loses the Collection's enabled/disabled state at-a-glance readability in my eyes. I'd put all the checkmark icons in the straight vertical collumn on the left - just like the rest of the visibility restriction icons are organized on the right side of he Outliner. This way the relations tree won't be messed with visually strong checkmarks.

@Harley Your proposal looks tidier, but it loses the Collection's enabled/disabled state at-a-glance readability in my eyes. I'd put all the checkmark icons in the straight vertical collumn on the left - just like the rest of the visibility restriction icons are organized on the right side of he Outliner. This way the relations tree won't be messed with visually strong checkmarks.

Harley Acheson commented 2019-02-19 01:24:03 +01:00

Member

Copy Link

I'd put all the checkmark icons in the straight vertical collumn on the left

I tried that, but couldn't make it look okay.

Another simpler thought that keeps the relationships a bit tighter. But might be a bit too whimsical...

> I'd put all the checkmark icons in the straight vertical collumn on the left I tried that, but couldn't make it look okay. Another simpler thought that keeps the relationships a bit tighter. But might be a bit too whimsical... 

Andrzej Ambroz commented 2019-02-19 01:34:10 +01:00

Member

Copy Link

What's wrong with this?

 What's wrong with this?

Duarte Farrajota Ramos commented 2019-02-19 01:39:30 +01:00

Copy Link

In #61578#623163, @jendrzych wrote:

What's wrong with this?

As far as I know the gutter is generally reserved as place to start box select, if we start cluttering it in with new features it defeats its purposed

In #61578#623162, @Harley wrote:

If the UI team deems this clear and self explanatory enough I would go with something along those lines. It is very compact, uses no additional space, and turns the otherwise mostly decorative icon into something functional

> In #61578#623163, @jendrzych wrote: >  > What's wrong with this? As far as I know the gutter is generally reserved as place to start box select, if we start cluttering it in with new features it defeats its purposed > In #61578#623162, @Harley wrote: >  If the UI team deems this clear and self explanatory enough I would go with something along those lines. It is very compact, uses no additional space, and turns the otherwise mostly decorative icon into something functional

Harley Acheson commented 2019-02-19 01:39:57 +01:00

Member

Copy Link

What's wrong with this?

Probably nothing wrong with it.

But for my brain it ends up looking odd with a straight vertical column of checkmarks, then a ragged tree (where it is the raggedness itself that tells the story), followed by a straight vertical column of visibility icons. The two straight columns on each side acting as bookends to the tree in middle make it hard to tell the relationships.

Or in a nutshell, the crap on the right that is not shown screws it all. LOL

> What's wrong with this? Probably nothing wrong with it. But for *my brain* it ends up looking odd with a straight vertical column of checkmarks, then a ragged tree (where it is the raggedness itself that tells the story), followed by a straight vertical column of visibility icons. The two straight columns on each side acting as bookends to the tree in middle make it hard to tell the relationships. Or in a nutshell, the crap on the right that is not shown screws it all. LOL

Luciano Muñoz Sessarego commented 2019-02-19 02:41:40 +01:00

Member

Copy Link

Added subscriber: @LucianoMunoz

Added subscriber: @LucianoMunoz

Luciano Muñoz Sessarego commented 2019-02-19 02:41:40 +01:00

Member

Copy Link

I think we're overcomplicating the outliner for options that seem and feel far more advanced than what the common user will understand, I dont think they should be taken away they are all stuff i believe i would use one way or an other but in the outliner I would only keep one or two options visible as previously suggested like selectability and visibility, but I'd make visibility affect be for both viewport and render (by default).

Then under the object properties, I'd have a sort of "advanced panel" or "overrides" or something of sorts where you can find, disable / enable, renderable / non, (maybe something similar to the Cycles "ray visitibility" settings panel.

Also I would by default make that an invisible object, Isnt calculated nor rendered (because it's expected), but with the possibility of bringing this back, so you can turn the eye off but then override whether this will still be calculated, or rendered.

An other thing regarding this, when hiding a collection have it affect it's children but not turn off their eyes, it's really hard then to turn them back on if say you have only 3 on out of 10, because now blender has forgotten which ones were on and off inside that collection, have the collection be a master visibility that overrides whatever visibility of the objects inside it no matter if they're on or off that way as a user you dont end up having to manually go back and change the visibility for each one again.

that's my two cents, I also believe all these options shouldnt be shared by both collections and objects, I still dont exactly know which one should have em all and which one shouldnt, probably the collection only should have visibility and selectability and linkedability (?).

As a side note please make sure that turning off selectability doesnt turn selectability via the outliner, it makes no sense, the idea is that you turn of selectability so you dont screw up in the viewport, but in the outliner then it becomes a problem.

yes i think those are my two cents.

I think we're overcomplicating the outliner for options that seem and feel far more advanced than what the common user will understand, I dont think they should be taken away they are all stuff i believe i would use one way or an other but in the outliner I would only keep one or two options visible as previously suggested like selectability and visibility, but I'd make visibility affect be for both viewport and render (by default). Then under the object properties, I'd have a sort of "advanced panel" or "overrides" or something of sorts where you can find, disable / enable, renderable / non, (maybe something similar to the Cycles "ray visitibility" settings panel. Also I would by default make that an invisible object, Isnt calculated nor rendered (because it's expected), but with the possibility of bringing this back, so you can turn the eye off but then override whether this will still be calculated, or rendered. An other thing regarding this, when hiding a collection have it affect it's children but not turn off their eyes, it's really hard then to turn them back on if say you have only 3 on out of 10, because now blender has forgotten which ones were on and off inside that collection, have the collection be a master visibility that overrides whatever visibility of the objects inside it no matter if they're on or off that way as a user you dont end up having to manually go back and change the visibility for each one again. that's my two cents, I also believe all these options shouldnt be shared by both collections and objects, I still dont exactly know which one should have em all and which one shouldnt, probably the collection only should have visibility and selectability and linkedability (?). As a side note please make sure that turning off selectability doesnt turn selectability via the outliner, it makes no sense, the idea is that you turn of selectability so you dont screw up in the viewport, but in the outliner then it becomes a problem. yes i think those are my two cents.

KiJeon commented 2019-02-19 10:50:12 +01:00

Copy Link

Added subscriber: @0o00o0oo

Added subscriber: @0o00o0oo

Daniel Paul commented 2019-02-19 11:10:47 +01:00

Copy Link

Added subscriber: @DanielPaul

Added subscriber: @DanielPaul

Daniel Paul commented 2019-02-19 11:10:47 +01:00

Copy Link

I think visibility and render should be visible all the time,
but we could toggle both of them with alt+click.

Moreover, we could inherit the status to the hierarchy by holding shift or ctrl.
So by holding shift+alt+click, I can hide the complete hierarchy for visibility and render.

Overall we should also consider a display-toggle for showing the "parent child" hierarchy in collections too.
It's really difficult to work with collections when one is used to group objects under other objects or emptys.
In this case, it is required to use two outliners at the same time to see what is happening.

I think visibility and render should be visible all the time, but we could toggle both of them with alt+click. Moreover, we could inherit the status to the hierarchy by holding shift or ctrl. So by holding shift+alt+click, I can hide the complete hierarchy for visibility and render. Overall we should also consider a display-toggle for showing the "parent child" hierarchy in collections too. It's really difficult to work with collections when one is used to group objects under other objects or emptys. In this case, it is required to use two outliners at the same time to see what is happening.

Daniel Paul commented 2019-02-19 11:35:18 +01:00

Copy Link

Removed subscriber: @DanielPaul

Removed subscriber: @DanielPaul

Daniel Paul commented 2019-02-19 11:35:19 +01:00

Copy Link

Added subscriber: @DanielPaul

Added subscriber: @DanielPaul

Andrzej Ambroz commented 2019-02-19 11:53:36 +01:00

Member

Copy Link

I think, that visibility restriction icons need some improvement in the style department.
Proposals: LINK .

I think, that visibility restriction icons need some improvement in the style department. Proposals: [LINK ](https://devtalk.blender.org/t/new-icons-for-blender-2-8/4651/40?u=jendrzych).

William Reynish commented 2019-02-19 11:55:49 +01:00

Author

Copy Link

@Harley @DuarteRamos @jendrzych

I updated the mockups in the original post with the checkmarks after the disclosure triangles. I think this is the nicest solution among the ones discussed.

The Collection icon-as-checkmark idea is neat but too inconsistent. Users expect to be able to click the icon without toggling it on or off.

@LucianoMunoz re. moving the toggles to the Properties:
We thought of this solution too. I wouldn't mind adding it there as well, but the reason we ended up with the solution described, is that in productions you'll often want to get an overview of many items at once. Inside the Properties, you'll only see the Properties for the active object or collection.

As for the the issue you describe with nested visibility, we have discussed a solution for it, which is: If you toggle visibility on a child item that is being toggled off by its parent, the parents should then be toggled back on. Otherwise users will have to manually make sure all parents are turned on.

It's on the (long!) list of improvements needed in the Outliner.

@Harley @DuarteRamos @jendrzych I updated the mockups in the original post with the checkmarks after the disclosure triangles. I think this is the nicest solution among the ones discussed. The Collection icon-as-checkmark idea is neat but too inconsistent. Users expect to be able to click the icon without toggling it on or off. @LucianoMunoz re. moving the toggles to the Properties: We thought of this solution too. I wouldn't mind adding it there as well, but the reason we ended up with the solution described, is that in productions you'll often want to get an overview of many items at once. Inside the Properties, you'll only see the Properties for the active object or collection. As for the the issue you describe with nested visibility, we have discussed a solution for it, which is: If you toggle visibility on a child item that is being toggled off by its parent, the parents should then be toggled back on. Otherwise users will have to manually make sure all parents are turned on. It's on the (long!) list of improvements needed in the Outliner.

William Reynish commented 2019-02-19 11:57:12 +01:00

Author

Copy Link

@jendrzych Thanks - these look great to me (the ones on the right).

@jendrzych Thanks - these look great to me (the ones on the right).

Daniel Paul commented 2019-02-19 13:16:57 +01:00

Copy Link

For nested visibility, a third state could make objects globally visible,
even when parent objects or collections aren't visible.

There is a good solution to this in c4d, it's also color-coded,
red for invisible, green for globally visible and grey for neutral behavior(Visible but can be overridden by a parent)

For nested visibility, a third state could make objects globally visible, even when parent objects or collections aren't visible. There is a good solution to this in c4d, it's also color-coded, red for invisible, green for globally visible and grey for neutral behavior(Visible but can be overridden by a parent)

Harley Acheson commented 2019-02-19 17:40:36 +01:00

Member

Copy Link

Another thought, here exaggerated for effect. Rather than show the right-side icons as enabled or disabled, we could show them as regular or restricted. Give prominence to the states that are exceptional, rather than see a sea of bright icons indicating the normal state.

Another thought, here exaggerated for effect. Rather than show the right-side icons as enabled or disabled, we could show them as regular or restricted. Give prominence to the states that are exceptional, rather than see a sea of bright icons indicating the normal state. 

Andrzej Ambroz commented 2019-02-19 18:01:58 +01:00

Member

Copy Link

@Harley
Well, it's just a question what do You want to underline. A matter of preference I'd say - You may say the glass is half full or half empty, but both of the statements re true. Here we have similar situation. Current design makes enabled states strong, that's true, but most of software I work with does it this way. Lack of information is an information as well, so both states are noticeable and easy to identify. Moreover devs could colour code the states (green = ON / red = OFF, or so).
BTW - restriction icons have three states actually ON / OFF / INACTIVE (greyed out), but Your mockup doesn't take this into account. Moreover it uses badly designed Linked Visibility icons that make it kinda messy (weak difference between ON and OFF states).

I think we should discuss this in the icons thread on the devtalk forum.

@Harley Well, it's just a question what do You want to underline. A matter of preference I'd say - You may say the glass is half full or half empty, but both of the statements re true. Here we have similar situation. Current design makes enabled states strong, that's true, but most of software I work with does it this way. Lack of information is an information as well, so both states are noticeable and easy to identify. Moreover devs could colour code the states (green = ON / red = OFF, or so). BTW - restriction icons have three states actually ON / OFF / INACTIVE (greyed out), but Your mockup doesn't take this into account. Moreover it uses badly designed Linked Visibility icons that make it kinda messy (weak difference between ON and OFF states). I think we should discuss this in the icons thread on the devtalk forum.

Harley Acheson commented 2019-02-19 18:15:14 +01:00

Member

Copy Link

@jendrzych

but most of software I work with does it this way

For sure. It was just a thought. While making the mockup I was trying to make sure that each side showed the same items restricted, and just doing that it was easy to miss some. I really have to scan the left side very carefully, while the right jumps out. Of course this is with old eyes that need reading glasses. LOL

ON / OFF / INACTIVE (greyed out), but Your mockup doesn't take this into account.

Yes, I couldn't find three states in the icon sheet so I just used the "On" version. And swapped the link one horizontally so it would work with my slash.

I think we should talk about this in the icons thread on the devtalk forum.

For sure. I got all excited and cross-posted. Any excuse to make a mock up. LOL

@jendrzych > but most of software I work with does it this way For sure. It was just a thought. While making the mockup I was trying to make sure that each side showed the same items restricted, and just doing that it was easy to miss some. I really have to scan the left side very carefully, while the right jumps out. Of course this is with old eyes that need reading glasses. LOL > ON / OFF / INACTIVE (greyed out), but Your mockup doesn't take this into account. Yes, I couldn't find three states in the icon sheet so I just used the "On" version. And swapped the link one horizontally so it would work with my slash. > I think we should talk about this in the icons thread on the devtalk forum. For sure. I got all excited and cross-posted. Any excuse to make a mock up. LOL

Andrzej Ambroz commented 2019-02-19 18:21:26 +01:00

Member

Copy Link

@Harley
I appreciate and enjoy Your contribution! It makes me move instead of resting on my laurels. I bet, that better icons (check out my latest proposal) will make it easier to distinguish ID states and spot the proper information.

@Harley I appreciate and enjoy Your contribution! It makes me move instead of resting on my laurels. I bet, that better icons (check out my latest proposal) will make it easier to distinguish ID states and spot the proper information.

Julien Kaspar commented 2019-02-19 18:50:24 +01:00

Member

Copy Link

@jendrzych @WilliamReynish Actually there may have to be 4 states. In the current outliner when a screen/cursor/camera icon is greyed out it means that it cannot be toggled because it is linked.
So there should be a representation for: On, Off, inactive (greyed out) & linked (cannot be toggled).
Using greyed out icons for 2 different states is probably an issue.
Maybe the linked state could have a slightly red circle behind it, similarly to how selected items get a white or orange circle behind them. Or the icon itself could be slightly red.
Do you have any ideas for a solution?

@jendrzych @WilliamReynish Actually there may have to be 4 states. In the current outliner when a screen/cursor/camera icon is greyed out it means that it cannot be toggled because it is linked. So there should be a representation for: On, Off, inactive (greyed out) & linked (cannot be toggled). Using greyed out icons for 2 different states is probably an issue. Maybe the linked state could have a slightly red circle behind it, similarly to how selected items get a white or orange circle behind them. Or the icon itself could be slightly red. Do you have any ideas for a solution?

Harley Acheson commented 2019-02-19 18:53:10 +01:00

Member

Copy Link

I probably don't understand the issue. But if something is in a state where it "cannot be toggled" shouldn't the toggle icons be completely hidden?

I probably don't understand the issue. But if something is in a state where it "cannot be toggled" shouldn't the toggle icons be completely hidden?

Julien Kaspar commented 2019-02-19 18:57:35 +01:00

Member

Copy Link

@Harley It's necessary to still be able to see if it is on, off and maybe even inactive. So I think a backdrop would be best because it doesn't change the style of the icon itself.

@Harley It's necessary to still be able to see if it is on, off and maybe even inactive. So I think a backdrop would be best because it doesn't change the style of the icon itself.

Harley Acheson commented 2019-02-19 18:59:30 +01:00

Member

Copy Link

Oh I see. So it can be on, off, or inactive while ALSO being unchangeable. Yikes. I think I'll just back away slowly... LOL

Oh I see. So it can be on, off, or inactive while ALSO being unchangeable. Yikes. I think I'll just back away slowly... LOL

Andrzej Ambroz commented 2019-02-19 18:59:37 +01:00

Member

Copy Link

At first glance, Harley's solution seems reasonable - turning off the opportunity to toggle, by hiding toggle icons.

At first glance, Harley's solution seems reasonable - turning off the opportunity to toggle, by hiding toggle icons.

Julien Kaspar commented 2019-02-19 19:10:51 +01:00

Member

Copy Link

@jendrzych I was waiting for the "... but when looking at the issue further" :D
Well if the icons are completely hidden when linked then the user would be blind to what state the toggles are in. The only way to find out in that case would be to load the file it is linked from.
But once Overrides get implemented it should be possible to override these states so an indication of what the state is is necessary.
If we would use a slightly red backdrop for linked toggles then the backdrop could change to cyan when overridden (I believe that is the planned color for overridden values/sliders/icons/etc) or yellow when keyed (if that feature returns) and purple when driven.

@jendrzych I was waiting for the "... but when looking at the issue further" :D Well if the icons are completely hidden when linked then the user would be blind to what state the toggles are in. The only way to find out in that case would be to load the file it is linked from. But once Overrides get implemented it should be possible to override these states so an indication of what the state is is necessary. If we would use a slightly red backdrop for linked toggles then the backdrop could change to cyan when overridden (I believe that is the planned color for overridden values/sliders/icons/etc) or yellow when keyed (if that feature returns) and purple when driven.

Andrzej Ambroz commented 2019-02-19 19:59:38 +01:00

Member

Copy Link

@JulienKaspar
Sorry - I didn't reload the browser and missed some responses.
I don't like the backdrop solution, since it's not elegant and will introduce unnecessary muddle in the space that already is overloaded with information.
In my opinion, dimming icons that are inactive or ineditable will be sufficient, because the effect for the end user will be identical - no possibility to change the state of the icon. The burden of information about whether the ID is linked should be transferred to the object's pictogram - I would try to change the color of the linked object's icon from warm yellow to light gray, as indication of the lack of editing.

@JulienKaspar Sorry - I didn't reload the browser and missed some responses. I don't like the backdrop solution, since it's not elegant and will introduce unnecessary muddle in the space that already is overloaded with information. In my opinion, dimming icons that are inactive or ineditable will be sufficient, because the effect for the end user will be identical - no possibility to change the state of the icon. The burden of information about whether the ID is linked should be transferred to the object's pictogram - I would try to change the color of the linked object's icon from warm yellow to light gray, as indication of the lack of editing.

Harley Acheson commented 2019-02-19 20:09:51 +01:00

Member

Copy Link

I tried to back away... LOL.

Since we use changes of opacity in the icons themselves to help differentiate between on and off, it can be ambiguous to use lowered opacity for disabled (unchangeable) as well.

Is it a thought to manufacture a "disabled" state for the icons on demand? Old-school style by drawing it twice with an offset?

I tried to back away... LOL. Since we use changes of opacity in the icons themselves to help differentiate between on and off, it can be ambiguous to use lowered opacity for disabled (unchangeable) as well. Is it a thought to [manufacture ](https://developer.blender.org/D4283) a "disabled" state for the icons on demand? Old-school style by drawing it twice with an offset? 

Julien Kaspar commented 2019-02-19 20:18:18 +01:00

Member

Copy Link

@jendrzych

In my opinion, dimming icons that are inactive or ineditable will be sufficient, because the effect for the end user will be identical - no possibility to change the state of the icon.

Fair enough.

I would try to change the color of the linked object's icon from warm yellow to light gray, as indication of the lack of editing.

But they already have an additional link icon next to their own icon. That is a much clearer indication that the object/collection is linked (although maybe a bit confusing once the link toggle on the right gets added).
Changing object color from orange to light grey sounds fine otherwise, but collection icons would then change from white to light grey, right? That is a lot more subtle than a link icon next to it.

@jendrzych > In my opinion, dimming icons that are inactive or ineditable will be sufficient, because the effect for the end user will be identical - no possibility to change the state of the icon. Fair enough. > I would try to change the color of the linked object's icon from warm yellow to light gray, as indication of the lack of editing. But they already have an additional link icon next to their own icon. That is a much clearer indication that the object/collection is linked (although maybe a bit confusing once the link toggle on the right gets added). Changing object color from orange to light grey sounds fine otherwise, but collection icons would then change from white to light grey, right? That is a lot more subtle than a link icon next to it.

Luciano Muñoz Sessarego commented 2019-02-19 20:53:05 +01:00

Member

Copy Link

nice, thanks mate!
i think you guys are doing a great job, keep it up!

nice, thanks mate! i think you guys are doing a great job, keep it up!

Val Barashkov commented 2019-02-19 20:57:03 +01:00

Copy Link

Added subscriber: @ValBarashkov

Added subscriber: @ValBarashkov

Val Barashkov commented 2019-02-19 20:57:03 +01:00

Copy Link

I like this! The right design makes the icon usable and clear what to expect when selected or deselected. And yeah, saves UI space.

>  I like this! The right design makes the icon usable and clear what to expect when selected or deselected. And yeah, saves UI space.

Marcus Papathoma commented 2019-02-19 20:59:22 +01:00

Copy Link

Removed subscriber: @machieb

Removed subscriber: @machieb

Andrei Nadin commented 2019-02-19 22:05:37 +01:00

Copy Link

Added subscriber: @AnadinX

Added subscriber: @AnadinX

Andrei Nadin commented 2019-02-19 22:05:37 +01:00

Copy Link

I hate to add more options here but in my opinion C4D has one of the best outliners of any DCC app. They use the traffic light icons as mentioned above which I great once you learn it :). I’m only here to say that green/red icon states are pretty unfair IF you resort to colours. Blue and Yellow are the safest pairing I believe unless you add a colour blind toggle in the preferences as well. Otherwise, personally I think I like where this is all going.

I hate to add more options here but in my opinion C4D has one of the best outliners of any DCC app. They use the traffic light icons as mentioned above which I great once you learn it :). I’m only here to say that green/red icon states are pretty unfair IF you resort to colours. Blue and Yellow are the safest pairing I believe unless you add a colour blind toggle in the preferences as well. Otherwise, personally I think I like where this is all going.

Andrzej Ambroz commented 2019-02-19 22:40:13 +01:00

Member

Copy Link

@JulienKaspar
Ha! Linked Objects have a link icon next to them indeed. Can't help feeling that all the stuff gets more and more crowded.

@JulienKaspar Ha! Linked Objects have a link icon next to them indeed. Can't help feeling that all the stuff gets more and more crowded.

Petter Lundh commented 2019-02-20 08:55:50 +01:00

Copy Link

Added subscriber: @PetterLundh

Added subscriber: @PetterLundh

Petter Lundh commented 2019-02-20 09:28:29 +01:00

Copy Link

Love the quick availability and read of "enable/disable" in this suggestion, but where does the ability to use "set indirect only" come in? It would be strange if that was still hidden in a menu.

Additionally, I found it weird that "indirect" is currently only visible when you have Cycles picked as a renderer, even if it only takes effect there. Most of the time I use Eeevee as a preview while working, and then only switch to Cycles at the very end. It would be nice to adjust the "indirect" setting at any time.

Love the quick availability and read of "enable/disable" in this suggestion, but where does the ability to use "set indirect only" come in? It would be strange if that was still hidden in a menu. Additionally, I found it weird that "indirect" is currently only visible when you have Cycles picked as a renderer, even if it only takes effect there. Most of the time I use Eeevee as a preview while working, and then only switch to Cycles at the very end. It would be nice to adjust the "indirect" setting at any time.

Daniel Paul commented 2019-02-20 12:25:51 +01:00

Copy Link

@AnadinX Yes! I also think that this is the best way I have encountered in DDC apps so far.

Especially with ctrl and alt modifier, it's really easy to use.
Safes space, has a lot of functionality.

Additionally, the color makes the reading super easy.

In this case Alt + click toggles both at the same time
Ctrl + click inherits through the hierarchy.
Ctrl + Alt + click toggles all and also the hierarchy.
Super eazy.

In general, I think blender should copy more from other DDCs what is already good and enhance it from there even more. Like the c4d outliner, or at least use other DDCs more for inspiration. Maxon did the same, they took blenders node Editor as a model. (not talking from CyclesToC4D, I mean the new native node system in c4d) They copied almost every function I love blenders node editor for.

@AnadinX Yes! I also think that this is the best way I have encountered in DDC apps so far. Especially with ctrl and alt modifier, it's really easy to use. Safes space, has a lot of functionality. Additionally, the color makes the reading super easy.   In this case Alt + click toggles both at the same time Ctrl + click inherits through the hierarchy. Ctrl + Alt + click toggles all and also the hierarchy. Super eazy. In general, I think blender should copy more from other DDCs what is already good and enhance it from there even more. Like the c4d outliner, or at least use other DDCs more for inspiration. Maxon did the same, they took blenders node Editor as a model. (not talking from CyclesToC4D, I mean the new native node system in c4d) They copied almost every function I love blenders node editor for.

Brecht Van Lommel commented 2019-02-20 12:48:44 +01:00

Owner

Copy Link

In #61578#621706, @WilliamReynish wrote:
re. the render/viewport thing: That was also what the checkmark should solve - this applies to both the viewport and the render.
We can also just show the render visibility toggle by default, which will make the distinction clearer. Perhaps we should show check mark, viewport visibility and render visibility by default. Selectability and Instance visibility can then be hidden by default.

My point was that render vs. viewport visibility as a concept is problematic, that this is actually the wrong distinction to make. Showing the checkmark does not solve that problem.

The more I think about it, the Instanced Visibility toggle should not actually make something invisible, unless it's being instanced. In the common use-cases of boolean objects and armatures, you want to be able to select and manipulate them inside the source Collection, but not be visible when instanced.

I agree it's not ideal to have to toggle this every time you want to edit the original asset. But making this only affect instances means it can't be used anymore in other cases without instancing. When you are not making an asset to be instanced elsewhere but just locally in a file you still want to be able to hide objects in a more permanent way like this. Further, this is also the property that would be used for animation.

There could be an additional option but that makes the UI even more cluttered.

> In #61578#621706, @WilliamReynish wrote: > re. the render/viewport thing: That was also what the checkmark should solve - this applies to both the viewport and the render. > We can also just show the render visibility toggle by default, which will make the distinction clearer. Perhaps we should show check mark, viewport visibility and render visibility by default. Selectability and Instance visibility can then be hidden by default. My point was that render vs. viewport visibility as a concept is problematic, that this is actually the wrong distinction to make. Showing the checkmark does not solve that problem. > The more I think about it, the Instanced Visibility toggle should not actually make something invisible, unless it's being instanced. In the common use-cases of boolean objects and armatures, you want to be able to select and manipulate them inside the source Collection, but not be visible when instanced. I agree it's not ideal to have to toggle this every time you want to edit the original asset. But making this only affect instances means it can't be used anymore in other cases without instancing. When you are not making an asset to be instanced elsewhere but just locally in a file you still want to be able to hide objects in a more permanent way like this. Further, this is also the property that would be used for animation. There could be an additional option but that makes the UI even more cluttered.

AlphaVDP2 commented 2019-02-21 05:59:38 +01:00

Copy Link

Added subscriber: @AlphaVDP2

Added subscriber: @AlphaVDP2

Harley Acheson commented 2019-02-23 19:35:55 +01:00

Member

Copy Link

Regarding something I posed earlier, it looks like I could manufacture a "disabled" state for icons that works across different themes. It could just draw this way if uiBut has UI_BUT_DISABLED in flag. Is this worth pursuing?

Regarding something I posed earlier, it looks like I **could** manufacture a "disabled" state for icons that works across different themes. It could just draw this way if uiBut has UI_BUT_DISABLED in flag. Is this worth pursuing? 

Paul Kotelevets commented 2019-02-24 00:32:59 +01:00

Copy Link

Added subscriber: @1D_Inc

Added subscriber: @1D_Inc

Paul Kotelevets commented 2019-02-24 00:32:59 +01:00

Copy Link

In #61578#623163, @jendrzych wrote:

What's wrong with this?

Looking nice, but there is infinite collections count with ifinite cout of insets.
Personally I would like to propose to duplicate it, in a dopesheet style.

> In #61578#623163, @jendrzych wrote: >  > What's wrong with this? Looking nice, but there is infinite collections count with ifinite cout of insets. Personally I would like to propose to duplicate it, in a dopesheet style.

Stephen Hamacek commented 2019-03-13 07:00:03 +01:00

Copy Link

Added subscriber: @StephenHamacek

Added subscriber: @StephenHamacek

Mafer M commented 2019-03-13 12:30:43 +01:00

Copy Link

Added subscriber: @MaferM

Added subscriber: @MaferM

Jack Schaberg commented 2019-03-28 21:39:14 +01:00

Copy Link

Added subscriber: @JaySchay

Added subscriber: @JaySchay

Jack Schaberg commented 2019-03-28 21:39:14 +01:00

Copy Link

do I gather from this thread that it is currently not possible to keyframe the render icon to affect the visibility of objects during animation, as we can do in 2.79? If it's not currently possible, is that likely the change? It's an extremely helpful and time-saving feature in my work.

do I gather from this thread that it is currently not possible to keyframe the render icon to affect the visibility of objects during animation, as we can do in 2.79? If it's not currently possible, is that likely the change? It's an extremely helpful and time-saving feature in my work.

Julien Kaspar commented 2019-03-29 14:44:43 +01:00

Member

Copy Link

@JaySchay I do agree that there are some things that need to be considered like keying/driving render and viewport visibility. Right now it's not possible for viewport visibility, which is a big issue.
@WilliamReynish @brecht @dfelinto
If the screen icon gets replaced by the instanced visibility then it needs to be possible to key/drive the eye icon, which means that the eye needs to become global instead of per viewlayer.
That's something to consider.

@JaySchay I do agree that there are some things that need to be considered like keying/driving render and viewport visibility. Right now it's not possible for viewport visibility, which is a big issue. @WilliamReynish @brecht @dfelinto If the screen icon gets replaced by the instanced visibility then it needs to be possible to key/drive the eye icon, which means that the eye needs to become global instead of per viewlayer. That's something to consider.

Jack Schaberg commented 2019-03-29 15:10:34 +01:00

Copy Link

@JulienKaspar Agree with all. Adding to it, in my work, the ability to control keying of the camera/render visibility of an object is even more important than viewport visibility. Hopefully, both are something that can be addressed.

@JulienKaspar Agree with all. Adding to it, in my work, the ability to control keying of the camera/render visibility of an object is even more important than viewport visibility. Hopefully, both are something that can be addressed.

msalv commented 2019-03-29 16:52:08 +01:00

Copy Link

Added subscriber: @moisessalvador

Added subscriber: @moisessalvador

msalv commented 2019-03-29 16:52:08 +01:00

Copy Link

I too rely on viewport visibility for my rigs. Allowing me to use drivers to control from within the Armature things like outfits, hiding, showing different object parts

I too rely on viewport visibility for my rigs. Allowing me to use drivers to control from within the Armature things like outfits, hiding, showing different object parts

William Reynish commented 2019-03-29 16:53:44 +01:00

Author

Copy Link

I don't think anyone has ever disputed the need for animating viewport visibility. No need to pile on - it is only a technical issue to do with the depsgraph, nothing to do with the UI or overall paradigm.

I don't think anyone has ever disputed the need for animating viewport visibility. No need to pile on - it is only a technical issue to do with the depsgraph, nothing to do with the UI or overall paradigm.

Paul Kotelevets commented 2019-03-30 15:34:42 +01:00

Copy Link

Ability to animate any kind of UI gives sence of power)
I think, that Visibility button binar paradigm is not designed for animation yet
(three states needed instead of two for this ability - non-animated, animated, animated, but not at current frame),
as far as outliner is hierarcial viewing/editing tool, so it have to be animation-independent in order to be in the TOP of hierarchy, to provide ability to view full of it.

Animating Outliner will place Animation of Outliner higher in hierarchy, than Outliner itself.
This will require to rewrite a lot, starting from depsgraph.
So it is a nice but laborious and time-consuming idea.

Or maybe not. I don't know why it was possible in 2.79

Ability to animate any kind of UI gives sence of power) I think, that Visibility button binar paradigm is not designed for animation yet (three states needed instead of two for this ability - non-animated, animated, animated, but not at current frame), as far as outliner is hierarcial viewing/editing tool, so it have to be animation-independent in order to be in the TOP of hierarchy, to provide ability to view full of it. Animating Outliner will place Animation of Outliner higher in hierarchy, than Outliner itself. This will require to rewrite a lot, starting from depsgraph. So it is a nice but laborious and time-consuming idea. Or maybe not. I don't know why it was possible in 2.79

Luciano Muñoz Sessarego commented 2019-04-09 21:42:39 +02:00

Member

Copy Link

What if "visibility, excludility and rendereability" are by default just one button, so if the object is visible, is included, and rendereable, if the visibility is off, its excluded, not rendereable, not visible not even calculated in the depthsgraph, unless you want to have it invisible in the viewport but want it rendereable then you can override that "manually" I think it would be much simpler to use for starters and would make more sense.

What if "visibility, excludility and rendereability" are by default just one button, so if the object is visible, is included, and rendereable, if the visibility is off, its excluded, not rendereable, not visible not even calculated in the depthsgraph, unless you want to have it invisible in the viewport but want it rendereable then you can override that "manually" I think it would be much simpler to use for starters and would make more sense.

Brecht Van Lommel commented 2019-04-09 22:10:56 +02:00

Owner

Copy Link

My meeting notes from discussion at homestretch workshop. No decisions taken yet, a more concrete proposal that further changes the design in this task is to be worked out still.

Types of Settings

• Viewport vs. render
• Per-view layer local and per-datablock global (instances and linking)
• Temporary for working or more permanent and rarely touched
• Animateable and non-animatable
• For beginners or more advanced use cases

Challenges

• Large number of visibility settings is hard to understand
• Viewport and render visibility distinction is useful but also causes confusion for cases where new or experienced users do not care about the distinction. Ideally user would only have to worry about this in cases where they actually want there to be distinction instead of keeping both in sync.
• It’s not clear which settings are per-viewlayer and which are global.
• Instanced / linked visibility does not have a clear name.
• When hiding the original object for duplicators, it’s not obvious that the right way to do it is to put them in a hidden collection.
• Not obvious which visibility settings can be animated. Not all settings useful to animate currently can be animated.
• Number keys do not obviously map to a collection hierarchy.
• Debugging why an object is or is not visible is hard.
• Not all hiding options improve performance.
• No good solution for quick visibility toggling in the 3D viewport, popover not popular, want something more permanent to work fullscreen without outliner.
• Holdout, indirect only not available as columns in outliner.
• No way to view objects with final render visibility in the viewport.

Ideas

• Filter out advanced visibility columns by default, and add holdout and indirect only columns.
• Filter out selectability column by default. Instead do it through right click menu or shortcut, and show icon indicating when objects are not selectable. Not so important for new users, and object type selectability in viewport often replaces this.
• Change instanced and render visibility settings to two other settings: global visibility, and an enum with “both, viewport only, render only". The global visibility would be an icon column that is visible by default. The latter two states would not have a column, but if viewport only or render only is set there would be an icon indicating that state.
• Try to separate per-viewlayer and per-datablock settings visually somehow.
• Put 3D viewport panel with collections in sidebar instead of header popover, make usable enough so animators can hide outliner.

My meeting notes from discussion at homestretch workshop. No decisions taken yet, a more concrete proposal that further changes the design in this task is to be worked out still. ### Types of Settings * Viewport vs. render * Per-view layer local and per-datablock global (instances and linking) * Temporary for working or more permanent and rarely touched * Animateable and non-animatable * For beginners or more advanced use cases ### Challenges * Large number of visibility settings is hard to understand * Viewport and render visibility distinction is useful but also causes confusion for cases where new or experienced users do not care about the distinction. Ideally user would only have to worry about this in cases where they actually want there to be distinction instead of keeping both in sync. * It’s not clear which settings are per-viewlayer and which are global. * Instanced / linked visibility does not have a clear name. * When hiding the original object for duplicators, it’s not obvious that the right way to do it is to put them in a hidden collection. * Not obvious which visibility settings can be animated. Not all settings useful to animate currently can be animated. * Number keys do not obviously map to a collection hierarchy. * Debugging why an object is or is not visible is hard. * Not all hiding options improve performance. * No good solution for quick visibility toggling in the 3D viewport, popover not popular, want something more permanent to work fullscreen without outliner. * Holdout, indirect only not available as columns in outliner. * No way to view objects with final render visibility in the viewport. ### Ideas * Filter out advanced visibility columns by default, and add holdout and indirect only columns. * Filter out selectability column by default. Instead do it through right click menu or shortcut, and show icon indicating when objects are not selectable. Not so important for new users, and object type selectability in viewport often replaces this. * Change instanced and render visibility settings to two other settings: global visibility, and an enum with “both, viewport only, render only". The global visibility would be an icon column that is visible by default. The latter two states would not have a column, but if viewport only or render only is set there would be an icon indicating that state. * Try to separate per-viewlayer and per-datablock settings visually somehow. * Put 3D viewport panel with collections in sidebar instead of header popover, make usable enough so animators can hide outliner.

Brecht Van Lommel commented 2019-04-09 22:11:36 +02:00

Owner

Copy Link

@LucianoMunoz, we discussed something like this, see notes above.

@LucianoMunoz, we discussed something like this, see notes above.

Luciano Muñoz Sessarego commented 2019-04-09 22:13:42 +02:00

Member

Copy Link

In #61578#657640, @brecht wrote:
@LucianoMunoz, we discussed something like this, see notes above.

yeah i just noticed, i think i posted that just before you did ?, very nice, I'm excited! great job and good luck with the homestretch!

> In #61578#657640, @brecht wrote: > @LucianoMunoz, we discussed something like this, see notes above. yeah i just noticed, i think i posted that just before you did ?, very nice, I'm excited! great job and good luck with the homestretch!

Paul Kotelevets commented 2019-04-09 23:48:35 +02:00

Copy Link

Debugging why an object is or is not visible is hard.

I remember Revit hint about "Why object is hidden", with the instruction to search in 9 different places in program (visibility states, sections, classic hiding, structural class hiding, building state, building variations, etc.)
Yep, that was time consuming)

> Debugging why an object is or is not visible is hard. I remember Revit hint about "Why object is hidden", with the instruction to search in 9 different places in program (visibility states, sections, classic hiding, structural class hiding, building state, building variations, etc.) Yep, that was time consuming)

Dalai Felinto was assigned by Brecht Van Lommel 2019-04-12 07:51:27 +02:00

Maciej Jutrzenka commented 2019-04-23 12:22:37 +02:00

Copy Link

Added subscriber: @MaciejJutrzenka

Added subscriber: @MaciejJutrzenka

Maciej Jutrzenka commented 2019-04-23 12:22:37 +02:00

Copy Link

This comment was removed by @MaciejJutrzenka

*This comment was removed by @MaciejJutrzenka*

Maciej Jutrzenka commented 2019-04-26 23:44:27 +02:00

Copy Link

i would personaly keep it very simple for ech option just make icon and that is all.. very easy to use and check. also would be nice if there would be option to just filter thru those.

i would personaly keep it very simple for ech option just make icon and that is all.. very easy to use and check. also would be nice if there would be option to just filter thru those.

Paul Kotelevets commented 2019-04-27 15:58:36 +02:00

Copy Link

Also - important - fuction to inverse visibility is needed.
That will split scene into two global "slots" (visible vs invisible) with ability to switch between them.

Maybe Alt+Ctrl click on any eye sign in outliner.
That will give full fast control over hidden objects in entire scene.

Also - important - fuction to inverse visibility is needed. That will split scene into two global "slots" (visible vs invisible) with ability to switch between them. Maybe Alt+Ctrl click on any eye sign in outliner. That will give full fast control over hidden objects in entire scene. 

Paul Kotelevets commented 2019-04-27 20:19:50 +02:00

Copy Link

• It’s too much of a hassle to make sure the viewport visibility matches the render visibility.

The same switch can be made between render visibility and viewport visibility, to view what actually will be rendered as visible objects, control it with visibility switch from picture, and then switch back.
This way visibility can be the map for displaying different unobvious properties like render visibility.
Can be the solution for an issue.

We made such switch system for AutoCAD, and it is nice if it properly marked, we have full control over visibility and plottable state of thousands of layers.
We can switch in, edit plottability as visibility, and switch back.

In the Eisenhower matrix, this is how the switch looks like.

Not by inverse, but the same purpose in Revit:
https://www.youtube.com/watch?v=2adkWRabRYE

- It’s too much of a hassle to make sure the viewport visibility matches the render visibility. The same switch can be made between render visibility and viewport visibility, to view what actually will be rendered as visible objects, control it with visibility switch from picture, and then switch back. This way visibility can be the map for displaying different unobvious properties like render visibility. Can be the solution for an issue.  We made such switch system for AutoCAD, and it is nice if it properly marked, we have full control over visibility and plottable state of thousands of layers. We can switch in, edit plottability as visibility, and switch back.  In the Eisenhower matrix, this is how the switch looks like.  Not by inverse, but the same purpose in Revit: https://www.youtube.com/watch?v=2adkWRabRYE

Harley Acheson commented 2019-04-27 23:11:32 +02:00

Member

Copy Link

Part of the issue for me is that we don't do a good job of indicating the relationship between collection restrictions and object restrictions. It is difficult to tell the story of why there are multiple levels and which one takes precedence.

For example, take a look at the object "Schrodinger" below. It is not visible on the left because its local "visibility" is turned off, despite the parent collection visibility turned on. Therefore you might conclude that the object setting overrides the parent setting.

However, on the right it is still invisible despite the local setting. So the parent setting is more important in this case, but not in the other.

One idea to make that relationship more clear and remove some of the visual confusion of having a million icons in rows. Give the collection restrictions a third state:

So by default we only show restriction icons on the collections, and therefore allow those to control the children. As shown on the left it becomes clear that collection icons are controlling everything in a very big and simple way.

But the collection's "eye" goes from on, to off, and then to looking disabled. At that point we show all the children's restriction icons as shown on the right. These two captures seem to tell the story for me in a straightforward way and with minimum clutter. It is obvious in both why Schrodinger is invisible. And this requires minimal changes in how this all works under the hood, mostly to how it is shown to users.

Part of the issue for me is that we don't do a good job of indicating the *relationship* between collection restrictions and object restrictions. It is difficult to tell the story of why there are multiple levels and which one takes precedence. For example, take a look at the object "Schrodinger" below. It is not visible on the left because its local "visibility" is turned off, despite the parent collection visibility turned on. Therefore you might conclude that the object setting overrides the parent setting. However, on the right it is still invisible despite the local setting. So the parent setting is more important in this case, but not in the other.  One idea to make that relationship more clear and remove some of the visual confusion of having a million icons in rows. **Give the collection restrictions a third state**: So by default we only show restriction icons on the collections, and therefore allow those to control the children. As shown on the left it becomes clear that collection icons are controlling everything in a very big and simple way. But the collection's "eye" goes from on, to off, and then to looking disabled. At that point we show all the children's restriction icons as shown on the right. These two captures seem to tell the story for me in a straightforward way and with minimum clutter. It is obvious in both why Schrodinger is invisible. And this requires minimal changes in how this all works under the hood, mostly to how it is shown to users. 

Karlo commented 2019-04-29 18:29:48 +02:00

Copy Link

Added subscriber: @kpavicic

Added subscriber: @kpavicic

Paul Kotelevets commented 2019-05-01 22:21:55 +02:00

Copy Link

Here is an example of swap/invert modes

First button inverts visibility state
Second - swaps visibility and renderability

Object visibility can be inverted or swapped, that gives ability to view/edit rendederability of objects as visibility.
Personally, I would like to prefer columns switching, to define mode
(declaring first column for changing value by visibility when swapping columns), that will make things more clean.
But it is already useful concept.

2buttons.py

Here is an example of swap/invert modes First button inverts visibility state Second - swaps visibility and renderability Object visibility can be inverted or swapped, that gives ability to view/edit rendederability of objects as visibility. Personally, I would like to prefer columns switching, to define mode (declaring first column for changing value by visibility when swapping columns), that will make things more clean. But it is already useful concept.  [2buttons.py](https://archive.blender.org/developer/F6999635/2buttons.py)

Paul Kotelevets commented 2019-05-04 13:42:56 +02:00

Copy Link

Update with icons, (instead of possible columns changing) that depicts current mode.
Allow to recognize what mode of visibility is currently on.

Here on GIF I making column of unrenderable objects and row of invisible objects, controlling their states as visibility with 2 buttons, having full control over their states.

2buttons (1-0-1).py

Update with icons, (instead of possible columns changing) that depicts current mode. Allow to recognize what mode of visibility is currently on. Here on GIF I making column of unrenderable objects and row of invisible objects, controlling their states as visibility with 2 buttons, having full control over their states.  [2buttons (1-0-1).py](https://archive.blender.org/developer/F7005186/2buttons__1-0-1_.py)

Marcus Papathoma commented 2019-05-12 12:30:40 +02:00

Copy Link

Super great improvement! Thanks for your hard work!

Super great improvement! Thanks for your hard work!

ronald johnson commented 2019-05-13 15:39:15 +02:00

Copy Link

Added subscriber: @billyand

Added subscriber: @billyand

heini commented 2019-05-13 17:48:56 +02:00

Copy Link

Added subscriber: @heini

Added subscriber: @heini

YAFU commented 2019-05-14 14:53:45 +02:00

Copy Link

Added subscriber: @YAFU

Added subscriber: @YAFU

YAFU commented 2019-05-14 14:53:45 +02:00

Copy Link

Hello.
About the check boxes for collections, I think the idea of this has been that it works like the arrange in boxes for view layers that we have in 2.79 at bottom. What I do not understand is why when you disable a collection the content disappears from outliner. I imagine that for better organization you will always want to see the content of the collections even though it is disabled. I’m not sure if grayed out the content can be confused with disabling viewport view, but perhaps there should be another way to indicate that it is disabled but without the elements disappear from outliner (strikethrough text, color change, a mark, etc). Or perhaps none of the buttons on the right should grayed out the collection/content, and reserve grayed out text only for disabled/unchecked collections and its content.

Hello. About the check boxes for collections, I think the idea of this has been that it works like the arrange in boxes for view layers that we have in 2.79 at bottom. What I do not understand is why when you disable a collection the content disappears from outliner. I imagine that for better organization you will always want to see the content of the collections even though it is disabled. I’m not sure if grayed out the content can be confused with disabling viewport view, but perhaps there should be another way to indicate that it is disabled but without the elements disappear from outliner (strikethrough text, color change, a mark, etc). Or perhaps none of the buttons on the right should grayed out the collection/content, and reserve grayed out text only for disabled/unchecked collections and its content.

Paul Kotelevets commented 2019-05-14 15:56:43 +02:00

Copy Link

In #61578#678762, @YAFU wrote:

What I do not understand is why when you disable a collection the content disappears from outliner. I imagine that for better organization you will always want to see the content of the collections even though it is disabled.

Agreed.
Or it can be separate mode, that depends on orkflow demand with outliner visibility control.

> In #61578#678762, @YAFU wrote: > What I do not understand is why when you disable a collection the content disappears from outliner. I imagine that for better organization you will always want to see the content of the collections even though it is disabled. Agreed. Or it can be separate mode, that depends on orkflow demand with outliner visibility control.

Dalai Felinto commented 2019-05-15 00:09:07 +02:00

Owner

Copy Link

Changed status from 'Open' to: 'Resolved'

Changed status from 'Open' to: 'Resolved'

Dalai Felinto closed this issue 2019-05-15 00:09:07 +02:00

Dalai Felinto commented 2019-05-15 00:09:07 +02:00

Owner

Copy Link

Implemented on b1af682001, with updates in subsequent commits (5f84e2d732, 9b80318a28, 903041e1c0, 777a546c0c).

Implemented on b1af6820015, with updates in subsequent commits (5f84e2d732c, 9b80318a284, 903041e1c0e, 777a546c0c7).

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

main

brush-assets-project

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

Assignees

Clear assignees

No Assignees

Dalai Felinto

27 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#61578

No description provided.