Page MenuHome

Sculpt Facemap
Needs ReviewPublic

Authored by Pablo Dobarro (pablodp606) on Oct 15 2019, 4:55 PM.
Tokens
"Love" token, awarded by RyanJEC."Love" token, awarded by amonpaike."Love" token, awarded by monio."Love" token, awarded by michaelknubben."Love" token, awarded by andruxa696."Love" token, awarded by Dusty_Shoe."Love" token, awarded by julperado."Love" token, awarded by Brandon777."Like" token, awarded by knightknight."Love" token, awarded by MetinSeven."Love" token, awarded by iWaraxe."Love" token, awarded by tiagoffcruz."Love" token, awarded by erickblender."Love" token, awarded by TheFlow."Like" token, awarded by Alrob."Yellow Medal" token, awarded by Zino."Mountain of Wealth" token, awarded by TheRedWaxPolice."Love" token, awarded by xrg."100" token, awarded by Frozen_Death_Knight.

Details

Summary

[Work in progress, prototype]

This is a new system to manage sculpt mode visibility. You can create groups of faces dynamically and hide/show them directly while sculpting without using masking tools or box selections.

The sculpt facemap is also used in other sculpting features like the automasking system and mesh filters. It can also be preserved when remeshing the sculpt with the voxel remesher.
The sculpt facemap is stored in the polys instead of in the vertices. This way we can subidivide it with multires in a predictable way.

This patch includes all basic features:

  • Sculpt Facemap data structures
  • Undo support
  • Remesher reprojection support
  • Automasking and Mesh filter support
  • Sculpt Mode Facemap API
  • Sculpt Facemap creation and visibility operators
  • New keymap

Know Issues:

  • We can change the name of this feature to avoid confusion with the mesh facemaps for rigging. If in the future we are going to use Vertex groups, Edges groups and Face groups we can keep this name for this feature.
  • The facemap colors are drawn by the PBVH. We need to add something to change the visibility of the facemap and mix it with the new sculpt vertex colors. I'm not sure if we can use an overlay for this without affecting sculpt mode performance, but that would be the ideal solution. It also misses smooth shading support and opacity controls.
  • It needs multires support. When using dyntopo, the sculpt facemap should be disabled.
  • It gives an error related to the new datalayer.
  • I think we should store mesh visibility in sculpt mode in polys instead of in vertices. This should be an easy change. Right now I'm using both and it is starting to become a mess. Some facemap tools have bugs related to keeping in sync facemap visibility and vertex visibility.
  • Colors are generated using a random seed that is generated each time the PBVH is built. This way we always get different colors, but colors will also change when entering sculpt mode. Is there something else I can use a seed? Maybe store it in the mesh datablock?

Diff Detail

Repository
rB Blender
Branch
sculpt-facemap (branched from master)
Build Status
Buildable 5390
Build 5390: arc lint + arc unit

Event Timeline

Yes! Polygroups in Blender Sculpt Mode, this is fantastic, @Pablo Dobarro (pablodp606) ! 👍👍

Will you also add tools to manipulate the polygroups? Such as:

  • Polish By Groups to smooth all polygroup edges
  • Mask only the borders of one or all polygroups
  • Make the Extract tool also work with polygroups (selected or all)
  • Extrude tool for polygroups (so you don't have to convert it to a face selection and go to Edit Mode)
  • Tools to slice custom polygroups into a mesh
  • Options to grow or shrink polygroups

Apologies for posting this here. I know this is not the place for feature suggestions, but I couldn't suppress my enthusiasm. 🙂

What is the reason to declare a new face-map custom-data type?

Can't the existing face-maps be used here?

@Campbell Barton (campbellbarton) (copy from the email)
I don't think we can use the rigging facemaps for this. (I already tried that).
The sculpt facemap datalayer is just an int per poly. The sign bit stores the visibility and the number the facemap ID. This way we can render them in different colors in a predictable way just by hashing the ID. We already have a vertex -> poly map in memory during sculpting that is used by most of the tools, so integrating this feature with the current tools is super easy and it won't have any performance penalty. Also, performance is not going to be affected by the number of facemaps we are using in the sculpt. This feature does not need more UI/UX that what is already in the patch to be useful (just the additional overlay opacity control).
I don't think this data has more uses outside sculpt/paint modes to define visibility areas. I think we should keep it this way instead of trying to use a more complex already existing data structure

@Campbell Barton (campbellbarton) (copy from the email)
I don't think we can use the rigging facemaps for this. (I already tried that).
The sculpt facemap datalayer is just an int per poly. The sign bit stores the visibility and the number the facemap ID. This way we can render them in different colors in a predictable way just by hashing the ID. We already have a vertex -> poly map in memory during sculpting that is used by most of the tools, so integrating this feature with the current tools is super easy and it won't have any performance penalty. Also, performance is not going to be affected by the number of facemaps we are using in the sculpt. This feature does not need more UI/UX that what is already in the patch to be useful (just the additional overlay opacity control).
I don't think this data has more uses outside sculpt/paint modes to define visibility areas. I think we should keep it this way instead of trying to use a more complex already existing data structure

You mention vertex, edge and face-groups in your first post, is there a chance these will make it in? It'd be a lot more consistent than the current system, and it opens up new uses
(like bevel weight groups that you can edit in the edge group list, and Face groups being used for masking modifiers (where vertex groups are often unusable because the vertices might share faces)

Jacques Lucke (JacquesLucke) added inline comments.
source/blender/blenkernel/intern/pbvh.c
568

Using a random number generator seems a bit overkill here. Maybe use BLI_hash_int instead? Or use the output from PIL_check_seconds_timer_i directly. It does not have to be very random, since it is only a seed, right?

source/blender/editors/sculpt_paint/sculpt_intern.h
146

Should this be int instead of short?

Pablo Dobarro (pablodp606) marked 2 inline comments as done.
  • Face Map Paint tool
  • Face Maps are now an overlay with opacity control
  • EEVEE support
  • Vertex and Face map visibility should now be in sync
  • Move the random seed to the mesh
  • Face maps are now int and store their visibility

Will this work in edit mode?