I’m all for the node based graph brush thing.
I like bringing things under one roof as well, but wouldn’t that make things too crowded? In many cases, like most production scenarios, it’s 2 different workflows after all. I’d imagine a fusion of Mari and Zbrush would be a nightmare to use for either texture or sculpting artists right out of the box. They would end modifying it to their own needs essentially creating 2 modes.
Not sure, just how I’d imagine it happening.
I like the idea of facesets outlining, esp. if outline will appear only around active/working faceset, where you draw now.
inverted mask is specific way. Yes, it is common pipeline to use unmasked. But it should be optional, perhaps for brush, as condition: If nothing masked, mask all and allow to unmask. If something masked, it is better to keep it.
I just leave existing suggestion about keeping alpha and color separately.
Blender lacks of compact and handy brushsets/toolsets without blowing toolshelf. So I would prefer customizable brush-set instead of current toolshelf. And easy access to switch it to another brushset or old toolshelf. Or brushset pop-up around mouse pointer.
Of course masks for pixel painting should use pixels, nothing else! And they should be available as b/w layers.
Mask overlay — yes, please. Face mask in old vertex paint is already nice.
“it’s 2 different workflows after all”
Because the good option doesn’t exist
If I design a material/brush I want to paint all channels at the same time.
exemples :
Veins, pores, scratches, bullet impacts, face warpaint, rust and so on. Each time it’s diff,spec, rougness, normal/displace.
And I’m not speaking or descirbing something that could be replaced by just material blending
Hi.
I’m curious if this project will then make it possible to implement an easy-to-configure environment for painting directly with Blender materials in real time (Like ArmorPaint for example, not to mention proprietary software).
Since we have a powerful real time engine like Eevee, that feature would be great.
I’m not arguing against painting all or certain selected channels at once, far from it. I’m all for that, as well as node based anything, physics brushes and whatnot.
I simply question if it makes sense in terms of UI/UX to have every texturing tool and every sculpting tool in the same mode. I’d argue it would make things super crowded and would appeal to no one by trying to appeal to everyone.
This brush node graph could have an input node “stroke” with output like start, end, pressure, random, position and so on.
Basic Brushes could be presets, like geonode trees
And those trees can have “outside” parameters displayed in the N panel instead of modifier
In ZBrush RGBAZ are just checkboxes/textureSlots/Sliders
UI is important but not the big deal imho.
The goal is the big deal in the long run
I’m all for tech and new concepts but unless proven otherwise I have to go with facts on this one.
You can probably do all that and more in Houdini, fact is that the majority of artists still prefer a nice specialized package to get stuff done.
Until there’s a proof of concept it’s pretty hard to tell what people would prefer and if it’d pay off to invest all the time and money. I’m sure there’s a reason people prefer Zbrush for concepting and maybe coloring meshes, while they very much prefer Substance or Mari for anything pixel based when it comes to texturing.
Masking based on a texture (Stencil Mask
Can we get UV mapped image based masking in sculpt mode? Zbrush has had this since probably 2003 or earlier.
Please do not forget the text tools
Long ago there was much debate among my photoshop 4 - 7 using friends about its “quick mask”. It turns out only 2 very vocal people in the group used it as-is. Everyone else would go into quick mask, paint over what they wanted to edit, exit quick mask which gives a selection of everything they don’t want to edit, cmd+shift+i to invert the selection.
So as a photoshop user this makes sense to me. But in a sculpting mode there is something intuitive about “marking”/“darkening” the area you care about that I think is more user friendly that lightening it.
I think many photoshop users would agree that they wished quick mask mode would turn the painted area into the selected area instead of having to perform that inversion step. Perhaps Blender can just have an option where after painting a mask it auto-inverts the mask for the convenience of those people who are too lazy to press A and nudge their cursor to the left.
@kevindeguisne
A “node based graph brush” is outside of the scope of this project.
@YAFU
Painting multiple textures/layers at the same time is also not part of this project but the Layered Texture Design.
@Vyach
It would be great to only show the face set contours of the face set under the brush cursor. We’ll have to see if that works performance wise though.
A reworked UI for brushes would be a different project. This should be tackled with brush management.
- Of course masks for pixel painting should use pixels, nothing else! And they should be available as b/w layers.
Can you elaborate on this. What b/w layers?
Can we get UV mapped image based masking in sculpt mode?
Yes, That’s the idea behind pixel masks.
Also yes, the inversion of the masking behaviour should feel more intuitive overall. Customising the mask overlay to be a different color than black is also optional. In sculpt mode it should definitely stay black as it is.
I love the future with these implemented!
Quick question though:
What would happen if I create a texture node, paint (a Mona Lisa) on its canvas then attempt to delete or even just cut the node to the clipboard?
I’m much less careful with nodes than with unsaved, open image documents so this seems like a potential issue to me.
Thinking of alternatives, I think that in Paint or Sculpt Mode, while the selection tools are active (old masks) the selected areas could be colored the same color as in Edit Mode, but with a color gradient, while when using painting tools or sculpture, a contour could delimit the selected areas by approximation, in the same way that Facesets are proposed.
S can be a good key to activate the selection tool (currently scale) or temporarily overlay the selection when hold.
I think this is a good idea when it comes to Dynamic overlays for the mask overlay. That while you use any masking tools, it will show the mask/selection as it actually is, but while sculpting/painting it will show a subtle contour/dashed line.
Another one suggestion.
As far as we can paint to attribute, it will be great to have special mode for painting non-color attributes.
Like weights (heatmap)
Vectors: normalized, remapped to 0—1 visually and with ability to set negative values to brush «color»
Channel painting, lock separately R,G,B,A — really helpful, when you make shadermasks. At this moment I have brush for each channel and separate Add and Subtract, because Add brush do not subtract with Ctrl… And as far as Blender sorts brushes by name, they named like this.
In my opinion modes should be task / workflow related, so if you want to paint, you should have some relevant (paint) mode available. Entering Sculpt Mode to do painting related tasks makes no sense.
I have different suggestion though - I know it is probably too late, but I would still suggest to re-consider that complete dropping of “Vertex Color” term and replacing it by “Color Attributes”.
Vertex Color is the industry standard term used in every 3D tool, in all the tutorials, game engines, various articles all over internet … and even though I understand that they are technically attributes in Blender, I am afraid that mainly beginners will be confused they can’t find such basic thing anymore.
If the naming can’t be reverted somehow, then I suggest to at least change the defaults when creating a new vcols layer, as regular users will never have idea what to choose there: that’s why I think the defaults should be Domain: Face Corner, Data Type: Byte Color, Fill Color: White to get the same result as creating vcols layer in Blender < 3.2.
Another option would be to create the layer using these defaults without any dialog, and if anybody needs to change it, he can always convert it to appropriate format afterwards. Then the behavior would be as simple as in previous versions, but without confusing beginners by those technical terms, and also without loosing any new functionality for advanced users.
Here are some more discussion points related to syncing masks between selection modes and betwen paint mode and edit mode.
(Going further into this reply I will mostly refer to sculpt/paint mode masks as “selections”)
The syncing of selections is not trivial. There are three ways of going forward with the idea. So when switching selection/object modes:
The first would be the easiest route but might end up being frustrating to use.
For edit mode it might be fine to convert a selection but across ALL modes, this could be too difficult to use.
So just like in the example above when switching edit mode selecton modes, when switching from paint/sculpt mode to edit mode, it would convert your selection completely.
But since selections are meant to be discarded very regularly, this could lead to a sleek, usable and clear design across all modes.
The second might sound like the most preferred but could also be the most confusing and least useful.
Try painting a mask on a multires subdiv level 4 (A) and then on on level 1 (B) clear or change the mask.
Going back up to the highest level shows that the mask was only altered on the visible verts from level 1 (C).
We could treat selection modes the same way. So if you switch between sculpt/paint and edit mode, or even change the selection in edit mode, your detailed selection would always be preserved to an extend. It would only become hard to truly clear your selection on the most detailed level.
The third would be the best in my opinion and still not too hard to implement as long as there is an atomic selection element that works for all selection/object modes and can run with good enough performance.
This might be face corner floats for geometry selection, or once a texture is used it would convert the selection to pixel values as the most atomic element.
It might be clearer to then always show the most atomic selection elements in Paint/Sculpt Mode no matter what selection mode is used at the moment.
In the example above:
(A) In Paint Mode, you could already have painted a soft selection on pixels.
Switching to face selection mode would not change the selection. You can from here select faces as well. This will select all pixels that are within those faces.
(B) Switching to Edit Mode would show you an abstracted version of the selection in Paint Mode.
(C) Changing the selection by either adding or removing faces would alter all affected pixels in Paint Mode (D). But the rest of the selection would stay intact.
This idea might break apart if it requires altering the behaviour of other modes like Edit Mode.
have special mode for painting non-color attributes
This is exactly the idea behind “Attribute Paint Mode” which will be developed at a later point.
@jendabek
The name of color attributes is unlikely to change. I do think that the current default when creating a color attribute is the best though. It also ties back to the original name if the default color attributes are “Vertex - Color”.
Although I would extend the basic selection and editing tools in Sculpt Mode, I understand that the goal is to avoid duplication of tools between modes.
Transferring the selection from Sculpt to Edit Mode allows you to perform Extrudes, Insets, Holes, Duplicates and Panels. And from Edit Mode to Sculpt, use the Edit Mode selection tools and protect surfaces with sharp corners.
In my opinion, the 1Conversion option is sufficient for most cases, even if there is a loss, and the 3 Propagation is ideal if it does not involve changes in the Edit Mode structure.
Selections with sharp corners and gradients can be made with Option 1 if the selection is first made in Edit Mode and the gradients are added later in Sculpt Mode (not the other way around).
if i were you guys i’d leave the edit mode out of the painting workflow completely. too cumbersome
+1
someone at bf needs to stop allowing the creation of modes in blender at some point. too much, it’s just too much
it’s time to think about unifying the application, not create more rooms
