2022-1-27 Sculpt/Texture/Paint Module Meeting

Participants: Joe Eager, Julien Kaspar, Daniel Bystedt


  • Earlier meeting schedule?
  • Blog post progress
    • Deliver date?
  • Discussing possible near term targets
    • Sculpt Vertex Colors
    • Topology Rake Curvature
    • Enhance Details Brush
    • Multires Heal Brush
    • Threaded Cloth Brush
    • PBVH Eevee support
    • Boundary Edges in Sculpt Mode
  • Possible medium term topics
    • Eevee sculpting
    • Dyntopo refactor
    • Undo bug fixing
    • Multires improvements


Blog post draft

  • Joe will work on a detailed draft over the next week
  • Collect visual examples if needed

Sculpt colors patch (D12587)

  • A conclusion for moving forward on the technical implementation needs to be reached
  • Does someone have ownership over the C API of attributes.
    Get them involved to help out.

Near term goals

  • Cloth brush
    • Threaded cloth brush is a small planned improvement
    • Another big help would be to create a tutorial/documentation and a demo file with a collection of cloth brushes
      • This would open up the toolset to anyone
    • Daniel has the most experience and would like to help out
    • Other possible improvements are self-intersections and fixing gravity stretching
      • Daniel will collect issues that should be improved in the future
  • Multires Heal Brush
    • Works in sculpt-dev as intended
    • A good workaround until the Multires modifer is made more stable
    • But we agree that a filter/operator would work better since it removes the need of hunting down the spikes origin point
  • Enhance Detail brush
    • More of a bug fix to the current implementation
  • Topology Rake (Dyntopo)
    • Would be good to get a demo of how it can be used
    • Especially useful for smoothing and in combination with future handling of boundary edges
  • Boundary Edges
    • Preserving of the boundary edges of certain attributes (seam, sharp, face set boundary, …) is really easy to understand & showcase
    • Hard Edge Mode needs more demo material on the other hand
    • Should be handled as a separate feature
  • PBVH Eevee support
    • There’s already a patch (D13897)
    • It’s about speed increase for now
    • Dyntopo & multires support for Eevee will come later

Medium Term

  • Multires improvements
    • The goal is to make the base mesh always follow the higher resolution. Make Apply Base obsolete
    • The new behaviour that we’re aiming for would benefit the sculpting workflow and make multires more stable
    • But vector displacement baking would need to be implemented first to not lose the original multires use cases
    • The Apply Base operation is also still a needed feature to preserve the volume when using a subdiv modifier
    • More design discussion needed
  • Eevee support
    • Dyntopo support ready in sculpt-dev branch
    • Mutlires depends on interpolating attributes. Joe could work with Sergey to implement it
    • Undo bugs
      • Most fixed in sculpt-dev
      • Could be put into patches and reviewed

Other topics

  • Shapekeys/Sculpt Layers using tangent space instead of object space is a great goal to keep in mind. This would help with:
    • Posing a sculpt non-destructively
    • Corrective shapekeys on animation
  • Brush management
    • Needs more discussion with asset browser team
    • Should become a high priority soon
    • Needs more discussion on what is absolutely necessary for it to work
  • Talk with geo nodes devs / Dalai on geo nodes workflow.
    • Are they replacing other modifiers?
    • Should we maintain modifiers like data transfer?

Next To Do’s

  • Finish the blog post to communicate our near term goals
  • Sculpt colors discussion. Ask owner of attribute API for help?
  • Cloth sculpting demo & file
    • Includes presets
  • Discuss plan of data transfer modifier support
  • Discuss plan and roadmap for brush asset support
    • Minimum necessary implementation?
    • Long term plan with brush authoring and brush engine refactor
  • Discuss plan for multires and vector displacement baking
    • Gather current design tasks
    • Work on a design that includes all current & planned use cases
  • Continue to gather/ceate more design tasks and documentation for further improvements
    • Once current near term goals are successfully implemented we should have a priority list of the next goals

Next Meeting

February 3rd, 10am CET


I think Sculpt should provide more development resources, the original industry benchmark is capital-tainted node in time to capture the hearts of more users, the requirements are not high at least 20% to start :rofl: :rofl:


feel free to donate enough so they can hire the development resources you think they need :wink:


Blender Studio decides who to hire and what for, regardless of who donated and for which purpose.

1 Like

How can I have enough money to donate when I’m recently unemployed? :sob: :sob: :sob: :sob: :sob:

1 Like

yeah but the budget for that comes from the donations and it’s still limited. Never heard that there is anyone from the developers who is hired and is hanging out in the ball pool because there are enough development ressources.

Don’t feel ashamed. But it’s often the ones not contributing who are the loudest that more people need to be hired.


The meeting notes have now been added.

When it comes to giving more support & resources to the module it’s not really about financial support right now. The main hurdle is to get developers & designers who can contribute.
Because of the active and vocal community we are aware of a lot of issues but working on it takes time and needs to be prioritised.


A hair brush similar to zbrush works well, any ideas?

1 Like

Can this bug get some love before the 3.1 release? This is quite destructive, and not fun for the multires workflow.

Multires Unsubdivide destroys the vertex groups

1 Like

Really exciting goals, especially the brush management.

I am a little concerned about this:

Because, the modifier workflow should NOT be replaced with geo nodes. Both serve different purposes, for different workflows. Modifiers are easier and quicker to work with while modeling and concepting, whereas the procedural geo nodes workflow takes a lot more effor to get going initially, but allows for more flexibility in the end. No modifiers should be scrapped.


As far as I understand it, the goal is to have geonodes under the hood of each modifier. When it is setup this way, you can use the modifier in a stack in the traditional way. If you are a more technical user, you could then open up the node network to make changes to make a custom modifier based on the original. Best of both worlds, and hopefully being able to save out a modifier as a preset.


That’s also my understanding, my comment was just to make sure that that would still be the case here.


That’s probably what will happen. In the mid-term I could see Blender ship with a number of geonode presets each emulating a legacy modifier. Ideally we could still pick them off the list like we do now. Node groups being made into assets will allow them to be part of the default asset bundle, I assume.


That’s a nice way of eating a cake and having it too.

1 Like

You really lost me there

I’m concerned this would break the workflow of sculpting on a basemesh for normal map baking, as in that case you do not want to modify the basemesh. i.e. you want to bake the normal map as the high-res sculpt on top of the original, unmodified, basemesh. This is especially useful when you want to have a shared basemesh and texture-swap between normal maps (which is very common in games). I was under the impression that this, and similar, workflows was why the Apply Base is an explicit step.


That’s a nice way of eating a cake and having it too.

That’s a common saying in english. It means that you are getting more than that is reasonable (in a good way in this case).

Edit: You can't have your cake and eat it - Wikipedia