The big Blender Sculpt Mode thread (Part 2)

Same as Softimage|XSI with autodesk. History repeating itself

3 Likes

Canā€™t agree more. Switched to blender in 2018 and Linux as my daily driverā€¦ so i had to force myself to use gimp and inkscape (i still press photoshop shortcuts in gimp lol) but from 2012 to 2018 I stayed with CS6 (still have it on an old system) and i didnā€™t feel i was missing anything.

2 Likes

I think a good comparison/benchmark would be Mudbox. Yes, I fear Maxon has ā€˜Mudboxedā€™ Zbrush desktop, but Zbrush still has all sorts of unorthodox yet unique and powerful workflows that are just part of the nature of what it is.

Mudbox is closer to what Blender sculpt could be because of the true 3D nature - real 3D viewport, cameras, lighting, and materials. Plus a proper outliner, UV tools, and UDIM/USD support. Not to mention the ability to use modern GPU computing power. These are all Zbrushā€™s weak points and weak points that can never be fixed or improved.

Mudbox (still actually favoured over ZB to this day by some pros) has excellent sculpt/paint layers and displacement baking features. These would all be great goals for Blender devs to set. This is why I feel that Mudbox is a better comparison for Blender Sculpt Mode, with Blender obviously having the huge advantage that it is a also a full DDC with all the bells and whistles that go along with having these features alongside your sculpting features.

Future for sculpt mode is looking brighter and brighter. Maybe one day Iā€™ll finally say my final farewell to Zbrush? :pray:

15 Likes

Iā€™m also wondering what sort of performance improvements sculpt mode might benefit from when the Vulkan backend is stable and they move into the optimisation and performance phase of dev? Couldnā€™t this potentially take all aspects of Blender to the next level in performance?

I know that performance all across the program has greatly improved in recent years, but I do still find myself experiencing lags here and there that feel like they just shouldnā€™t be there. On a recent project (V4.3) I was getting lags with simply moving UV islands around or moving a few verts with proportional editing, and this was on meshes that were not even ā€˜thatā€™ high res.

5 Likes

With the complexity of realtime shading these days, moving to Vulkan is really the only way to get things like compile times under control. OpenGL has really been starting to show its limits when it comes to highly advanced algorithms for things like realtime GI and the ability to compile such in an optimized way.

That OpenGL has become bloated over time does not help either, last I checked version 4 was an ever-expanding amalgamation of functions and APIā€™s with no real management of technical debt. That it allows more avenues for performance in general has become critical as Mooreā€™s law grinds to a halt (at least until we move beyond Silcon).

3 Likes

The lag you were experiencing is very likely due to being bottlenecked by the CPU, which is what most algorithms in sculpt and edit mode use, with a few exceptions.

The main use of GPU for sculpting is rendering the viewport, which in my opinion already has a very good performance. With a RTX 2070 (which is a 6-year-old GPU), even when the ā€˜Fast Navigationā€™ option is off, I can navigate the viewport while working on a mesh with 50 million vertices and feel very little lag.

2 Likes

Yes, the sculpt mode perf is greatly improved, while other areas such as edit mode translations, modifiers, and UV translations can lag. Are these other areas eventually to be refactored to GPU? Iā€™m on a i9-12900K so I wouldnā€™t expect a bottleneck during relatively non-intensive operations, or maybe Iā€™m expecting too much?

2 Likes

Some code are not adapted to be processed as a multi-threaded process and instead does it single-threaded meaning that it not going to use your full CPUā€™s potential and core speed capabilitiesā€¦and gpu is more harder to transfer code or something like that or is some unstable with that adaptation: Well i did a quick research and since i dont have time to read all varied technicall info online here is a resume answer for that from Copilot;

Transferring code from CPU to GPU can indeed be challenging and may introduce instability. Here are some key points to consider:

  1. Code Adaptation: CPU code, especially if itā€™s single-threaded or multi-threaded, often needs significant adaptation to run efficiently on a GPU. GPUs are designed for parallel processing, so the code must be restructured to take advantage of this capability.
  2. Data Transfer Overhead: Transferring data between CPU and GPU can be a bottleneck. The PCIe bus, which connects the CPU and GPU, has limited bandwidth compared to the internal memory of the CPU or GPU. This can slow down the overall performance.
  3. Stability Issues: Running CPU code on a GPU can introduce stability issues, especially if the code isnā€™t optimized for the GPU architecture. This can lead to crashes or unexpected behavior.
  4. Performance Gains: Despite the challenges, the performance gains from using a GPU can be substantial for certain types of workloads, such as those involving large-scale parallel computations.

If youā€™re considering transferring CPU code to a GPU, itā€™s essential to thoroughly test and optimize the code to ensure stability and performance. Tools like CUDA for NVIDIA GPUs can help with this process.


and thatā€™s been happening with blender, from old but ā€œrefactoredā€ tools and operators that were transferred to every new blender version (since 2.8) but not optimized enough for the modern hardware speedsā€¦But blender devs having been catching up with that optimization from the core, interface, and a few other internal background things, making use of multi-threaded and other optimizations, and soon to be OpenGL graphics interface replacement which is Vulkan, and many more to come with due time and patience with its current development pace.

2 Likes

Areas such as mesh or UV editing donā€™t get too much attention performance-wise probably because most people use them with low- or medium-poly base meshes, so itā€™s not a priority. But if I had to guess thereā€™s likely room for at least a 10x increase in performance.
For example, the performance of the grab brush in the UV editor could be brought up to the same level as the grab brush in sculpt mode, or scaling in edit mode could be made as efficient as the scale tool in sculpt mode.

5 Likes

Iā€™m not even entirely sure about that.
You can only ever have a single object in Sculpt Mode at a time, but as many as you wish in edit mode simultaneously (as limited as multi-object editing may be, in its current form in Blender).

And one thing to keep in mind is the fact at least some tools in edit-mode rely on using Bmesh internally (iirc the Knife tool is a typical example), and that comes with a performance penalty (converting bmesh <> mesh), which is also why certain geometry nodes which historically used to internally work via an intermediate bmesh representation have recently been rewritten to work on the mesh datastructure itself directly.

So without any deeper knowledge of the code and technicalities, I doubt any of us around here can make much of an educated guess.

greetings, Kologe

The number of objects shouldnā€™t matter, the main variable is the number of total vertices. The first step for a better performance in edit mode would likely be replacing the use of BMesh, itā€™s just not the most efficient data structure for operations involving a large number of polys.

8 Likes

Iā€™ve made a PR for a new brush (Plane brush), a generalization of the existing Flatten, Scrape and Fill brushes. It has parameters to control height and depth, and stabilizers for the plane of the brush.

Any feedback is very welcome!
PR: https://projects.blender.org/blender/blender/pulls/132723
Download: https://builder.blender.org/download/patch/PR132723/

22 Likes

Thanks! I just did a very quick test but it already feels better than the existing Flatten, Scrape and Fill brushes. The Height and Depth sliders are more intuitive IMO.

Iā€™ll try to spend a bit more time testing it later today, to give proper feedback, but I really like the behavior of this new plane brush.

7 Likes

Thanks! Iā€™m interested to know if people can create useful brushes with it, such as polish brushes or brushes for hard-surface sculpting. And if not, what do you think is missing?

Also, something totally unrelated to the plane brush: when sculpting with a texture (either as a mask or for VDM brushes), which options would you guys consider important? For instance, does anyone ever adjust the settings within the Sampling panel?

tex menu

The Sampling panel is really of no use to me. In the Texture panel I use the parameters Sampling bias, Size (X,Y) and Angle. Sometimes in Mapping Mode I choose Tiled with Stroke Method Anchored. The Rake function is useful, but I really want to get a full Stroke Method Roll.

3 Likes

Yeah I donā€™t think Iā€™ve ever used the Sampling Panel with a texture for sculpting.

The only time I vaguely remember changing anything in that panel was in the time of the Blender Internal renderer, and Iā€™m not even sure why it was useful back then :sweat_smile:

1 Like

Sampling Bias has its importance for sculpting.
If you use Anchored method, you may pass from a texture with enough resolution for standard radius on standard mesh density of Space method, to a pixelated aliased deformation on a bigger area, corresponding to an higher mesh density.

Using Tiled mapping implies that texture used represents a tile-able pattern. So, it is not relevant for pattern representing a sign, a logo.
And if user desire is to represent a scaled pattern, at different scales, with Anchored method ; Tiled mapping stays inappropriate, anyways.

Playing with auto-smooth and Fall-Off will not be satisfying to solve an aliasing that could happen in center of texture deformation.

But, although sampling of texture panel was thought for rendering ; it may still have its importance for texturing, if resolution of painted texture is big compared to brush texture. In that case, it could be preferred or complementary to sampling bias.
That is rare to paint texture in Blender Texture Paint mode. That is rarer to paint big ones. But the case may become more common, if texture painting is improved.
People will probably not care about absence of settings ; if it is automatically set to be satisfying in common and extreme cases.
People would probably be fine to just have simplified Interpolation settings like Image Texture shading node ones.
Sometimes, the artist wants a sharp but anti-aliased result. Sometimes, he wants a blurred result. Sometimes, he wants to do pixel art.

Mapping panel of Texture tab is not really redundant with mapping of brush texture. Mapping panel of brush texture donā€™t do flipping, mirroring or cropping.
And color and alpha adjustments are making sense for painting (color ramp for procedural textures).

For the most of it, Texture tab is coherent with brushes we have.
Except for Sampling Interpolation, only reason, to change it, would be to improve other stuff ( to reuse EEVEE/Cycles textures, to use texture nodes or layered images for brush textures, to use brushes with other settings).

4 Likes

Sculpting

Non-destructive sculpting with layers, and better keyboard-less workflow.

Multires propagation spikes remain a critical issue. These occur when changes to lower subdivision levels are not properly reflected in higher levels, leading to infamous artifacts. Fixing this problem is a priority to ensure the multires modifier works reliably in production.

Sculpting Layers are a natural next step now that sculpting mode can handle more data, thanks to last yearā€™s performance improvements. Adding support for mixing multiple layers will enable higher levels of detail and deforming layers essential for animation workflows, giving artists greater control and flexibility.

Tablet pen support is important for workflows like sculpting, painting, and 2D animation. While the mouse can often be replaced by a pen, Blenderā€™s heavy reliance on keyboard input makes it cumbersome to use. Even more so for display tablets and, in the future, portable devices. The initial focus will be on supporting touch inputs, with basic gestures for navigation, undo, and redo.

:thinking:

17 Likes

Thatā€™s nice. All Iā€™m hoping for is attribute support in multires. I think it was mentioned in the sculpt layers document. I really want vertex painting in multires :frowning:

10 Likes