The purpose of this task is to discuss the UI/UX design of the features included in the sculpt-mode-features branch.
Cursor, normal radius and brush parameters
- Right now the cursor is disabled when previewing textures and in any other paint mode. Should we support this even if the modes are not compatible with normal projection internally?
- Curve presets are nice to have, but they are conflicting with the curve option of the brush. The most important curve preset right now is the smooth curve for grab, so we can:
- Disable the curve presets completely and add an option to the grab brush to use the hardcoded smooth curve
- Merge the curve presets and the brush curve panel into one, with a “use curve preset” checkbox
- A normal radius of 0.0 won’t produce any deformation (the same as 0 radius or 0 strength), but this option is currently hidden inside a popover. Should we add this option to the top bar, or maybe show a warning when sculpting with 0 normal radius?
- Normal radius behaves weirdly with dyntopo enabled. This is expected, as you can’t crease an edge while collapsing it. Should normal radius default to 1 when dyntopo is enabled?
Blender should include several remeshers, designed both for blocking and for automatic retopology to use the sculpt with the multires modifier. They should have the following properties:
- The remeshers configuration should be stored per mesh. This includes the desired algorithm with its parameters and the reprojection options (mask, vertex, weights). This is especially important for the voxel remesher, which needs to be run several times when blocking a sculpt without interrupting the workflow.
- The remesher options will be displayed in the top bar, next to dyntopo. The configuration is stored in the mesh datablock, so maybe it should also be displayed in the mesh datablock panel.
- The remesh modifier could read these options from the datablock when added and apply them. This should be useful when working with OpenVDB booleans from sculpt mode.
- Right now you can undo a remesh operator, but you can’t redo it from the undo stack without applying the remesher again, as it would require to copy the whole mesh resulting for the remesher twice (once for undo and once for redo). Should this be supported?
- A quad extractor remesher could take several minutes to finish. How are we going to display this in the interface? Should it block the whole interface when running?
- Should we limit the size of the OpenVDB grid size? Some users working on really small objects reported that the current voxel size limits are not enough to achieve the desired level of detail, but giving the option to go directly to a small voxel size with a huge mesh will crash Blender.
- Which quad extractor remesher are we going to support? Right now we have LibIGL/QEX in the branch, but Quadriflow should be better and with fewer dependencies. Can we develop a custom quad extractor remehser?
Sculpt Vertex Colors
The sculpt vertex color data is not compatible with the current vertex color data. In order to keep supporting the functionality of the current vertex colors, we could do the following:
- Keep the current vertex paint mode as it is. This mode will affect color data stored in the loops.
- Sculpt mode should have a global “affect colors” toggle. When enabled, compatible brushes should expose color options and color pickers and palletes should be displayed.
- When enabling this option, the user should be warned because he/she may lose color data. Sculpt vertex colors are stored per vertex, so they can only store a single color per vertex.
- Blender should copy the color data from the active regular loop color layer into sculpt mode vertex color layer. Once the user switches the active color layer or exits sculpt mode, the color data will be copied back to the loop color layer. This approach is relatively easy to implement, but it is not compatible with painting from sculpt mode with EEVEE enabled.
- Which brushes should support vertex colors?
- When vertex colors from sculpt mode are enabled, the brush texture should be interpreted as a color texture or as an alpha?
- Right now the branch has a Paint Brush in sculpt mode, which only affects vertex colors, optimizing the undo operation. Should this be kept?
- If we port all the vertex paint tools to sculpt vertex colors we can leave the current vertex paint mode as an “attribute paint” mode for the everything nodes project. For that kind of task, brush behavior and performance won’t be that important, and we are going to reuse a lot of code from sculpt mode. Can this option be considered?
- Other option could be keeping the current vertex paint mode while switching all the internals to sculpt vertex colors. The IU should be exactly the same, but internally you are going enter sculpt mode when selecting vertex paint. This also brings the advantages of more code reuse, better brushes, performance… but we may lose the ability to have a vertex color per face.
Mesh, mask and color filters
These tools implement several operations which affect the mesh as a whole. The user can select the desired filter from the toolbar and apply it by dragging the cursor on the viewport.
- Some filters, like smooth, require several iterations to be useful. Previewing this in real time would take an insane amount of memory. How can we solve this?
- Real-time preview support for some filters may take a lot of resources. Should we add an option to apply the filter directly without the interactive preview? We can’t use the redo panel for the same reason, unless we add some kind of "update" button to it to apply the changes manually.
- It would be very useful to have the mask filters mapped to the keymap by default, we should find good default for this, as switching to the mask filter tool each time you create a mask is not a good workflow.
The transform tool uses the same gizmos, snapping and constraints as any other transform operator in Blender. This tool is often used for posing, so it includes several operators to position the pivot point automatically, as well as the mask expand operator, specially designed for posing characters.
- We need to think about how to implement all the set pivot position options. This could be a “set pivot” menu, similar to the “merge” menu of edit mode.
- The transform tool should have a “move pivot only” option. For this to work, it would be nice to have the gizmo always visible during transform. Should this be added as a tools setting, as a keymap option or as a separate tool?
- The mask expand operator should also be added to the transform tool keymap from sculpt mode. Could it be mapped to a mouse click and drag gesture?
- Should we use the 3D cursor as the default pivot for the transform tool? This way, users would be familiar with the operators to position the pivot, but that was not the intended use for the 3D cursor
- We can’t rely on the redo panel for the same reason explained in the mesh filters section, so maybe the redo panel should be disabled. Are we going to support redoing transform operations with another method?
Masking tools and automasking stack
The automasking stack should allow the user to use several automasking operations at the same time. For example, it should be possible to grab only the vertex connected topologically, ignoring edge borders, and affecting creases with a 50% strength. The UI for this could be quite complex. So, in the first version, supporting only topological masking with a checkbox should be enough.
- The branch includes several masking operators which are really useful (mask by color, mask by normal…). These operators depend on the active vertex highlighted by the cursor, so they only can be executed from the keymap. How can we add intuitive shortcuts for this?
- Furthermore, some of these mask generation tools have a lot of parameters (tolerance, invert…). These parameters can’t be changed from the redo panel for performance reasons (which in my opinion would be the ideal solution). How can we solve this? Should we add a new tool for every mask generation tool?
- Currently, the mask by color operator takes all the color components into consideration. Should it only take the hue into consideration?