- User Since
- Feb 1 2018, 12:48 PM (72 w, 12 h)
Fri, Jun 7
Mon, May 27
Thu, May 23
May 21 2019
May 15 2019
May 13 2019
@Campbell Barton (campbellbarton) I like the inclusion of this setting but I don't think it should be enabled by default.
One common scenario is that when we commit bug reports we load factory settings to test if the bug is tied to our personal preferences or startup file.
After we checked that we just close Blender and now this would destroy our own preferences without a warning. We would have to constantly be aware that this setting is enabled by default and could ruin our own preferences at any time if we make changes that were not intended to be saved.
May 8 2019
@Dalai Felinto (dfelinto)
Unfortunately I wasn't able to try out the Diff so I just read through the description.
Some things were a bit hard to understand but regarding your open question:
Should we have per collection OR per (view) layer collection viewport visibility?
May 7 2019
May 2 2019
Apr 23 2019
@Antonio Vazquez (antoniov) @Matias Mendiola (mendio) @Daniel Lara (Pepeland) (pepeland)
I agree. The optimal drawing feel should be most important. The suggestion of the even spacing of points will feel worse and will make details get lost with to wide spacing but in certain corner cases can have a curve that's easier to work with. The simplify & adaptive simplify are great additions but don't solve the problem of massively uneven spacing or extremely dense curves.
The spacing option could also be used for drawing regular poly curves. I hope that these will share a lot of functionality with grease pencil at some point since grease pencil is so much more advanced now.
Apr 16 2019
Humm, interesting results but as a sculptor, the stronger the cavity effect, the better, for sculpting,
Apr 12 2019
@Andrzej Ambroz (jendrzych)
I really like the third mockup! As another thing to point out: There is currently also the issue with making the selected objects clearly visible when they are within collapsed collections.
Apr 11 2019
Mar 29 2019
@Jack Schaberg (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.
@William Reynish (billreynish) @Brecht Van Lommel (brecht) @Dalai Felinto (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.
Mar 23 2019
@Clément Foucault (fclem) Doesn't seem to help for me either. The materials still end up pink.
Mar 20 2019
Mar 16 2019
@Dalai Felinto (dfelinto) Ah ok. The latest build I downloaded at home clearly wasn't the most up to date. As far as I can see it's now working just as I expected it to.
@Dalai Felinto (dfelinto) I think we had this conversation before during the code quest. Here's my feedback on the topic:
Mar 11 2019
@Philipp Oeser (lichtwerk) I will look into arc. Thanks for the commit. It works just as expected :)
@Philipp Oeser (lichtwerk) I don't think so. I am doing it through the linux terminal based on how some developers at the studio walked me through it. I don't know what arc is ...
@Philipp Oeser (lichtwerk) Sorry I can't use the Diff for some reason. Can you send me a build so I can test it?
Mar 8 2019
Mar 7 2019
Mar 6 2019
@William Reynish (billreynish)
But ... most tools/brushes are not really compatible either in the settings or in how they are used. And these differences make sense.
You can't use textures or colors for weight painting since these are useless for that mode. You can't define options like weights, auto-normalize and multi-paint for vertex painting for the same reason. Some settings are not available for the brush in one mode or another which makes any brush setup in most cases useless and unnecessary to share between modes (especially vertex paint & weight paint).
Mar 5 2019
Mar 1 2019
The naming for delete is pretty clear: "Delete" for the what you selected and "Delete Hierarchy" for the entire Hierarchy of the selection.
"Duplicate Linked" doesn't imply the hierarchy part. It could just as well be the default duplicate linked operator for objects.
Naming it "Duplicate Hierarchy Linked" is clearer but maybe too long?
@Dalai Felinto (dfelinto) Just tried it out and it works great! One confusing thing is the name "Duplicate Collection". It implies that only that collection will be duplicated instead of the entire hierarchy.
I think overall the naming and tooltips are becoming a bit confusing but that's perhaps a different issue.
Feb 28 2019
@William Reynish (billreynish) Vertex could also mean vertex groups or Vertex ID, etc. I wonder how clear it would be that Vertex means Vertex Colors.
Feb 27 2019
Yes I guess that would be more useful than the current way it works but I can't remember if I ever needed that kind of operator. This would be for very specific corner cases.
Feb 26 2019
@Dalai Felinto (dfelinto) I never really saw the current "Duplicate"operator in the outliner as that useful in comparison to a proper "duplicate hierarchy" or "duplicate linked hierarchy" operator.
It can become useful sometimes but often isn't even that much of a time saver in comparison to just creating a new collection, box selecting the old contents you need and LMB + Ctrl dragging them to the new one.
Feb 21 2019
Feb 19 2019
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.
@Andrzej Ambroz (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.
@Harley Acheson (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.
@Andrzej Ambroz (jendrzych) @William Reynish (billreynish) 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?
Feb 18 2019
Feb 16 2019
I would say, no. The least options we have per object the better I think.
Feb 15 2019
Feb 13 2019
@carlos (c17vfx) It's an interesting proposal but this kind of menu would be a nightmare to manage.
Imagine having to click through potentially hundreds of collections and objects to change these settings. Keeping this in the outliner makes it very easy to manage.
@William Reynish (billreynish)
I absolutely agree. The eye and checkmark/excluding should be front and center to make clear what should be used the most. Good tooltips can clear up any remaining confusion.
Feb 12 2019
They way those states relate to the other features are and presented in the UI is so hidden and confusing that very few people will find them, and if they do, it's completely non-obvious how they work,
I'm going full circle. The current way the visibility system works is the most functional for all cases. If we attempt to simplify, remove or merge any of the toggles we would need to make certain use cases still possible by introducing hidden features like locking, more options in object/collection tabs in the properties, leaving the user to do a lot more collection management & potentially more.
Feb 11 2019
Damnit ... in a lot of cases when keeping collections or objects always hidden in the viewport, either in the current file or for linking, is to hide high res geometry that will be used for rendering but is too taxing for the viewport performance. But since the eye icon doesn't improve performance, this becomes impossible.
With view layers and checkmark setups this can still be achieved in my version of the proposal but this setup couldn't be linked over to other files and needs to be set up every time.
Neither of these solutions with 3 toggles and locking can work for these cases.
- Ideally, we could make it so it the linked visibility is set in the scene you link TO, not FROM
- We could set the linked visibility inside the Object > Collections panel
Ok how about this:
@William Reynish (billreynish) I like the proposal but I think we still need to be careful how to implement it exactly. The current visibility system is at least usable in a lot of ways but when attempting to simplify the complexity we could lose important functionality.
When thinking longer about it, I can see one big issue with the proposal as an example:
Why? To me this seems fundamentally confusing, to have two competing visibility states that only affect the viewport
@Dalai Felinto (dfelinto) This is a great overview on how the visibility options work but wouldn't my proposal of the 4 toggles not clearer?
I'm just wondering if we need a full wiki documentation to understand how visibility toggles work, is that the right way?
@William Reynish (billreynish) I have some questions about your proposal.
Feb 10 2019
Yes but by making these options affect both viewport and render visibility it makes it more confusing.
@William Reynish (billreynish)
Well that sounds pretty simple. But just as food for thought:
Makes sense but there's an issue with this:
Feb 9 2019
To give my feedback on this as well: I like it!
But I think it would be more usable as a tab in the sidebar instead of a popup. There's a reason why the Ctrl + H menu was never used, and it's because it was harder to access if you have to first hit a shortcut (or in this case click on a tiny button).
Feb 7 2019
Can we create a new design task for this? I know this is related to the patch, but the design discussion here is getting a bit out of hand.
I'm beginning to think this should be a sub-menu when right clicking a collection in the outliner instead of a separate "Duplicate Hierarchy" option.
Somewhat like this?
More feedback notes:
Feb 6 2019
@Dalai Felinto (dfelinto) The shift click seems to still not work correctly. It works when Shift clicking to hide but when Shift clicking to show it changes the screen icon to an eye without actually changing the disabled state.
If the file gets saved afterwards and reverted/reloaded the disabled state is completely gone ...
More feedback from the rest of the Spring team:
@Dalai Felinto (dfelinto) More feedback from using it a couple of hours:
@Dalai Felinto (dfelinto) I tried it out and it works just as expected except for that Ctrl clicking does only work for collections and not objects. Is this intentional since it's also not mentioned in the tooltip for objects?