Since Texturing became one of the main development goals for 2022 there have been a few improvements in progress.
An important missing part of that design is still the Paint Mode itself. This post will explain the current conclusions and open questions of where we are heading for the most important functionality.
By sharing this we hope to get more feedback and suggestions from the community.
Some of these features would benefit greatly from using the proposed texture layer nodes.
But until then we will make the features usable with the currently available features.
Based on Sculpt Mode
To make the mode structure clearer we are aiming to use Pablo Dobarroās design for modes.
Paint Mode will be based on the code of Sculpt Mode, which means it will inherit a lot of its features and fast performance.
The mode will replace the existing Texture Paint and Vertex Paint Modes and will provide the full tool set for artistic painting of color attributes & image textures.
What you will paint on can be set via the Canvas selector.
Toolset
To cover all workflows the Tools need to be extensive. A few tools and general operators will be the same as Sculpt Mode, like masking, face set and automasking features.
But overall the Toolbar would include these most essential tools:
- Paint Brush
(A new 3D painting brush based on the new sculpt mode paint brush and the work on PBVH texture painting.) - Draw Brush
(A simpler brush meant for pixel art. Will make it possible to paint single pixels and faces.) - Projection Brush
(A brush that is much closer to the original texture paint brush. This one will use proper occlusion for 2D projection painting and use of stencil masking.) - Erase Brush
- Smear Brush
- Blur Brush
- Clone Brush
- Draw Face Set
(Used for drawing face sets. More on that further down.) - Mask Brush
- Sample
- Mask by Color
- Color Filter
- Gradient
- Gesture Tools
Masking Modes
In the current painting modes there are various ways of masking. Including all of these in their current form in a single Paint Mode would lead to a muddled and confusing design.
But still, these ways of masking should be supported:
- Masking per vertex (Like Sculpt Mode masking)
- Masking per face corner (To achieve sharp edges on color attributes)
- Masking based on selection (Synched with edit mode)
- Masking based on a texture (Stencil Mask)
(Mockup of masking modes)
The proposal is to add three easily accessible āMasking modesā that can be switched with the number keys. This directly parallels the selection modes in edit mode, grease pencil and the UV editor. And just like in these other modes they should be interchangeably usable for intuitive and fast masking.
The 3 modes would let you:
-
Mask Vertices
Same behaviour as sculpt mode. -
Mask Faces
Also similar to sculpt mode but with the ability to mask face by targeting per face corner data. -
Mask Pixels
This feature should replace the current āStencil Maskā but with full support for sculpt mode masking features
These masking features are meant for loose and temporary masks, similar to selections in other modes. For more permanent masking for material and texture mixing it would still be referred to paint image textures and use them as masks in the material.
Open questions:
- Will the sculpt/paint mode mask need to be always stored as face corner data to make this possible?
- Available masking modes likely depend on what data is being painted? (Vertex colors, face corner colors, image texture)
- How can, or should, image based and geometry base masks be synced? Syncing them would make switching between them more intuitive, but only if this doesnāt result in data loss for masks
Perhaps Pixel masks need to be an opt-in feature. If disabled the masking features will target actual vertices and faces. Once enabled all masking modes and tools will result in editing the image texture of the pixel mask. - Pixel masks will likely be stored in the object for now. But should this eventually become part of the Texture Layer design? This would make it easier to keep the resolution of the painted textures and pixel mask in sync.
- For pixel masks do we need better automatic UV map creation? The use and creation of pixel masks should be as easy as possible.
Until then it might be necessary for users to create/define a texture and UV map just like in the current stencil mask options.
Syncing Edit Mode Selection
A very useful feature of the current painting modes is that the mask and selection are synced. This way masks can be much more precisely created in Edit Mode.
While switching between Edit Mode should not be required - masking in Paint Mode should be intuitive enough - some workflows rely on this for painting precise attributes and technical textures.
So keeping this functionality will be a priority!
Supporting this will not be straightforward. Paint Mode masks can either be per face-corner floating points or RGB image textures, while Edit Mode selections are boolean values.
In the case of per-face corner floating points there can be a threshold of what value is considered selected in Edit Mode. The ideal value would probably be 1. So any vertex that is completely masked will show up as selected in Edit Mode.
Itās important that switching modes will not result in data loss for masks. So only if any part of the mesh is being deselected or selected, will those elements be updated in the Paint Mode mask. The behaviour should be predictable and intuitive.
Open questions:
- How can, or should, the Edit Mode selection be synced when using the pixel mask?
If no clear solution can be found we could disable syncing with selections if pixel masks are used. This would relate the the previous open question of making pixel masks an opt-in feature
Inverted Masking
The typical workflow issue when using masks is that users mask a section of their mesh and then invert the mask.
In most cases the areas you mask are the ones you DO want to edit.
So a long time proposed change can finally be implemented by inverting the behaviour of masks in general. This would also make it much easier to sync selections and masks, since they both define the elements you CAN edit.
The expand operator has already used this updated design ever since it was released and it led to a more usable tool.
Open Questions:
- The name āMaskā might end up confusing if the behaviour is flipped. You are no longer masking areas then, you are masking everything else.
Renaming them to āSelectionā might be a good change, especially if masks are synced with Edit Mode selections.
Mask Overlay Color
The mask overlay should also be updated to make it more useful for painting workflows.
(By adding a color option, it should be easier to customise the look of masks for texturing needs. Credit for the model shown goes to Daniel Bystedt)
Instead of only having a slider for multiplying black on top masked areas, there should be options to mix in a custom color.
Saving Masks
A small addition that is much requested and would end up very useful is to save and load masks for later use.
This is useful when an intricately created mask needs to be changed or discarded but would result in too much time lost.
This would be as simple as saving geometry based masks as generic āFace Corner - Floatā attributes. Since pixel based masks would require an image texture it is already easy to replace and store them as well.
ID Maps and Face Sets
An important feature that will be necessary to implement with the upcoming Texture Layer design are ID maps. They are already very similar in their use to Face Sets and can help in effortlessly creating masks and layering materials.
There are issues with storing and using ID maps as single images though:
- Anti-aliasing between id colors usually result in visible gaps. The alternative is not using anti-aliasing which is also not ideal.
- Too similar colors can result in bleeding and inaccurate masks
- Compression can lead to inaccurate masks
The proposal would be to instead create a unique version of this concept in the form of āPixel Setsā within Blender. Instead of saving a single image, we could save a set of grayscale masks that are auto-normalised to avoid overlaps between them.
This way we can avoid all issues mentioned above.
Just like with Masking Modes, there should be a toggle to use either Face Sets or Pixel Sets, if available. If Pixel Sets are used they would offer the same features as Face Sets for quick control of viewport visibility, creating masks and automasking.
Open questions:
- How can ID maps be imported and exported while Blender uses Pixel Sets internally?
- Do Pixel Sets have to be an opt-in feature like Pixel Masks?
- Pixel Masks and Sets should ideally be part of the Texture Layer nodes to keep them consistent in resolution and use UV maps with the material that is benign painted.
Are Pixel Sets until then even useful or should Face Sets be enough? - The use cases for using ID maps for the same functionality of Face Sets is not clear. Would this be useful or would Face Sets be enough for managing temporary masks and viewport visibility?
If so, then it would be better to keep using the term āID mapsā and only use them for easy material layering.
Dynamic Overlays
Just like mentioned before with the mask overlays, itās not ideal to have the color information on the object obscured.
This was already a long term concern with Face Sets and should finally be addressed with Paint Mode.
The issue is that the Face Sets - and eventually also Pixel Sets - are always visible which makes painting hard or they are completely turned off which makes it hard to use them.
(Current way of drawing face sets and proposed contours at 100% opacity)
The proposal is to add an option to make the overlay dynamically visible whenever it is used, edited or otherwise necessary to see it.
For example when using tools like Face Set Draw or Expand while snapping to face sets, you would see the face sets completely filled. But otherwise face sets would be hidden.
If options like automasking by face sets are enabled it would be best to show the face sets in a more subtle way like contour lines, so that they are less distracting.
Image Editor
While updates to the Image Editor are also important, this is its own big project that should come after Paint Mode. But to make the feature set complete itās important that the same or similar overlays, tools, operators and masking options are in sync with the image editor.
This can also be explored further with the inclusion of the Texture Layers design.
Feedback wanted
These are a lot of design decisions that will have an impact on Painting and Sculpting in general. To make this as intuitive as possible we want to get more feedback from as many different perspectives as possible. Nobody should be left out.
If anything in the proposal wasnāt clear enough also donāt hesitate to ask questions.
Important notes from Feedback so far
- Inverting the masking behaviour everywhere for everyone should also be a user preference or tool setting. That way it should still be possible to create a mask brush to mask off small areas by just painting with the brush. Same for gesture tools like lasso masking.
- More good reasons to rename āMaskā to āSelectionā in sculpt mode and paint mode is to make it obvious that they are meant to be quickly created and discarded, like edit mode selections.
If users want to create a proper mask, they should create an attribute or image texture to paint on, which can then be used for mixing/layering in shader and geometry nodes.
These are two very different use cases for masks, so naming them something different makes sense. - The dynamic overlays could also be extended to masks. So if no masking tool/brush is used, the mask would be displayed as a contour line
- Greying out or even hiding selection modes depending on the data you are painting on would not be a good idea. Especially in Paint Mode, the user could switch between painting on various color attributes and image texture regularly. Selections/Masks should stay consistent and understandable when doing so. Same when switching to Sculpt Mode.
- Converting the painted mask whenever the mask mode is changed, or when switching to Edit Mode would very likely be the easiest and most usable solution. Trying to propagate or abstract the mask between modes would make the behaviour far less predictable and for questionable advantages. Selections are meant to be temporary and quickly & regularly discarded after all.
