Same as Softimage|XSI with autodesk. History repeating itself
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.
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?
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.
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).
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.
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?
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:
- 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.
- 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.
- 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.
- 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.
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.
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.
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/
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.
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?
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.
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
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).
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.
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