- User Since
- Feb 1 2018, 12:48 PM (36 w, 5 d)
@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?
Fri, Oct 12
@Brecht Van Lommel (brecht) Yes, hiding with H. I am only doing these steps in the 3D view.
Wed, Oct 10
Fri, Oct 5
@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 Mode 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.
Thu, Oct 4
Wed, Oct 3
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 in 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.
Tue, Oct 2
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.
Mon, Oct 1
Thu, Sep 27
Wed, Sep 26
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.
Tue, Sep 25
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 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 if it wasn't clear: Moving the slider to the left in the header ultimately wouldn't work. I was arguing of keeping the setting close to the toggle.
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.
Mon, Sep 24
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.
Sun, Sep 23
@Clément Foucault (fclem) Sounds good to me. 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.
Sat, Sep 22
@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:
I went through some original design mockups of the toolbar again and saw that one draft depicted different views of the toolbar and customisability:
Fri, Sep 21
Thu, Sep 20
I think it could very well work in an overhauled sidebar but the pinning will still be useful to implement in that one then. Sometimes you would want to have the interface of an addon like Blenrig visible on the side even when going fullscreen but while also having the transform properties visible at the same time. So pinning them makes them both visible without switching tabs constantly in the future sidebar.
it's just a shame of not being able to use the space in the toolbar if available space on the sidebar would run out. The current way is more clean bu the things that were removed were able to be more useful were they were.
An alternative would be the concept of the 3D View Sidebar in the task T55407, described under "2: Panel Addons" but I wonder how customisation this space will be, how it interacts with the N panel and if this concept is still planned to be implemented.
I finally want to share my concerns and suggestions for the current design of the toolbar itself.
Wed, Sep 19
@Ludvik Koutny (rawalanche) It already is it's own tool at the moment. It's in the tool dropdown together with Box & Circle select so I don't think it makes sense to add it to the box select tool.
But there should still be a shortcut related operator to access it without switching the active tool, the same way it works right now. If it's included in the box select operator as well you would press B and then instead draw a lasso with RMB or by holding a modifier key?
That's not really clear enough if you don't know how to access lasso select.
Another thing I noticed is when assigning Ctrl + RMB to setting the 3D Cursor, then there needs to be a new shortcut for the lasso tool. Actually I'd like the lasso selection to get a simple key like B & C for Box & Circle select. These work fine for them so it can work for Lasso select as well.
But maybe that's not really possible since most are already taken in Edit Mode and reassigning it to a key might require reassigning of other keys as well.
Maybe the shortcut for the 3D Cursor can be Ctrl + Alt + RMB but this likely just involves too many keys.
Tue, Sep 18
@William Reynish (billreynish)
Yeah I see now where there have been some misunderstandings. I was also under the impression that these tools were planned to be further separated in the future. That possibly still came from some miscommunication during the code quest.
I think I can very much get used to Ctrl + RMB for setting the 3D cursor but using Alt + LMB or Crtl+ LMB is definitely a problem with selection. I hope there can be a good solution for that but unless emulate-3-button mouse is enabled this shouldn't be an issue anyway.
If you use any of the transform tools and disable Click Anywhere, the input will fall back to selection. But, just like in 2.79, this is a quite bad. It means that it's not possible to select items that happen to be under the Gizmo. But if you really want to do it that way, you will be able to.
@William Reynish (billreynish) Well my points are these:
- Where before you could use Select, 3D Cursor & Transform Gizmos at the same time they are now changed into Tools to switch between. This makes the Toolbar a mandatory element that has to be used, either trough shortcuts or by selecting the tools.
- Putting essential operators into separate Tools adds an extra step to switch between them, slowing you down in the process. This is not the case with others since the traditional operators still exist (G, R, S shortcuts for example)
- Using Tools consecutively by leaving it active and changing selections is no longer possible in LMB select, since the Tool needs to be switched after each use to the Selection Tool. This removes one of the advantages of using Tools for the average user.
These are inconveniences, minor for some, major for others.
@Ludvik Koutny (rawalanche) I actually kept working with LMB select for years, only switching a few times to test out the alternative, and am currently the only LMB select user at the Blender Institute as far as I know :D
So far it felt better to use as a pen user and there weren't really any downsides for me to use it.
Although I do agree with you on muscle memory and the benefits of switching to the common keyboard setup etc, that was not really my point. I was just discussing the minor loss of efficiency with the most common operators being replaced with these new tools.
As far as I can tell right now, LMB select in Blender 2.8 will be no longer be equally as usable, even if not by a huge amount.
True, I think users that don't have a keyboard or are used to a more industry standard approach are better served.
And as long as all major tools have easy shortcuts to quickly switch between them, it can still work very fluently. I also like the suggestion that when using the operators instead, the related tools light up to show the connection so that the shortcuts and tools are not entirely disconnected in the old way of using Blender.
I feel very conflicted about this proposal. On one hand I love how it makes the LMB work consistently with all tools. It eliminates the conflict pretty well.
On the other hand I think one good thing about the toolbar is that if the user plans to use a tool often you can just keep it active, use it, select something new, use it again, rinse & repeat.
This works nicely in RMB select but if the user needs to constantly switch back to a select tool, they would quickly just ignore all tools and use the operator hotkeys instead and keep the select tool active at all times since it's basically the most essential operation. It just adds more tedium since there's always an extra step of switching the active tool back & forth when using the toolbar.
Mon, Sep 17
@Bastien Montagne (mont29) I just update Blender with the buildbot. How can/should I update the OpenColorIO manually? Are you having the same issue?
Sep 10 2018
@Brecht Van Lommel (brecht) I am currently working with the latest compiled version of Blender 2.8.
@Brecht Van Lommel (brecht) All of the color picker types act out but the default only once you change the HSV sliders to the maximum.
I noticed that it does actually work as it should (mostly) for the HSV sliders but the RGB ones all act wrong.
These three don't match with the HSV values or the graphic color picker.
Aug 24 2018
Aug 23 2018
@Clément Foucault (fclem) I think it takes double the performance with overlays on but all additional overlay options disabled. With wireframes, etc it gets drastically worse.
@Clément Foucault (fclem) But this is still going to be resolved at some point, preferably before the beta? This seems like a big flaw to me in terms of performance. If the design dictates that the mesh is always going to be drawn twice then it should be changed/adjusted to fix the issue, right?
Aug 21 2018
Aug 20 2018
@Erick Tukuniata (erickblender) Yes. Yes I am encountering this problem because it is due to this bug. But it makes no sense to unpack a discussion between a couple of people about changing the design decisions of the toolbar within a simple bug report. There are separate tasks for this to comment in :D
@Erick Tukuniata (erickblender) That is a different issue though. This task is just the bug report that the shortcut cycling doesn't work anymore.
This bug actually bothers me a lot during my workday. Not being able to rely on the shortcuts and having to click through the popups in the toolbar slows me down quite a bit.
Would be great if someone fixes this one soon.
Aug 16 2018
Aug 15 2018
Aug 6 2018
Jul 26 2018
@Bastien Montagne (mont29) The point of using a stencil texture is to move it around ;)
Reseting the transforms just puts it back to the original position but doesn't fix the issue.
The problem I have is that once I start painting, the texture doesn't match with what I am painting:
Jul 24 2018
I haven't encountered this bug for a while. I guess it was already fixed during the Code Quest.
Jul 20 2018
@Bastien Montagne (mont29) Yeah I created this bug by mistake since I had a custom eraser brush for years prior to 2.8. It would be great to have one as a preset though, but it would be better to just overhaul the texture brushes in general then.
Jul 17 2018
I counted on the alpha material and with the colorramps and curves it leads to 28 textures. That should match with the texture limit. We use colorramps and curves a lot, so I agree it would be fantastic if those could be grouped. If that even makes the jacket material work, then that would be great. That one is needlessly complicated anyway but I think this will happen rather often when texturing and if Eevee can handle that then that would make it even more powerful for texturing/shading previews!
This is weird to me since I am only using 7 custom textures in the alpha creature material and I believe even less in the jacket. What qualifies as a texture? Do procedural textures count? If a texture is used for multiple different channels like diffuse, bump, specular, does it count as one for each? If yes then that seems like a big problem to me since the most efficient way to texture paint is to use one map for as many material inputs as possible.