2023-02-14 Sculpt/Texture/Paint Module Meeting

Meetings
1

Practical Info

This is a weekly video chat meeting for planning and discussion of development related to the sculpting and painting in Blender. Any contributor (developer, UI/UX designer, writer, …) working on these features in Blender is welcome to join and add proposed items to the agenda.
Write us a message in the module chat if you’re interested.

For users and other interested parties, we ask to read the meeting notes instead so that the meeting can remain focused.

Attendees

  • Julien Kaspar
  • Daniel Bystedt

Agenda

VDM Brush Demo

Daniel Bystedt is working on a demo file and is polishing the brushes.
This file will also include a baking setup and instructions on how to use/create brushes.

Julien will record release notes material and a feature showcase video later on based on it once it’s done. This is to showcase the feature and go more into depth on how to make use of it.

VDM next steps

There are possibilities to work on this feature further.
Robin is working on Bake from Multires support for vector displacement but this needs further testing to resolve baking accuracy issues.

Brush Thumbnail Redesign

WIP brush thumbnail design proposal.

Important next steps for Julien:

  • Add more missing thumbnails for better overview
  • Make each thumbnail more distinct and iconic (Colored lines help a lot for this)
  • Recolor them to match with object/edit mode and curve sculpt mode color pallete
  • Work on corner icons and what they must communicate (Stroke method or brush type?)

Daniel: Lines tend to get lost. They need more contrast.
Either darken Matcaps or adjust stroke color.
Needs some testing.

Brush Asset Essentials

We’ll gather a .blend file and a document.
Especially important for cloth brushes.

Planning for Paint Mode

Task: #96225 - PBVH image texture painting implementation - blender - Blender Projects

Right now the planning for 2023 won’t focus much time of core devs here.
What are the most important aspects of the task to wrap up for a first usable implementation?

Daniel: Hiding geometry is far more frequent to him than just masking. But both should have highest priority.
If a blur/smear brush implementation is too complex, perhaps a blur operator is more achievable in the short term?
Although this will have issues with vertex masking.

Otherwise it might be good to look into an implementation of Wet mixing in the paint brush as a first step.

Create VDM brush from existing sculpts

Quick test:

Daniel will check it out later and give his take.
There will be more experiments to find a usable workflow for creating VDM maps.
Eventually this can then be backed by further development to automate or speed up certain steps.

Base Mesh Creation via Gesture Tools

Daniel continued to create a research document on workflows and design.
The idea is to improve the Trim tools for base mesh creation within sculpt mode.

There was also the suggestion to implement these as Add Object tools in object mode, but this make them less intuitive for fast mesh creation.
The dev time and cost should also be kept low and ideally aligned with other development projects.

We want to talk to the geometry nodes team if this use case can be combined with the idea of geometry nodes brushes.
This could be a good first test case to use geometry nodes for base mesh creation from strokes within sculpt mode.

Base Mesh Asset Pack

Link: Asset Bundle - Base Meshes

Shipping base meshes is a great idea. for multiple workflows.
A full body human would be good. But he’ll think about it. Not quite sure.

Daniel can take a look at the male realistic human for feedback. But the VDM demo file has priority.

Daniel suggested that very light weight base meshes could also be made with the skin modifier.
Another idea would be to create a replacement for the skin modifier as a geo node group and ship that as an essential asset.

For the possibility to have versatile base meshes, the best way could be to wait for features to add parameters for a base mesh primitive (Style, resolution, gender, etc)

Updated Matcaps with specular layer #104285

Clement added MatCap Improvement #104640 with additional proposals to improve the Matcaps.

  • Should we make all matcaps color neutral?
  • Is supporting metalic and roughness sliders useful/desired?
  • Automatic conversion?
  • Light extracttion for shadows?

Daniel: Matcaps give a quick new look at model. Fixed colors in the matcap help with that.
Metalness and roughness seem counter intuitive for matcaps.
Light extraction for shadows is not that important either.

Overall the suggested improvements down’t seem like a wise time investment.

17 Likes
2

Clément’s proposal about matcaps is following logic, that the more a matcap has layers, the less a user has to create several matcaps for specific uses.
A matcap with 4 layers should replace need of 4 matcaps without layers.
Main Light Extraction goal is to be more pertinent than current Flip option.
It would be if the goal is a Workbench animation.

That being said, I think that an automatic conversion is not needed, unless there is a technical problem with supporting matcaps without layers.

Color neutrality depends on the goal of the matcap.
If the goal of the matcap is to correspond to metal-ness, roughness, specular reflection intensities,values or to a lighting, it should be color neutral.
If the goal of the matcap is to mimic a specific matter that has a specific color (gold, chrome, bronze, copper, jade, ruby…) it should be colored.
But if this specific matter can have any color (carpaint, clay, ceramic, resin, plastic…), it should be neutral.

If the goal is to allow cool Workbench rendered animations, that does not seem like a waste of time, at condition, that matcap can be per material instead of per scene.
So, there are probably other priorities for users like :

  • ability to have Viewport Display Color of material, automatically, copying Diffuse color.
  • ability to copy/paste all Viewport Display Settings as one from one material to another.
  • ability to have a matcap as a Viewport Display Setting of material.

Changing the way Viewport Display settings are exposed in UI as a shading node output could have a lot of benefits.
An RGB input could be connected to Diffuse Color of Principled shader and Viewport Display color.
Such node could be copy/paste easily from one material to another.
And if ability to a matcap per material is achieved, simply, connecting a matcap node to it would be satisfying.

2 Likes
3

I have not seen yet the brush creation video, but I want to add that VDM is a magnificent option to bake multirrs detail to texture, much more precise option than a simple height map.

Baking the normal from multires could be enough? Or a similar option with the required differences maybe.

2 Likes
4

@RonanDucluzeau Thanks for the input! I fully agree with our points on color.
When it comes to making Matcaps more flexible and defining them per material, I think that is making their use far too complex.
Maybe the best way forward is to improve and empower the Studio lighting for that purpose instead.

1 Like
5

How is it complex? :thinking:
Matcaps are basicaly a type of material, so it’s expected to be available per object too…
The “viewport display” section in the material would be a nice place to have it…

6

The big advantage of Matcaps over Studio lighting is that it’s basically a one click solution to changing the entire viewport visualization.
You get a fresh look of all models with a new color, lighting direction & material behavior all at once.
If a Matcap can be set per object, then this might get too complex. But if it’s really needed then it can be done.

IMO I don’t believe it’s a good idea to over-complicate this core concept in order to make the Matcaps more like the Studio lighting.
It’s also easily very jarring to have a completely different lighting and material behavior on different objects.

What are the main reasons to set a matcap per material other than trying to replicate a final looking material style for each mesh in the scene?

2 Likes
7

This is also my opinion, matcaps are a one-click solution. If the user wants to control highlights and different light sources independently then I believe they should use studio lights, given they’re made exactly for this purpose.
On the other hand studio lights lack some flexibility that matcaps have, in the sense that they don’t allow creating as much complexity in the light response compared to them : anisotropy, subtle translucency effects…

2 Likes
8

I mean - it depends on what you want to achieve with the Matcap. As a quick viewport aproximation with different benefits like cavity or clay previews? Sure. As simple as posible. One click in the viewport setings - done.

But I would have wished for a celshading shader in the regular node editor or as an option in the Workbench for Rendering out super fast iterations for pixel art. Think of the workflow for “Dead Cells” here.

I used Matcaps with quick CelShading Setups in Pixel Art renderings for example. Rendering on a super low resolution Matcaps can be a very nice way of adding not only very high contrast lighting but also very predictable outlines in a very, very fast to use material setup.

I agree that as a quick overall viewport shading method per material matcaps could be overkill. But as a separate shading option in Workbench this can be very powerful and much faster to set up.

So for a viewport setup - sure. No need to overcomplicate things.
But it would be really good to have them as a separate shader option that doesn’t need much setup.

9

Artistic freedom?
I mean, this is how matcaps are used in other 3d applications… each object can have it’s own matcap for the obvious reasons…
For instance, when vertex painting an eye, you would probably want the eyeball to have a shiny matcap while the rest of the model uses different matcaps… it’s nicer to work this way…
Sometimes, even for rendering, all you need are just matcaps and some AO… :wink:

Besides, this concept almost made into blender already… :point_down:

So let’s make it proper… :wink:

1 Like
10

No reasons are ever obvious. Everything deserves to be questioned :wink:

The Clay engine example seems pretty complex to me, but I could see there being a toggle to either
A: Use one matcap for the entire viewport
B: Let the Material define the matcap

But again I see this as a very weak feature. It’s already possible to set a custom matcap per material by using the material nodes themselves.
Especially for the purpose of making quick and beautiful renders in the viewport, using Eevee should be a good way to go with maximum artistic freedom.

3 Likes
11

  1. Main benefits of matcaps are: they are lighting and other complex effects baked into single image and there are thousands of them already made on internet. It’s very easy to just use “metal” or “skin” or “plastic” matcap to get basic material look.

  2. Studio lights are unbaked lighting with some limited customizability. To get them look like metal for example you need to mess with sliders and complex effects like sss are kinda impossible (though you could fake it somewhat in past when ao color was tweakable and not just black).

  3. And proper pbr shaders in material preview allow you to do anything.

I feel like making blender matcaps very customizable, more complex to make but still restricting viewport to single matcap goes against their basic nature and will unnecessary duplicate studio lights / material preview functionality. Matcaps should be kept simple, but be swappable with few clicks per object, because once you have to mess with nodes you might as well go all the way and use proper pbr materials.

5 Likes
12

Trust me, it’s not weak… once implemented, it will be your best friend… :wink:

My thoughts exactly…
To me, right now, matcaps per object should be the high prio improvement related to matcaps before anything else…

1 Like
13

LOL. A debate shouldn’t be necessary to see how important matcaps per object is.
Not be able to use matcap per object should be considered a bug or known issue really.
Why do you guys think matcaps are very powerful in zbrush? If it was just for the entire scene like in blender it would be limited as hell.
It will be a game changer in blender.

@TheRedWaxPolice bruh, you are fighting for it for a long time lol. I hope you win this war. lmao :v:

2 Likes
14

:tired_face:
But yeah, it’s a crucial workflow to unleash the full power of matcaps in blender… so let’s keep fighting… :wink:

15

Hmm ok I was looking a bit more into how the Viewport Display settings are used for materials.
Turns out they are only applied in the viewport when the Color setting is on “Material”. That would include any defined Matcap.

Screenshot_20230303_102003
Screenshot_20230303_1020031920×1182 75.7 KB

But for sculpting it’s gonna be much more common to have the viewport on “Attribute” to paint the meshes, which is primarily using the Viewport Display settings from the object properties.

@TheRedWaxPolice @ThinkingPolygons
So would you even consider to instead set the Matcap per object, in the viewport display settings of the object properties?

Screenshot_20230303_102205
Screenshot_20230303_1022051920×1175 77.9 KB

16

Zbrush is lacking a lot of features Blender has so it has to compensate with matcaps. Blender doesnt have to do the same.

3 Likes
17

The matcap should be per material if it’s going to be customizable like that, not per object or collection. We don’t need a second material assignment system. And it’s better if you have multiple materials in an object, material assets could come with a matcap pre-configured, etc.

10 Likes
18

I was just sharing some observations.
Tbh this is adding too much complexity for very little benefit. Unless Matcaps can be assigned per material while showing color attributes, it’s not that useful anyway.

Again, if maximum artistic freedom is the justification, Eevee can already be used for that and beyond.

1 Like
19

That’s what I had in mind actually… simple enough…
But apparently the devs don’t think it’s the best approach… :frowning_with_open_mouth:

Still, there are different ways of doing this, I think… Like for example a “Fill” function inside of the color filter tool, that fills the object with the current select matcap… something like this would do the job just fine as well…

This is crucial, yeah…

This goes beyond zbrush… Matcap is a material… so it’s weird not be able to apply different materials on different objects…

20

I think matcap per material (the ability to set up material as a matcap to display and render by using specific reflective texture coordinates ) is a concept which was made available for a very long time ago.
For example, this is the way we has used to set up zebra shader since, probably, 2.6+, before we proposed it as a separate matcap :

1 Like