As part of my Blender development fund work, I’m working to bring sculpt masking (a feature from the 2010 Google Summer of Code) into trunk.
Here is a patch against current trunk for testing: masking-01.diff. There’s also a tarball of the git patches if you’d prefer something more fine-grained. Note that this patch sits on top of the partial-visibility code, so you’ll find both features available after building with these patches. If you make a test build, please consider uploading it to Graphicall and post a link in the comments.
You’ll find in-progress documentation on masking in the wiki. Although these patches are not quite finished yet, they are ready for testing. I’d appreciate feedback on the masking tools. In particular, how’s the UI? And of course any notes on crashes and other bugs would be good to have as well.
Back in the ancient days of Blender 2.4x, sculpt had a feature called partial visibility. You could hide areas of the mesh via border selection. This feature went away during the 2.5 rewrite, which was probably a good thing. The old code was nasty, touching too many parts of the code and resulting in a lot of file corruption bugs. My bad.
I rewrote the partial visibility tool during the 2010 Google Summer of Code as a much “safer” tool that mainly affects the PBVH (the acceleration structure used by sculpt mode for drawing and querying the mesh.) This code never quite made it to Blender trunk, but I’ve been working on a freshening that code up and getting it ready for a proper release as one part of the work I’m being sponsored to do by the Blender development fund.
The code has been cleaned up in various ways, and from the user perspective you’ll notice that multires hiding now works as you’d expect, rather than the very “blocky” look it had in the GSoC branch.
With BMesh coming soon to trunk (possibly as soon as 2.63) I’ve rebased my patches against that. Here’s a single diff containing the entire changeset: partial-visibility-20120210-00.diff (again, this is against the bmesh branch, not trunk!)
I’ve noticed that people are often unsure why you’d ever want to use the Sharp mode of the Remesh modifier, rather than Smooth mode.* One simple example is 3D text. Converting 3D text to a mesh will tend to give you lots of skinny triangles; if you want to sculpt or animate the text, a more regular tessellation could be quite helpful. Sharp mode then gives excellent results. The edges of the text are pretty much perfectly preserved, and now you can go add fun things like a Cloth modifier and watch it deform much more smoothly.
Meshes created with the Boolean modifier are another good candidate for use of sharp mode, as can be seen in this old demo video: http://vimeo.com/21330126
* People do correctly understand that the Block mode is mostly a gimmick.
CCGSubsurf, the code behind the subsurf modifier, stores “grids” of subdivided data, one grid for each corner of a face. Each element of the grid contains a coordinate stored as three floats. It can also calculate normals, adding another three floats to each element.
When a mesh has UV layers, the subsurf modifier can (optionally) subdivide UV coordinates. This is done as a separate calculation from subdivision of the mesh’s face/edge data, because the connectivity of faces might look different from the UV perspective (think seams.) Because of this difference, a whole new CCGSubsurf object is created, calculated, and destroyed for each UV layer.
The change introduced in this commit is to simply disable normals calculation when it’s not needed (as in the case of UV layers.) So subdivision should runs a little bit faster and uses a little bit less memory (only during subdivision itself though; the output will use the same amount of memory, so the “Mem” number in the header will look the same.)