@Philipp Oeser (lichtwerk) I experimented a bit more and I found out that I left a step out of the description. You need to have work with multires subdivisions. I will update the bug report.
Mon, Jul 6
Fri, Jun 19
I've tested the feature for a bit and it seems to work fine most of the time. With clothing pieces that are close to each other this makes it far easier to pose characters.
The only odd thing I kept noticing is that the pivot point becomes increasingly unpredictable with a higher "Max Element Distance".
Tue, Jun 16
Ok apparently instead of using the custom shortcut I mentioned, this can also be more easily replicated by just using undo, exiting sculpt mode and entering sculpt mode again.
The same effect is then suddenly visible.
Fri, Jun 12
@Germano Cavalcante (mano-wii) I just tested it on another computer as well and I can reproduce the bug with the outlines steps.
In your file you didn't make any changes to the shapekey. You need to model or sculpt changes on the base resolution (level 0) since the multires subdivisions are not changing the base and therefore don't affect the shapekeys.
Thu, Jun 11
Wed, Jun 10
Jun 5 2020
May 13 2020
May 12 2020
Apr 28 2020
Apr 24 2020
@Pablo Dobarro (pablodp606) What if the behavior of the Tab key changes to 'on release' instead of 'on press'.
Then the Tab key could be held down as a modifier key and Selecting another object (LMB/RMB) will switch the object and copy the mode.
Just throwing around ideas.
So for the keymap ... what about something close to what already exists. With Ctrl + Select you can select another object even if you are in any mode other than object mode. In every one except for edit mode it even switches the active object and switches to the mode that was last used for that object (You need to disable "Lock Object Modes" though).
The big issue right now is that the user still needs to set up the mode manually for each object after switching.
@William Reynish (billreynish) Yeah I totally agree. In my case I have like 4 tabs in most cases that I use and the rest is well described as a "wasteful bar". That would be the case for most users.
What if the tabs would get cut off at some point to leave more space for the editor underneath?
@William Reynish (billreynish) True, but who would willingly have the proposed list long enough to show more than 11 tabs? That's taking a huge amount of space that should be reserved for the actual content of the sidebar, right?
A while ago I put some custom tabs in my sidebar via addons so here's an idea of how much space the list would take with 11 tabs (in my case it's vertex groups).
That's half the sidebar.
This does seem to fix some the issues listed above but I am worried about the issues this design might bring with it. Also I think the key issue with the current tabs in Blender is if there are too many tabs. The other issues seem kinda nitpicky to me.
Apr 21 2020
Apr 17 2020
Apr 15 2020
Apr 11 2020
Apr 1 2020
It works fine once anti-aliasing is disabled.
Mar 31 2020
Mar 27 2020
Mar 26 2020
@Richard Antalik (ISS) It also happens on factory settings. I am using a Wacom Intuos M.
Mar 24 2020
Mar 20 2020
I strongly agree with @William Reynish (billreynish) here. You may read and carefully pick the pie menu options at first but since there are only 4-8 options to memorize for each (and for some you don't even use all of them most of the time) it's very easy to remember where the desired options are.
So after a minimal amount of time using the pie menus you start learning the gestures instead of using them as buttons.
The visual design needs to be improved so this doesn't look like bug anymore but the core design and usefulness of pie menus shouldn't be harmed.
Mar 18 2020
Mar 17 2020
Mar 15 2020
Mar 11 2020
Mar 10 2020
@Pablo Dobarro (pablodp606) The earliest build with the face sets I have is 5be0e3430d13 and it also happens there.
In the latest Blender version dc8bb3f3a0bc it's actually worse since the face sets are bleeding into the white default face set randomly (in addition the the other mentioned glitches).
@Pablo Dobarro (pablodp606) Ok I also just discovered that the workflow I described above is a bit different than I thought.
If you have 2 different smooth brushes in the Smooth Tool, switch to the second brush, switch back to another tool and use Shift to smooth, then the Smooth Tool has the first brush assigned again.
This is a bit bizarre behaviour and make it less predictable which smooth brush will be used when pressing S.
I agree with @Metin Seven (MetinSeven) that the Zbrush way of alternating between the 2 smoothing methods is the most convenient but it needs to be properly explained in a Tooltip since it 's a very unusual behaviour for Blender.
Zbrush often changes the current operation if a key is no longer held but Blender does the opposite and keeps the current operation unless a new key is pressed.
Mar 9 2020
@Campbell Barton (campbellbarton) I do really like the idea behind this feature. But I tested it out a bit and I found that even with the default threshold of 30px, I am constantly accidentally activating the operators with G/R/S since I am moving the mouse often & very quickly when using a pen.
When pressing the keys quickly it also isn't registered some times and the tool won't switch. I don't know what's causing that though.
But yeah, I find the feature extremely hard to use when working fast and not stopping my mouse movement every time I press a key.
Mar 4 2020
I tested the patch a bit and I found visual bugd when having a vertex color layer, drawing face sets in a color mode other than vertex colors (like random or material) and then switching to vertex colors.
The colors just completely glitch out. Can someone else confirm this.
I also noticed that sometimes face sets are still visible as wires or in white when being toggled and take a moment to catch up.
Mar 2 2020
@Pablo Dobarro (pablodp606) I wouldn't apply the scale automatically since users can enter sculpt mode by accident and don't always want the scale applied. A popover to ask the user if they want to apply the scale would be better.
@Brecht Van Lommel (brecht)
Yes I agree that currently it's not ideal or should be advised to work with non-uniform scale on objects.
Transforming the objects in edit mode is extremely slow on high poly objects but luckily we have the transform tools in sculpt mode now too.
Feb 28 2020
Feb 24 2020
@William Reynish (billreynish) Maybe it's better to show the operators but greying them out if they can't be executed?
I think it's still very important to find the thing I'm searching for, otherwise I would think it's gone.
Feb 23 2020
Feb 22 2020
Feb 21 2020
I second this.
@William Sitton (william) Reynish : does this proposal support binding the ESC keymap to the select tool? One of the challenges of the tool system currently is that my existing muscle memory struggles with exiting the active tool. If I could bind the ESC key, I could exit the tool the same way I exit its operator equivalent. Of course there might be a conflict between
- hitting ESC while actively manipulating a widget =>should cancel the widget manipulation but remain inside the tool)
- hitting ESC while not manipulating a widget => should activate the tool tied to ESC
@William Reynish (billreynish) @Campbell Barton (campbellbarton) @Brecht Van Lommel (brecht)
I would really love if this patch get's another look. To use the Active Tools efficiently they need to be properly included in the keymap.
I have been testing a custom Active-Tool-only keymap and I'm pretty happy with it.
It would help a lot of that becomes an option.
Feb 20 2020
Feb 19 2020
Feb 18 2020
I originally brought this issue to Dalai because I am using vertex colors also for pre-viz in workbench just like material colors.
Interestingly when no vertex colors are detected, the color will default back to object colors.
Since I needed to define some objects as trasnparent I had to use object colors as a result since vertex colors don't have an alpha value.
This is where the issue of instancing came in since all instances replaced the object colors I had set up.
Feb 14 2020
Feb 13 2020
@Pablo Dobarro (pablodp606) Looks good. Fits much better with the other cursor colours now.
Feb 12 2020
@Pablo Dobarro (pablodp606) I tried it with lower strength and the higher strength seems to just make the ripping happen faster. If a stroke is going over the same surface multiple times it eventually rips.
Jan 29 2020
@Pablo Dobarro (pablodp606) This works really well as far as I tested it now. I would personally mostly have it reserved for the "Smooth" and "Slide Relax" Tools so I'm glad that the option also works by accessing the smooth brush via holding Shift.
I noticed the limitations too but I don't have anything else to add.
Jan 22 2020
Seems to work fine and grouping options better together sounds good to me.
Jan 20 2020
Seems to work fine for the other brushes too!
The rotate brush is the only one that is excluded right now but I'm only mentioning it to make it consistent. I don't think anyone uses the rotate brush much ...
Jan 17 2020
@Pablo Dobarro (pablodp606) Ok I tried it out and I actually love it. I thought the drag threshold would be way more annoying but it works really well!
I think this is more useful for corner cases but it's better to have this than a pressure sensitivity button that doesn't work or doesn't exist.
There are moments in the Spring production where I wish I had this feature since it would've saved me from pressing F a million times.
Jan 16 2020
Vertex position snapshots are the ones that work exactly like layers, so I think it is better to have more advanced layer features instead of adding this to snapshots.
@Pablo Dobarro (pablodp606) Fair enough. I think it's the best case if the snapshots are fast, temporary, on-at-a-time way of storing data.
So why not see it as something that goes hand-in-hand with other types of data instead of something that conflicts with them. Here's what I think snapshots could be:
@Pablo Dobarro (pablodp606) Looks and works really well! What if both Snapshot methods are working outside of the Undo Stack, which makes it so powerful. If users know that their snapshot will be saved while going back & forth in the undo stack it becomes a massively useful feature.
I wrote T56930 a while ago and there are actually 2 brushes that are using the pressure sensitivity for the brush size and that is Nudge & Thumb. There it becomes clear how this becomes an issue.
Because the size gets sampled from the pressure sensitivity at the start of the stroke the user still has no control over it since it will often be too small or randomly close to 0.
If we add a Drag Threshold so that the user has time to define the pressure sensitivity a bit more, then there will always be a delay which is already an annoying issue for when using the Tool Gizmos in LMB select.
In my opinion, I would prefer using multires layers as the main "storage" system of sculpt mode and leave this for quick shape exploration.
@Pablo Dobarro (pablodp606) I'm testing it right now and the first thing I am noticing is the constant need to remesh, This is because the snapping to the snapshot target is not very accurate. I'm assuming that the method used is similar to "Target Normal Project" or "Nearest Surface Point" in the Shrinkwrap modifier.
Jan 15 2020
@William Reynish (billreynish)
Some more notes:
Ok I tested it a bit and my only worry was that it would be harder to pinch a point instead of a line but that is still possible when circling the stroke a bit. Not sure if I this behaviour would make sense for the crease and blob brushes as well.
But I agree with @William Reynish (billreynish) that the old method should just be replaced for this brush.
@Pablo Dobarro (pablodp606) My opinion: Hell yes! Make this the default. Not sure if it's worth keeping the old way as an option ... Possibly yes.
@Pablo Dobarro (pablodp606)
Overall this all sounds pretty good. One thing that concerns me right now is backwards compatibility.
Like @William Reynish (billreynish) said there is an important use-case for multires at the moment:
Jan 13 2020
Since you would have to click on the output you want to render at any time anyway, using the Node Wrangler Addon to Ctrl + Shift on a node is just as valid as a workflow.
As long as the eevee output is selected it should be just as fast to use.
Sounds like a workaround and it is ... at least until this Node Wrangler feature get's a fully official default implementation.