The big Blender Sculpt Mode thread (Part 1)

[Kologe]

I feel some in this thread have a bit of a one-sided, biased view of this whole ‘do the devs ever listen to the artists on not’-question.
There seems to be an imho inappropriate amount of frustration and negativity in the reception of the development taking place.

Now I’m by no stretch trying to say you must not be critical of development decisions. But I feel the discourse in this thread is quick at getting the pitchforks and torches out, if something can be even vaguely interpreted as steering in an undesirable direction.
On the other hand, if development (even with regard to the very same concept or possible feature) steers in the right [read: desired by the critics] direction, nobody on this thread ever looses a single word about it. They just take it for granted, it seems, in some very self-entitled manner, I get the impression.

An example: There was quickly a lot of hysteria in this thread as soon as some statement from the devs could (if ever so vaguely) be interpreted as them (the Blender devs) opposing the idea of ‘sculpting and painting at the same time’, in a single brushstroke:

Being able to sculpt and paint at the same time is a very nice quality of life change and you want to remove that for a system that is “less complicated”? You’re just pulling my leg now.

From where all this hope is coming from?
There are no indications or plans of leaving vertex colors in sculpt mode AFAICS… or there are?
Now, if a miracle happens and they decide to leave vertex colors in sculpt mode and add back the ability to sculpt and paint at the same time (yes, it was already possible, but the feature was removed, idk why) then great…
But until then, this is what it is…

UI team happened…
For them, “sculpting and painting at the same time” is some sort of “corner case use-case” and it would just clutter the sculpt mode’s UI… can you imagine that?
And boom, just like that we lost a very valuable feature…

With that said, why does nobody aroud here seem to acknowledge the fact several statements in several recent ‘Sculpt & Paint’-module meetings quite clearly and unambiguously seem to indicate (if not outright verify) the official plan is to eventually support the feature of ‘sculpt and paint at the same time’ and not to completely rip out all painting abilities from sculpt mode alltogether:

• Color attribute painting might just as well stay also in sculpt mode. UI/UX just needs more attention still

source: 2022-4-13 Sculpt/Texture/Paint Module Meeting

• T97957 Sculpt Mode Painting
• Decision needed if we keep painting tools in sculpt mode
• For sculpt and paint at the same time absolutely necessary
• We agree that sculpt mode could override the color setting without changing it
  • It could be done in a similar way to dyntopo, as a toggle
  • Enable Canvas either manually or once painting tools are excecuted
  • Making a painting tool active will at least turn on color attribute shading for as long as the tool is active

source: 2022-5-11 Sculpt/Texture/Paint Module Meeting

Why Sculpt Mode should keep Painting Tools

While Sculpting almost any kind of asset, colors will become important at some point. It is often a basic part of the sculpting workflow to add colors to your model and since the new painting tools run directly on the Sculpt Mode code this is easier and better performing than ever.

While freely sculpting any asset the form could change drastically at any point, which could mean that the colors won’t match any more.
As a result it is common to switch between sculpting tools and the painting brushes very regularly.

There is also the advantage of using the “Mask by Color” tool in Sculpt Mode to create a mask from the active color attribute.
This tool can be used repeatedly in a short span of time and switching modes for that purpose would be frustrating.

A likely future addition to the sculpting toolset will also be to add a color input to most sculpting brushes.
This will allow the user to sculpt and paint in a single brush stroke and colouring their asset faster and more intuitively in the process.
For sculpting with texture masks this feature would be especially useful and could skip a lot of time spent trying to paint colors that match the sculpted shapes details.

source: T97957 Sculpt Module Painting

So in the light of all this, the question is: Can we strive for a more balanced discussion?

greetings, Kologe

[Harti (Steffen Hartmann)]

(2) blender.chat

[Hologram]

I think that the devs definitely do listen, but not everyone is able to participate in development decisions or is able to contact the devs personally. They definitely do listen when there’s user involvement. Thing is, with patches and/ or right-click select threads, there’s no response from the devs and only few of the feature requests seem to land in Blender.
On other occasions, really neat patches remain in limbo due to unresolved and simple design decision (UI) by the Blender Foundation. Relatively simple feature requests (low hanging fruits) seem to remain mostly unaddressed, which is what I mean when I say: “it needs some polishing.” That’s where users are particularly involved and feel like there is a lot at stake, but developers seem to be particularly absent. There should be a place where these things could be mentioned. They are not really feature requests, because they are essentially papercuts. But the papercut threads were, I believe, closed on devtalk.

[Metin_Seven]

@Kologe

if development (even with regard to the very same concept or possible feature) steers in the right [read: desired by the critics] direction, nobody on this thread ever looses a single word about it. They just take it for granted, it seems, in some very self-entitled manner, I get the impression.

This is a wrong impression. There are many cheering posts about new features in this thread, and rightly so. But everyone’s free to express their impressions and opinions here, including not-so positive comments, as Blender Artists is an independent platform by and for Blender users. As long as we keep it civil.

[zeauro]

I think there is a legitimate frustration.

2.8 redesign was too ambitious to only concern 2.8x series.
It was corresponding to a workload of a decade for developers.
The painting and texture workflow was a little bit neglected by that design.
During the process of posing fundamental blocks of the design, old technical debt was not entirely solved. And time for communication with patch writers was missing.

When Pablo came in, he created a refreshing atmosphere of new ideas solving a lot of issues.
And his improvements were immediately acclaimed. His work is the reason this thread exists.
He gave new horizons to this module. The issue is that path to reach them will be very long.
That generated another kind of frustration.
The idea that he was working on superficial stuff when more urgent and basic stuff should be solved.

Now, Joe worked on Bmesh and dyntopo. That are a part that Pablo would not have work on.
So currently, we have a huge amount of features that are only available on experimental, in development branches. And there are still a lot ideas floating in the air.

I think that Julien Kaspar is currently doing a great job to build a coherent design from all these ideas and current status of Blender.
He is not proposing to integrate all ideas, now. But he is making a proposal of a Paint mode that should end-up in Blender, quickly.

He already did a great work about keymaps issues and fallback tool. I have faith in him.

When extended asset browser, new curve object, viewport compositor, brush management and this new paint mode will be in place, software will eventually have a coherent new base. At that moment, devs will be in position to solve long-standing issues without the fear to prevent integration of a future block of ecosystem.
Since 2.8, development has entered a new phase of simplification of workflow.
But now, things will begin to stop to be partially true for one part of workflow, and partially false for another one.
The entire workflow would have been simplified. And the entire workflow will become more and more fluent. Things that had been stepped aside during 4 years will be treated.

I think that people who started with 2.8 will consider target reached, at the end of next year.
But people who started with 3.0 series will probably have new sources of frustration, at that moment.

[zeauro]

@RaphaelBarros

Can anyone find where this change is listed over at developer.blender.org ? I really need to understand what was the thought process behind this change. I truly must be missing something. Maybe it’s a bug, I don’t know.

I am not sure. But I think that is this one.
https://developer.blender.org/rBcfc46e43b2f4f653f2412ae564d3c6fb6638139a

I think that the idea is to reuse principle used for Falloff in order to simplify code and memory footprint.
What is sure is that Joe should be the author of change.
He is the only one modifying the branch.

Anyways, you are right. The change is not coherent with how pressure curve is handled in Grease Pencil brushes.

[thinsoldier]

@zeauro

During the process of posing fundamental blocks of the design, old technical debt was not entirely solved.

I want “Animation 2023” followed by “Slow and Boring Technical Debt Payment 2024” and then “Hype Train 2025” and then “Make Blender Run On Toasters Again 2026”

[Frozen_Death_Knight]

I think the reason why some are getting frustrated is that it has become increasingly harder to discuss the direction of Sculpt Mode with the developers. Not much has been going on with it in the master branch since Pablo left last year, who was the driving force for a lot of the improvements done to the master build. While Joseph and other devs do a lot of good work, the connection that the sculpting community used to have with the devs has not been maintained as swimmingly. There is a clear disconnect going on here.

Also, I think most people here have been pretty constructive with their negativity. It’s not like we just say that their work is bad and that they should feel bad, but that there is a clear problem with being able to deliver our feedback to the development team. Heck, I even gave a couple of suggestions on how to fix it, so I am more than willing to work with the devs on this issue. As Harti posted in that screenshot of his, the devs do not even want to engage this thread despite being the main hub for sculpting discussions, which to me is just a mistake.

That said, I am glad that they are taking steps toward making a proper channel for talking to the devs directly. I think there will be far less frustrated users that way.

[Hologram]

On the other hand, in the devs’ defence, they are doing a lot of work refactoring datasets (Curves, there is now also a proposal for Grease Pencil, Cycles X rewrite, Bmesh) once those deep and fundamental changes have been made. It will probably be easier to add new features and fix existing design flaws. They now know what they’d like to see changed, so they may have less interest in user feedback for the time being.

[Metin_Seven]

@Frozen_Death_Knight

I think the reason why some are getting frustrated is that it has become increasingly harder to discuss the direction of Sculpt Mode with the developers. Not much has been going on with it in the master branch since Pablo left last year, who was the driving force for a lot of the improvements done to the master build. While Joseph and other devs do a lot of good work, the connection that the sculpting community used to have with the devs has not been maintained as swimmingly. There is a clear disconnect going on here.

I can relate to this. In 2021 I was a part-time Technical Artist for the Blender Foundation for a number of months. As the exact tasks of that function were still being shaped by Ton, he gave me a lot of freedom. I thought a fitting activity for me would be to try and build a bridge between Blender developers and the Blender user community, but that turned out to be harder than I thought. This is not meant as criticism, it’s just an area that could benefit from more attention and effort.

[Michael_Knubben]

You’ve answered my question with ‘it depends’. What do you think? Based on the reasoning in that post, do you think it’s a good decision?

[zeauro]

There are issues.
Default mapping is shifted.
I did not succeed to make start of image matching start of stroke.
Setting of mapping is not intuitive.
And there are obvious artefacts at seams, that no option seems to have an impact on.

But since yesterday, there is a start of Roll mapping testable in sculpt-dev branch.

[TheRedWaxPolice (I know dead mesh when I see it..)]

Still depends on the person…
But for me it’s not, because of the way I use it… remesh is more of a base mesh creation tool for me… some people might use it differently…

When I’m starting a sculpt using the remesh workflow, at the early stages I really don’t care about preserving mask/face sets/color attributes, so for me those could be turned off by default, and just turn them on as needed…
What I do care about when starting is the preserve volume (for the obvious reasons), and the fix poles because of the slighly more friendly topology that it gives me:

At the early stages when the polycount is still quite low, the performance issues of the fix poles are not that noticeable, so you can remesh with it enabled just fine…
Later on when the polycount starts to increase and the fix poles slowdown is more noticeable, most of the time I already have most of the basic forms already established, so at this point I can turn off fix poles…

So for me a good default would be fix poles and preserve volume enabled, everything else disabled…

[joeedh (Joe Eagar)]

Sorry about that, I’m not sure what I was thinking there either. The code was flipping curves multiple times in weird ways and I got confused, and thought it was supposed to flip the other way. Anyway I’ve fixed it.

[Frozen_Death_Knight]

Happy to see you come in here and talking to us. Appreciate it!

[Michael_Knubben]

Thanks, that’s much more useful to developers!

In any event, I can’t fault the reasoning to go with minimal loss of data and maximum speed, but all of this makes clear that a robust way to set defaults is important, as you can’t please everyone.

[TheRedWaxPolice (I know dead mesh when I see it..)]

@Michael_Knubben

In any event, I can’t fault the reasoning to go with minimal loss of data and maximum speed, but all of this makes clear that a robust way to set defaults is important, as you can’t please everyone.

It’s possible to live without fix poles, but then you’ll fight the topology a little bit more when sculpting which is a tad bit annoying…

By the way, even with fix poles enabled, the topology is still not as even as zbrush’s dynamesh… so it would be nice if the devs could find a new trick to improve the voxel remesh’s topology…

And yes, a smarter way to save global defaults per tool would be nice…

[RaphaelBarros]

That’s awesome, and sorry if I sounded a bit harsh or rude.

[Metin_Seven]

@TheRedWaxPolice

the fix poles because of the slighly more friendly topology that it gives me:

Yep. Voxel Remesh with Fix Poles activated is very similar to ZBrush Dynamesh. Better, more even quad topology, which is more suitable for clean sculpting results.

[vily (12vily)]

sorry for the late reply, it’s good to collect these modes.