2022-2-23 Sculpt/Texture/Paint Module Meeting

Meetings
1

Participents: Joe Eagar, Julian Eisel, Daniel Bystedt, Julien Kaspar

Agenda

This week the focus is on the design of the brush assets, management and UI that need to be decided before an implementation can be worked on.
(When the actual implementation will happen is not yet clear)

  • Brush Assets design

    • Preset or Primitive Asset?
    • Standard asset library (Brushes that cannot be deleted)
    • Node or stack based brushes?

  • Brush selection UI

    • Global brush selector (sidebar, toolbar, popup, etc)
    • Limited brush selection (Shortcuts, cycling, pie menus, etc)

  • Brush authoring UI

    • Space to expose all settings, especially after a complex brush refactor (for creating brushes)
    • Exposed few settings per brush for the user (while using the brush)

  • General priority list

  • Sculpt & Paint Modes

More notes:

Notes

We mainly focused on discussing the difference & the implications of using preset or primitive assets for brushes in the future.

  • Downsides of ā€œPresetā€ assets would be too high

    • Having the brush settings reset when switching is not acceptable

  • How would we use ā€œPrimitiveā€ Assets

    • Should automatic brush resetting/loading from the asset library be opt in or out? Opt-out workflow could be as follows:
    • When selecting brushes via Asset Browser or brush selector UI it will append (Reuse Data) the asset
    • No representation of brush data blocks in brush selector. Only show brush asset library.
    • Any appended brush data blocks have no fake user (Shield Icon)
    • Allow marking brushes with a shield to keep changes locally. Otherwise it will pull asset after reload
    • Brushes that have their settings changed could be highlighted as such (Reminder to save brush settings to asset library or create a new brush)
    • Avoid requiring the user to reload brushes manually. Workflow should be automatic & intuitive
    • Brush asset pushing is absolutely required by default

  • Asset libraries or catalogues?

    • User brush assets will mostly stay in a single default asset library
    • Dynamic catalogues will be important for brush organisation

  • Default Brush Library

    • Blender needs to ship with potentially hundreds of default brushes
    • Donā€™t allow users to change/delete them (There must always be a way to restore the default brushes)
    • Users have to duplicate them to make changes
    • Open questions:
      • Where should the default brush library be stored? Should it be in the default user library?
      • Should catalogues mainly be used to organise custom brushes? (Also to avoid naming & shortcut conflicts)
      • Or should the user library be separated from the default brush library? (Allow full customization of brush asset library and pulling from default library to restore default brushes)

  • Brush selector UI

    • Eventually Toolbar merges all brushes into one tool
    • Brush selector UI will be based on the pose library addon in the sidebar
      • This would leave little space in the sidebar for addons ā†’ Users would need to switch sidebar tabs to access either addons or brushes (Thatā€™s not ideal)
        • Capping the height of the brush selector is not an option
        • Long term workaround would be to redesign the right click menu, or even dock the brush selector in a redesigned toolbar
      • As a result Brush settings would also be mainly accessed via header tool settings
    • Brushes can also be used via asset browser editor but the main use here would be brush organisation
    • Right click brush selector?
      • This UI would need to show a selection of brushes, tool settings and operators (Very different from other right click menus)
      • An essential UI element for full-screen workflow
      • A pie menu might be restricted to current design. 8 brushes are not enough
      • We do not want to change the current pie menu design. We need a new UI for this menu
      • A big complex UI can also be embraced as an addon

  • Brush authoring space in properties edior

    • With Joe Eagarā€™s design the new brush settings would be too much for the current UI to handle
    • Ideally the sidebar & header will then only show a selected few brush settings that are changed regularly by the user
    • ALL potential brush settings could be shown in a separate tab in the properties editor
    • This space is for brush authoring with full control of the brush behaviour
    • Settings can also be ā€œmarkedā€ to be exposed to the user (Comparable to exposed sockets in node groups and geo nodes modifiers)
    • The exact design of this UI and if it could be similar to the current, a node editor or stack based like modifiers is out of scope for now
    • Until we have a proper design with mockups, any added brush settings would not be exposed (Unless the current UI can handle them)

  • MVP & priority list for brush assets

    1. Mandatory functionality (As experimental feature)
      • Enabled brush asset support
      • Selection and pulling from asset browser
      • Minimum functionality for asset pushing & keeping brush changes local
    2. Secondary functionality (Important for first release)
      • Brush selector UI in sidebar (As a global brush library)
      • Standard Asset Library Design (How brushes are stored and edited if they are read-only?)
      • Standard Brush Library (Up to hundreds of default presets shipped with Blender)
      • Toolbar cleanup (Merge all brush tools into one)
    3. Long term improvements & nice-to-haveā€™s
      • Dynamic catalogues
      • Right click menu (New design to support brush selection & more)
      • Brush engine refactor
      • Brush authoring space (Properties editor or even a node editor)
      • Customizable brush settings in header/sidebar

  • Moving forward:

    • Julien will be responsible for collecting and writing up a design task based on this discussion, existing design tasks and online proposals.
    • There is no timeline yet on when the project would start development.
    • The focus is on defining a design that future development can start with

At the end we focused for a moment on a left-over question for the texture painting project:
How should the painting/sculpting modes be structured in future releases?

  • Internally unified code
    • The goal would be to internally de-duplicate the code of brushes & tools between modes
    • Painting & sculpt modes would all run with the same PBVH drawing
  • Mode structure
    • Theoretically sculpting, vertex painting and texture painting could be merged into a single mode
    • Mode separation/unification can be still flexible as a result. We could merge them or keep them divided as they are
    • This decision heavily depends on the implications to the clarity/cluttering of the UI and the keymap
    • We didnā€™t yet come to a conclusion
9 Likes
2

What is the ā€œnode or stackā€ based brushes?

3

After the brush refactor that Joe is planning there would be too many settings to realistically show in the current UI. So the idea was to either implement a node based UI to change the complex brush settings or a linear UI similar to a modifier stack.

5 Likes
4

I hope that the decision will be the one that gives the user the most possibilities. I love the per node thing. But on the other hand, if it doesnā€™t add anything compared to a linear configuration, it doesnā€™t make sense. That is to say, if it is simply to go concatenating nodes linearly anyway (it would be good to see what is proposed) at the end it is not different to have a lot of panels with a check to activate options as Z does.

5

Agreed. I love nodes, but am not sure what they would bring for brushes. Sure you could connect stroke speed to strength, or pen pressure to tilt, but is there real added value in it ?

6

The benefit I personally see in node based brush editor is that you can change a lot of basic brush settings for certain brush set - all at once.

For example you have setup like this:

brush size node` -> `brush type node` -> (to output)
                 -> `brush type node` -> (to output)
                 -> `brush type node` -> (to output)

You can change brush size for 3 brushes in a set at once.
At least thatā€™s how I imagine it could work.

7

Iā€™m not an expert so itā€™s a bit harder to visualize, but nodes vs linear i would assume that anything nodeā€™s related is more time consuming to set up.

My personal criteria for any system would be accessibility / readability / intuitiveness, so whichever system does it best is the one iā€™d go for. At least in theory, in practice it might be a bit different :sweat_smile:

8

We could imagine a simplification of brush UI.

Instead of having curve widget about brush pressure for every setting, we could have a simplified panel that just show one for pertinent setting for specific brush.

Node Editor could be seen as a way to edit a custom brush in depth ; while only settings, frequently tweaked, would be visible in UI.
The same way as we can make a very complicated nodetree with GN and only display few settings in modifierā€™s UI.

9

The meeting notes are now updated :+1:

2 Likes
10

I donā€™t think we came to an agreement there. To me dropping the user data on save/reload is a big anti-pattern that we should move away from. So IMO appended brushes should have a fake user by default that users can opt-out of. You shouldnā€™t have to (know to) opt-in for keeping changes. Of course this needs to be looked at from a sculpt/paint workflow point of view, but not solely that.

Would be good to investigate how other apps handle this. In the meeting we noticed Krita keeps the changed brushes on reload by default, it seems.

Think this is a bit unclear, especially with the term ā€œmanuallyā€. I guess this is about the brush resetting? (Pressing Reset Brush is also a manual action of course :slight_smile: ). If so, Iā€™d just note that operators to reset the brush(es) should be available (e.g. right-click ā†’ Reset Brush), thatā€™s more clear.

Itā€™s not that itā€™s not an option, technically itā€™s possible of course, just not easy to do, and not a common UI pattern in Blender. So Iā€™d rather have solutions without it tested & evaluated first, and only do this if we decide itā€™s actually the way forward.

Since we try to make clear that the Asset Browser is really a browser, and not a manager, Iā€™d prefer not to use the term ā€œmanagementā€ at all in this context. Users may put brushes into a custom asset library and self-manage them without the asset pushing add-on (e.g. to prepare a brush pack for publishing). Also, I expect there will be a right-click ā†’ Save Brush to Library or similar available in the sidebar, so this UI also provides some management features. So Iā€™d say the Asset Browser is used for brush organization instead - e.g. creating catalogs, moving brushes to catalogs, viewing/changing metadata, etc.

1 Like
11

One thing that needs discussion still is what edits to the standard library we allow, and how to do it. E.g. can you edit the catalogs and change which catalog an asset is in? Can you edit/add tags? Can you rename them? ā€¦
The same can be asked for custom brushes stored in the global brush ā€œpaletteā€, or in fact any brush accessed in the asset browser (that is not stored in the current file).

12

Thanks! I adjusted a couple things in the notes.

We could try capping the height for a brush selector. During the meeting it was just mentioned that this was already attempted for the pose library and it didnā€™t work well.
The only place where it is common is the list UI in the properties editor (vertex groups, material slots, etc). If a design like that works in the sidebar then that would help.

Think this is a bit unclear, especially with the term ā€œmanuallyā€.

What I mean with that is that the current workflow in Blender is to append brushes from another file if you want your most current brushes. Itā€™s a very manual process.
If brush assets need to be reset regularly with menu operators then I see that also as a very manual process. I suggested to move further away from that workflow and have brushes by default reset to what is in the asset library (Unless marked with a fake user, shield icon).

I agree that Blender should move away from the current fake user save/reload logic. That logic is counter intuitive and very much against norms in other 3D software. But in the case of brush assets it would probably be better to not keep outdated and duplicated data blocks around that need to be manually deleted or updated, and instead have everything intuitively loaded from the asset browser.

One thing that needs discussion still is what edits to the standard library we allow

Yes we didnā€™t discuss this properly in the meeting. Maybe it could be for the best if the standard asset library that is shipped with Blender is a separate asset library that is read only. If the user wants to use edit any of these assets or use them in their own user library theyā€™d need to save them to their user library. Anything outside the standard asset library could be free to edit.

13

Anyway, the takeaway from this is that the Standard Asset Library is left a bit unclear. We need to further discuss how and where it is stored, and how users interact and change those assets.
Another good thing to note is that the Standard Asset Library would not just be brushes. It would also encompass base meshes, node groups, materials, modifier node groups, textures and more, to provide an out of the box experience of using Blender.

Iā€™ll add it to the notes to be clear.

15

I really like step-by-step approach to the project.
MVPā€™s will allow users to gradually learn new tools and workflows without much disturbance.

As for sculpting/painting modes, I can see why this might be problematic.

  1. Some people will just want to sculpt.
  2. Some will just want to paint.
  3. Some will want to do both at the same time.

Maybe instead dividing sculpt and paint into separate modes this could be solved by hiding respective tool sets inside one mode? AKA - ā€˜hide sculpt toolsā€™ and ā€˜hide paint toolsā€™ buttons.
The mode could be just one just as it is now.

OTOH this might violate some design principles.

2 Likes
16

Itā€™s more of a thought experiment at this point: Do we still need paint modes? Why canā€™t you just select different brushes instead of sculpt/paint modes? Selecting a paint brush lets you paint, selecting a sculpt brush lets you sculpt. The brushes would be in separate catalogs by default, so youā€™d still make your choice explicitly.

Of course there are many issues, mostly in the UI design with that idea still. Itā€™s just something interesting to ponder about for the longer term. Technically the modes should become mostly unified anyway.

8 Likes
17

As for why the modes exist, my understand is because of two main reasons :

  1. making sure the data exists in a state thatā€™s usable with the tools in question (PBVH for sculpting, bmesh for edit mode, etc)
  2. dedicate the interface and the hotkeys to a certain workflow

Am I missing something ?

18

Agree completely on the first paragraph.

I was concerned by the amount of tools required by both sculpting and painting and how they will fit together in the UI. But if the design will be logical and clear I donā€™t mind it at all.