- User Since
- Feb 1 2018, 12:48 PM (44 w, 6 d)
@Dalai Felinto (dfelinto) I finally tried it out myself and I think it's great so far and I agree with all the feedback of @William Reynish (billreynish) and @Brecht Van Lommel (brecht) I do agree that the isolating with Ctrl clicking is still very useful and hiding all the components like it currently works should also be easily accessible to the user.
Perhaps we can assign shortcuts this way:
@Dalai Felinto (dfelinto) Sorry I was not able to try it out. Maybe you can send me a build. I can't really figure out what the 3 levels of outliner visibility means from the description alone.
Speed: It's much faster to directly be able to select the UV Editor, rather than first having to go to UV/Editor and then find the UV mode
Well we shouldn't decide weither to split features based on naming conventions :D
Mon, Dec 10
@William Reynish (billreynish) Right now it got split into 2 Editors but I was talking more as in what is planned (Or what I think is planned)
I think I misread one point above. I got the impression that the "New: 2D Paint" means that it becomes its own Editor as well. Would this still be part of the Image Viewer?
I'm all for everything that's said in this proposal. The syncing of the selections could cause problems when a lot of linking is involved but that's why keeping it optional and either completely on or off is a great idea.
I'd like to know more about the reasoning behind splitting the UV/Image Editor into 4 distinct Editors.
I get the reasoning behind making a Mask Editor since the masks are used in other Editors as well, but I don't see any reason for the others.
So we'll we have 3 editors that basically look the same and share similar functionality. To me this change seems very nonsensical and unintuitive.
Are all these Editors going to share the same interface and selected Image anyway, syncing up on all times in terms of panning and zooming? Then why have them separate Editors when we already had them as separate Modes.
Fri, Dec 7
I'd like to know more about the reasoning behind splitting the UV/Image Editor into 2 distinct Editors.
To me this change seems very nonsensical and unintuitive. Now we have two editors that look the same and do almost the same.
When going into Edit Mode now I have to switch between 2 almost identical Editors to see and edit my UVs but when going into Texture Paint Mode the UVs get displayed in both Editors anyway?
And the UV Editor and Image Editor share the same selected texture anyway, syncing up on all times.
Wed, Dec 5
Wed, Nov 28
@Campbell Barton (campbellbarton) I'm personally still for having the switch between global and local if global is the active orientation.
Otherwise the GXX does just nothing. It's like having a shortcut to switch to wireframe mode, except if you are in wireframe. Then the shortcut does nothing.
Doesn't it make sense that there is always a toggle? When the active orientation is global it can just change to the next orientation in the list (the other most used orientation): Local.
Just like in 2.7x when in wireframe mode and hitting Z it switches to solid mode. (The Wireframe example is not 100% applicable but you get my point)
The terms "freezing" and "locking" would make it more obvious what the visibility option is for.
We could make it so you *only* see the eye in the Outliner. The linked visibility is then something more specialized - perhaps something you can enable with right-click on item, which then shows an indicator.
@William Reynish (billreynish)
Usually we don't use the screen icon because it affect the entire file and the files that it's linked to. When we toggle the viewport visibility (screen icon) we want it to stay that way. It's more rigid like the render visibility, which is the advantage of this way of hiding.
Using it for frequent hiding and unhiding is slower than the H shortcut and eye as well.
@Dalai Felinto (dfelinto) We're all very confused and helpless at the studio to be honest :D
The changes that we're commited made it much harder to use the hiding functionality in Blender and as far as I can see the way the proposal is described does not line up with how it works right now or how I can see it working in the future.
Sun, Nov 25
@Campbell Barton (campbellbarton) I agree that the Pie Menus should not be overloaded but I don't think that max. 8 options is too much, as long as the options are distinct, related and often used.
Once all of the options are regularly used the muscle memory takes over and it's not a problem.
So I'd also argue that frequently performed actions are the one thing that should be put into pie menus.
Fri, Nov 23
I got to try out the new Z pie menu and it's ... ok.
To be honest I loved that you can go up or down to toggle overlays and xray in the old Z pie menu. Bringing the old pie menu layout back would be a blessing.
More so because the artists here at the Blender Studio are losing their minds because going down on the pie menu is now switching to LookDev, which constantly results in an accidental crash or a long waiting time of everything freezing ...
Even switching between Solid & Wireframe is weird now since the positions are switched. I know that these points have also a lot to do with muscle memory but it's worth considering
Thu, Nov 22
I tried it out after updating Blender again this morning. It seems to work fine now.
I have a different problem with this change. Could we use the Shading pie menu for a key other than D?
In object mode it was used for the annotations tool and it also makes sense to use the key in the 3 painting modes and sculpt mode for the default draw tool.
I'd suggest to rather have the shading pie menu set to Shift + Z.
Sorry. I meant having a collection with one ore multiple objects (other than empties) in it. That way the objects that are used as an instance are still visible even when empties are set to be hidden. I guess I didn't say "instance" because that term is not used in the properties editor.
Wed, Nov 21
Mon, Nov 19
@Hadrien Brissaud (hadrien)
I also think that removing Tools (or merging them) gives less usefulness to the Toolbar. But all brushes would still be quickly accessible with the RMB menu or in the Tool settings panel for switching brushes like proposed in the description of this task.
But I hope there can be a better way to still select the brushes in the Toolbar without opening an additional popover menu from it.
@Hadrien Brissaud (hadrien) But I am not speaking against brush diversity or having them easily accessible and understandable.
I'm arguing against having a restrictive "one brush per 1 tool" starting arsenal when most of their options could be shared and made available for extra customisation that goes outside of the simple to understand brushes like Clay.
There are many opportunities with digital brushes over physical ones so why not make them all available. Just look at the creative and complex "double action brushes" that Pablo Munoz is building in Zbrush. exposing and sharing settings across Tools is not making them worse.
And as long as the well known and easily understandable brushes are still there and the essential settings are most exposed, it should be fine to add more options.
Difference between Clay and Clay strips is not a setting exposed to user. OK draw brushes have a plane offset. But it is presented differently than height of Layer brush.
@ThinkingPolygons (ThinkingPolygons) I think I agree. It's less problematic right now but the more brushes are created or bundled together, the less usefulness the Toolbar has.
I was thinking of possibly displaying the brushes in the Toolbar as well. Perhaps a Tool could could be expanded downwards like a tab to reveal all brushes underneath or at least the favourite brushes? The problem with this would be that the brush preview still needs to work in a slim toolbar...
@William Reynish (billreynish)
Over the weekend I was experimenting and thinking more about the new split between Tools and Brushes.
If we look at the Toolbar in all painting modes and compare them to the Sculpt Mode, the latter is becoming pretty bloated with single Tools that have only one Brush in them.
So my thought was: How about we merge similar Tools just how we merged similar brushes in the painting modes?
Fri, Nov 16
@William Reynish (billreynish) Sounds like a plan!
Once the brush previews are implemented in Blender I will definitely start experimenting to see which brushes would have problems with the previews. If it's just a couple configurations of settings that are not working as well then it's maybe not even necessary to bring back custom icons. We'll see.
I guess the difference would be in resetting the view matrix, which is part of local view. We could also make it so / only changes visibility for the current viewport, and H/Shift+H/Alt+H do it for all viewports.
@William Reynish (billreynish)
I thought about the dynamic brush previews in sculpt mode for a while now and I think the way it's planned right now works the best. Any other solution I could think of right now is too inconsistent, confusing or overly complicated to implement.
Thu, Nov 15
Nov 7 2018
@Philipp Oeser (lichtwerk) Oh yeah you're right. This is with Open Subdiv. Forgot to add that.
Nov 6 2018
Oct 31 2018
The issue of the volumes not matching with the displacement map seems to be largely fixed T57517.
There are still some small differences but I think these are due to the lack of vector displacement.
Oct 30 2018
Oct 20 2018
Oct 19 2018
Oct 17 2018
Oct 16 2018
@Brecht Van Lommel (brecht) @Campbell Barton (campbellbarton) Are there any plans on fixing this bug any time soon?
I heard at some point that there is more work being put into how the tools for the brushes work and maybe also on how you cycle between them? Is that why this task is on a lesser priority?
Oct 12 2018
@Brecht Van Lommel (brecht) Yes, hiding with H. I am only doing these steps in the 3D view.
Oct 10 2018
Oct 5 2018
@Brecht Van Lommel (brecht) I don't think we should remove the overlay. The main reason (at the moment) why I think, for painting, that the texture overlay is more useful than the Texture on Solid is that it displays the active texture more accurately.
The Texture on Solid Mode on the other hand is washed out and because of that a worse way of previewing the texture and bad for color picking.
Oct 4 2018
Oct 3 2018
It seems we were completely talking past each other this whole time.
Anyway, what we were discussing earlier, is if you want to see the vertex colour mixed with other things.
In 2.8, it's trivial to make a material that combines a texture with a vertex color layer, if that's what you want to do.
Yeah that is fantastic, I agree. But the simple possibilities should also be possible. No mixing, no blending, just displaying the active vcolor of multiple objects in one easy step within solid mode.
The difference between that and the current way of doing it is too big and implementing a vcolor option in the shading panel is not out of the ordinary. It still works with what is there without breaking the norms.
Oct 2 2018
I agree, that when you want to mix textures & vertex colors or multiple of each, then it should be done in the materials.
The only exception to this I can think of are MatCaps but these are used rather for shading.
And the sliders are functional on their own if you want to paint on one object only but they can be very restricting if you work with multiple objects at a time.
I tried out the original implementation in Blender 2.79 and apparently the Ctrl function never worked for VPaint. So this is less a bug report and more a feature request :)
@Philipp Oeser (lichtwerk) As far as I remember the implementation of the secondary color and other improvements to the vertex paint mode from Blender 2.79 came into Blender 2.8 slowly and went a bit back & forth of them being properly implemented.
I can't try out some old builds right now but I remember it working just a few weeks back. No specific time though since I don't use it that often lately.
Oct 1 2018
Sep 27 2018
Sep 26 2018
I don't think it makes sense for it to change while dragging but as an initial dynamic size it could be very useful sometimes. When you are dragging out multiple shapes with the grab brush in succession and each is supposed to have a slightly different size, currently you would have to adjust the size radius every time.
Sep 25 2018
Maybe I'm making too much of a fuzz about this. In the end the position of this button is such a small thing and to be honest: No one in the studio here, or any hardcore user, would ever really pay attention to it. We're all just going to hit Z to switch xray and that's it.
I shared my arguments but if it ends up on the left side, no one is going to rebel and the world will keep spinning.
I get that it's probably the best way to promote users to adjust the way they work but my problem is still, and I know I sounds like a broken record at this point, that xray is not exclusively a selection option.
The visiblity/selectability settings affect both but not just those settings on the right side. Disable overlays like the bones, motion paths, ornaments etc and then try to select any of them. You can't because those settings affect both selection & visibility.
Again, I wasn't clear enough, sorry.
Sorry that I wasn't clear: Moving the slider to the left in the header ultimately wouldn't work. I was arguing of keeping the toggle close to the setting.
I disagree. No matter where we put the toggle in the header, it will take the same amount of space. If anything it would overcrowd the left side sicne there are more options available or at least more space taken already.
@William Reynish (billreynish) I understand the crux of the argument. My concern is just separating a toggle from other connected settings so far away from each other. So far there has been a pretty consistent job of bundling together related settings and options to other toggles. If you think the xray should be positioned to the left then I would argue the opacity slider should maybe move together with it.
Although that would not work really well and you are right: The slider is purely a shading option.
I totally agree :D
There should be a toggle in the 3D view header just as there always was. This information is essential enough to not have it buried it in the shading popup.
I'm unsure about the placement though. Shouldn't it rather be next to the shading popup since they are related and more xray settings can be found in that popup? But then there needs be some clear separation from the mode buttons since it could easily be misunderstood as its own shading mode.
If the toggle is placed way over to the left instead I think it's easy to not make the connection to the xray settings in the shading options. People will assume that it's two settings like before.
Sep 24 2018
Well but I have to disagree that it's "not a viewport shading option". It's both. That's why the occlude selection and xray got merged, to make it both a shading & selection option. So it should be regarded as both. I agree with @Brecht Van Lommel (brecht) here but I get the frustration.
Sep 23 2018
@Clément Foucault (fclem) I agree that it should be turned off by default. This added option can make it really confusing if the user are unaware of it.
They are independent things. One is a shading mode, the other is a tool setting to allow selecting through or not.
I agree with @Brecht Van Lommel (brecht) on the decoupling of the xray settings for wireframe and solid mode. In practice it's just easier this way since you would otherwise constantly use the pie menu twice in succession to switch modes & xray. If each mode remembers their own xray settings this could fix the issue.
This can be an optional setting like the "Lock Object Mode" is. Adding an option in the preferences for "Lock Xray Settings" would be my suggestion.
Sep 22 2018
@William Reynish (billreynish) I already know that these are old mockups but they demonstrate an idea that was discarded but that I think is valuable and still relevant.
So far working with the current UI for a few months now I have some more notes, mainly about the sculpting & paint modes. It's about some information that can be revealed and made accessible by default without taking up too much additional space.
Here's a mockup: