Sculpt Branch Status Report

This blog post is about the new main features that were added to the sculpt-mode-features branch in the last 3 months, as well as my opinion on how to merge these features into master.

New Features

Brush cursor, normal radius and curve presets

The patch of the sculpt cursor which follows the surface has been around for a while (D3594). It can work either by sampling the real normal of the sculpting operation or by using the normal of a single face. The normal sampling code is disabled when a sculpt stroke is active, so it should not affect performance. The cursor is also responsible for updating and displaying the active vertex (more on that later) across all the enabled symmetry axis in real time, with radial symmetry and tiling support.

The normal radius property limits the radius of the sampling sphere that is used to calculate the normal and the area center. It affects how closely the brush will follow the surface of the sculpt, but in some other brushes it produces some desirable effects. By tweaking this value, you can use the scrape brush to sculpt hard surface, which was not possible before.

I also added another brush which always applies the deformation on top of the original coordinates, useful for making insertions or creases in a much easier way. On top of that, you can now use the same curve presets that were used in edit mode proportional editing for the brush falloff. These curves produce a more pleasing deformation than the defaults that are shipped with the brush falloff editor right now. This also fixes the deformation issue with the grab brush when using the current default curve preset.

Voxel remesher

The voxel remesher uses an OpenVDB level set to generate a new manifold mesh from the current geometry (it does not actually use voxels, but I thought that this concept is easier to understand as it is related to volume). The operator can be executed from both sculpt mode and object mode, and it is fast enough that it also was added to the remesh modifier, including OpenVDB filters and volume based CSG operations (done by Martin Felke).

This OpenVDB operation is ideal for sculpting. It produces a mesh with perfectly even distributed topology and it does not have any performance penalty once the new mesh is calculated. Thanks to this new workflow it should now be possible to sculpt at a much higher level of detail than it was possible before with dyntopo, even if the resulting mesh has more vertices. It also supports vertex color and paint mask reprojection, so it is possible to keep the colors of the model while blocking its shapes. Besides sculpting, this new OpenVDB mesh operations can also be used for 3D printing and simulations.

With the new concept of a static remesher in Blender is now easy to add other external libraries for different use cases, like Quadriflow for automatic retopology.

Sculpt vertex colors

This new type of color data is stored in the model the same way the sculpt mask is. By doing this, I was able to reuse all the optimizations and features from sculpt mode. This brings a huge performance improvement to vertex paint, the ability to sculpt and paint at the same time and more maintainable code. The undo code was also tweaked to support color data and color + deformation data and I ported some tools from vertex paint to this system, like the color picker and the paint brush. In the future, the code from vertex paint could be replaced internally with this system without any changes in the UI.

The only problem with this new approach is that the new vertex paint data is stored on the vertices and the old one was stored on the face corners. The old system allows to have a different color per face, and the new system does not (unless you duplicate the vertex). This data incompatibility may result in data loss for some users working with low poly models. In order to avoid that, the sculpt branch has the two systems in place and I added two operators to convert the color data between them. For this reason, the new vertex colors are not connected to the renderers, so you can’t use them in real time from EEVEE/lookdev, neither previewing them in workbench without copy the layer first to a regular vertex color layer.

Mesh, mask and colors filters

The purpose of these tools is to apply an operation to all the vertices of the mesh as the same time, taking the mask into account. Internally, they are quite similar to brushes (some of the code is shared, like smoothing). Having these tools can save you a lot of time, and they are crucial for certain workflows.

Mesh and color filters discard totally masked PBVH nodes before starting, so they are quite fast when working with high poly meshes when they are partially masked. This approach does not make sense for the mask filter, so it is considerably slower. In general, updating all the nodes of the PBVH constantly for real time tweaking is not a fast operation, so these tools may become a lot faster in the future.

Transform tool

Internally, the transform tool is just a mesh filter controlled by the transform code and gizmo. The SculptSession now has a pivot point with position, rotation and scale. This point is transformed by the standard Blender transform code and all vertices of the sculpt are updated accordingly in parallel, using the same code as the mesh filter. This approach has some limitations (individual snapping from every vertex, for example), but it allows you to work with meshes that are impossible to handle in edit mode. On top of that, some new symmetry code was added to calculate the vertex transformations accordingly.

In order to position the pivot I added an operator which includes several options (pivot to center, to unmasked area, to active vertex…) and which also takes symmetry into account. I would like to add an option to transform the pivot only without affecting the sculpt, but without seeing the gizmos when a transform operation is active it would not be that useful (this is a planned feature, so it should be supported in the future).

I also added the mask expand operator, which was specifically designed to be used with the rotate tool to create a pose tool. It expands a mask from the active vertex as you drag the cursor, following the topology of the model. After the operation is done, the pivot is updated automatically to the corresponding rotation center. This tool is quite fast, all the iterations are cached as soon as you invoke the operator, so it just needs to check which vertices are masked for a certain iteration when updating the preview.

Automasking and mask generators

The original idea was to have a system which enables the user to stack multiple masking operators. For example, you should be able to affect only connected vertices, which are not part of an open edge and with 50% influence to cavities. Right now this system has the topological and the open edge masking implemented, but the UI is not ready and you can only enable them separately with a checkbox. Despite that, you can already use the grab brush with topological masking, which was a highly requested feature.

I also added several operators to generate masks automatically. Mask by color generates a mask based of the color of the active vertex. Mask by normal generates a mask limited by the angle between the normal of two connected vertices. This is useful for selecting “faces” on hard surface sculpts. I still need to find a way to solve the big UI problems these two operators have. They only can be invoked from the keymap, as they need the cursor to be visible and to be over the sculpt. Also, you can’t adjust the threshold of the masking operation from the undo panel, so you need to change the values for the operator from the keymap before running it.

Other features

• Option to control the mask opacity (already in master).
• Option for the lasso mask tool to ignore back facing vertices.
• 2D viewport navigation, which helps to keep the working area under control when working with brushes, as well as giving a more predictable zoom speed when using a pen tablet.
• The distance that is used to generate new brush steps can now be measured both in screen space and in world space.
• Relax brush tool, which distributes the topology automatically without affecting the volume of the model.

Merging the branch

If you have tried the sculpt-mode-features branch, you may have noticed a quite obvious bug: almost none of the new features work with the multires modifier or with dyntopo enabled. They may be disabled, or they may crash Blender.

Internally, sculpt mode has 3 different modes, FACES (when you are sculpting on a mesh), GRIDS (when sculpting on any of the levels of the multires modifiers) and BMESH (when dyntopo is enabled, it does not matter if it is modifying the topology dynamically or not). The interface hides this complexity, but when you change between dyntopo, multires or meshes, you are using a totally different data structure, undo stack and rendering code. You can think of it as supporting 3 totally different sculpt modes at the same time. This is why some bugs are specific to a mode and why they have noticeable performance differences.

Most of the brushes are implemented using a pbvh_vertex_iter helper which acts as an abstraction layer for the 3 systems. This works for most of the brushes, but for example, the smooth brush (which needs topology information from the mesh) needs 3 different implementations in order to work with the 3 modes (you can check the smooth() function of sculpt.c).

All the new features of the sculpt-mode branch rely heavily on topology information and a static mesh data structure, like the smooth brush, but they are way more complex. Supporting dyntopo and multires is not about laziness or feature polishing, it is about avoiding an insane code triplication all over sculpt mode.

That said, here are some options to merge the branch into master:

Merge the branch as it is now, without dyntopo and multires support

This may be doable for 2.81 – 2.82, but it will lead to the deprecation of dyntopo and multires sculpting. All the new features will be disabled from the interface when those modes are enabled, so they will start falling way behind in terms of functionality. Sure, we can support those modes triplicating the code for all the tools and operators, but it is not a problem about how much work could it take, it is about code maintenance. There is already plenty of bugs in the tracker specifically related to dyntopo and multires sculpting with the current code and continuing the development this way would make the problem even worse. In my opinion, doing this is an irresponsible decision.

Make an abstraction layer for the current modes to support the new tools

This is how most of the brushes work right now. The pbvh_vertex_iter functions let you modify the vertex coordinates of a mesh with the same code, no matter if the PBVH type is GRIDS, FACES or BMESH. We could try to add more functions to expose topological information and a ‘fake’ static geometry in order to make the new tools work. This could potentially have a performance impact and it will add some new hacks to the sculpting code. Also, I don’t know if this is really possible with the current code design or if all new tools can be supported in all modes after doing this.

Make a new data structure from scratch designed for sculpt mode

Now we have a working Blender version with most of the features that a modern digital sculpting application should have. This information should help us to make a new design for the internals of sculpt mode, without all the code duplication and hacks that Blender has now. All the new tools would be supported, and hopefully, with much better performance. This project should also try to fix bigger issues Blender sculpting has, like multires detail propagation, waiting times when switching modes, dyntopo performance and geometry errors.

This is not an easy task, and it will probably take several versions to get this ready for master before any of the tools can be ported. You can think of this process like going from the pbr-viewport branch to the draw manager and EEVEE. In the meantime, the current sculpt-mode-features branch could be supported as well, as some tools it has are crucial for some people’s workflow.

There are some features in the branch which don’t depend on the internal sculpt modes and data structure. Those features can be merged at any time, as soon as they are reviewed. This includes:

• Sculpt cursor and normal radius (the cursor needs some code duplication to make it work, but that was already done)
• Brush curve presets
• OpenVDB voxel remesher/Quadriflow (it may have some issues with the current undo system)
• 2D viewport navigation
• A slower version of the transform tool (needs to be redone

This project was never about adding fancy features to Blender for the sake of adding features. In my opinion, this is the most basic functionality any sculpting software should have. I started coding these tools because I needed them to make my portfolio, so my priority was having everything working as soon as possible. The main blocking issue for merging this is not the number of features that were added (they are actually not that complex), is that Blender sculpt mode code was not designed to support this properly. Making a new design or bigger changes was way beyond my skills when I started the project, so the options were doing everything on top of the current design or keep waiting until someone changes it while making feature requests. I don’t know how long would it take to make a plan to merge everything into master, but I know that the workflow of a lot of artists already depends on this branch. I will try to keep supporting this branch until merge happens, updating it to master and adding the few remaining features I had initially planned.

Pablo