Pablo Dobarro's master plan for sculpting and painting, development news

Several artists requested an Insert Mesh Brush.

But currently, Pablo is improving performance of switching from one object to another.

Blender offers to you ability to do it in Edit mode or Object mode.
If you are using few primitives, you are not creating heavy meshes.
Edit mode and Object Mode performance is not bad at the point they can’t handle that.
At that level switch to sculpt mode is not unbearable. And when things may become complicated in edit mode, object mode is a solid alternative.
You can also prototype a shape by using Skin modifier or Metaballs or using Dyntopo.

That may be considered slow to have to switch from one mode to another one.
Sculpt mode is an exception of mode not handled by multi-object editing.
Currently, you have to pass Active Object to Object mode to be able to add a new primitive. And when it is done, you have to pass 2 objects to sculpt mode. Former active one and newly added active one.
But that situation will not last. In theory, a switch between Layout workspace and Sculpt workspace should become satisfying.
That should be a lot simpler than adding a lot of object mode tools in Sculpt mode.


Don’t hold your breath… :neutral_face:

The only tool remotely close to an IMM brush is the Jsculpt addon(as mentioned above) Far from ideal, but better than nothing. Tabbing to Object/Edit mode works pretty well and with addons like Boxcutter and Qblocker you can place primitives quickly. Plus you have the benefit of all the tools available in these modes.

Maybe when there’s some sort of asset manager we could use masking or Face Sets to place primitives, or hopefully someone will create an addon to rival Zbrush IMM brushes.


Is Pablo Dobarro unhappy with the patch review process. What could have happened.

well i saw a video of you what mean in zbrush, and yes indeed we need that feature in sculpt mode…


There’s another interesting option: MiraTools includes a number of interactively placeable primitives. Below is a video demo. Be sure to watch the entire video. He creates a lot of cylinders first, but it’s worth viewing entirely.


I can imagine that with the recent growth of Blender, and the amount of involved developers, an increasing bureaucracy is inevitable. Processes need to be streamlined, administrated, structured. There are more meetings and discussions to guide everything that’s going on.

I think Pablo is a fast thinking and practical coding genius. He wants to proceed with speed, and that will probably be impossible sometimes.

I used to be a full-time game designer, many moons ago, working with a similar coding genius. He often came up with brilliant stuff, but it wasn’t always according to the rules that surrounded development. I was on his side, but things can not always unfold as you’d like, especially when a project or company has outgrown the pleasantly clear and accessible initial stage.


I completely agree. The bigger Blender becomes the more issues will arise in that area. Although, Blender is not a commercial company it does show some growing pains of one.


Not enough free devs to review his stuff… :wink:


I don’t see this being posted before:


Yes, they have well over a dozen developers on the core team now and letting all of them do their own thing their own way would be chaotic.

You still have to make sure that every developer’s plan will not interfere with the work of other people and will not break the overall vision, so the increased number of meetings is almost unavoidable. There’s also the issue of making sure the massive number of new features and tools just work for users, and that the overhauls and optimizations don’t break anything (hence why the gears have now been shifted to bugfixing for two weeks).

There is also a strong argument for the BF’s decision to base their hiring and planning to have just one or two core devs. in any one area of Blender at a time, to help avoid the problem of interference and to avoid the massive development issues of other large projects like Unity (reintroduced bugs, overly fragile code ect…).

Then you have an environment where the BF is seeing an increased number of patch submissions from a growing pool of volunteers, so the devs. now have to spend more time prioritizing and reviewing patches (which may mean longer waits for larger submissions).


I saw someone post a video of the keymesh feature similar to this a while ago, but man… This feature will absolutely change the game for animation in blender. Imagine you could animate a character the usual way with a rig and some corrective shape key drivers, but then add dynamic features with the keymesh on the fly throughout the animation to give it this greater level of polish and control. It’s gonna be very exciting to see what kind of things people are gonna make with this.


As I said when they first showed off the prototype, this type of technology is going to make traditional stop motion movies go practically extinct.

Plenty of CG movies have already bridged the gap between the two mediums to practically look indistinguishable from each other. Having a free and open source software able to perfectly emulate the stop motion style in a convenient workflow will make it hard to justify the long and expensive process of creating everything by hand.


I got an answer on my MultiRes masking bug report. While it seems that it has been fixed now, I am a bit bummed out by Sergey’s answer that they don’t consider it a bug that level 0 and the other subdiv levels have completely separate masks and do not propagate from level 0 and up. Face Sets does this and ZBrush has masking working like that with SubDivs, so why can’t Blender?

1 Like

What does he(Sergey) mean by this: ‘This is how the current design work (as I’ve mentioned before multires and non-multires masks are separate).’

So level 0 is ‘non-multires’ and all levels above are ‘multires’? I really don’t understand this, between this and the whole level 0 apply base thing, the multires modifier is becoming unnecessarily convoluted, imo. Why this can’t just be a simple sculpting subdivide levels system with level 0 considered the same as every other level I can’t understand.

A brand new sculpting-centric system/modifier independent of Multires seems like a far better option at this stage.


Every one of these issues could be avoided if they stopped trying to shoehorn multires into being a modifier. It doesn’t lend itself to such a design. If your modifier can only go in a certain position in the stack, then it doesn’t belong there.


I completely agree. While it has become a lot better, I do hope that they will do something similar to what they are planning to do with Open SubDiv and make it a mesh property or whatever they mentioned to improve its usefulness. Things would just be so much simpler and to the point with none of the current downsides as you said.


Hmmm, the way I see it, the devs are kinda doing their own thing, no? Hence the chaos… :thinking:

:100: :100: :100: :100: :100: :100: :100: :100: :100: :100: :weary:

Lighting a candle on my Dobarro altar, I’ve got a wish which I hope will reach him via this magical thread:

I’m still a Dyntopo lover (in fact I recently rediscovered it after viewing this course by Kent Trammell), and I’ve noticed that using the Elastic Deform brush while Dyntopo is active makes the brush agonizingly slow.

This results in constantly having to Control + D before and after activating Elastic Deform, while this isn’t necessary when using the Grab brush. Dyntopo is automatically inactive when using Grab, but you don’t need to deactivate Dyntopo.

If this could be fixed, I’d be a happy camper again.

Thanks in advance!


Well, this is what I’ve said from the start. A system inherent to sculpt mode would have been better. A fully non-destructive modifier for sculpting purposes is unnecessary and not suited to the workflow. I see no benefit to it at all.

1 Like