Jeah, i dont see the separated program idea… Its not the intuitive blender workflow… Sculpt mode performance isnt too bad with multires aka realistic sculpts are possible…
Improvements are always possible and needed but not as simple as for an independent program like zbrush… so dont expect miracles but improvements are probably possible like sculpt layers and such…
Looking back at the developer blog, the ideas for sculpt mode sounded nice…
And for the record, I wasn’t advocating abandoning all that - just pointing out that the development and user ecosystem for Blender is completely different than iOS, so drawing a comparison between 2 softwares that are somewhat similar in theory doesn’t mean that one can just easily mimic the other.
Not really. Theres no reason it couldnt be transparent to the user.
The problem is that sculpt mode overstresses the BFs institutional capacity. The BF is currently run more like Apple supposedly is, highly centralized with no team duplication. Its like MS in the early 80s; when they burned through one Windows project lead afrer anothet. This isnt sustainable. One way or another Blender dev teams are going to decentralize, whether its a rraditional corporate divisional structure or something else. That in turn will force greater code separation.
Give up
Call it quits
Stop the project
I am hearing this a lot on the forum recently, and it actually makes me wonder just how many here remain on Blenderartists because they continue to actually use Blender, or they are here now to just bash the project and the developers.
These issues are solvable, it is just a matter of the BF learning to have the right set of priorities, especially after making an announcement regarding development on the code blog or on devtalk. Things do in fact tend to move quickly once one or more developers begin to fully focus on a specific subject such as what we saw with Geometry Nodes.
And people wonder why the majority of devs. see this forum as just noise.
Maybe you’re listening to your own words too much. 
greetings, Kologe
Blender is moving in the exact opposite direction with code unification across all parts of Blender, it’s going great and devs are happy about it. It also simplifies things for newcomers as you won’t have to learn 100 things for 100 different functions. So, why will that change? You’re coming up with lot of predictions but I haven’t read a reason from you, why will that happen?
And any improvements to sculpting or other modules isn’t halted because it’s impossible and above BF capabilities or something. It’s just a matter of time and priorities. Hans has laid down plan to modernize sculpt mode code, refactor brush engine, etc. And I don’t see any stoppers mentioned anywhere. I’m not sure (or maybe I am) why some people try to portray Blender code as unsolvable quest, when capable people are quite comfortably solving it along the way.
I’m going to put it bluntly. This is probably the worst idea I’ve read on these forums so far. Truly an awful idea
It’s very funny to see all these replies criticizing a certain user and saying things like this:
Y’all do realize you’re talking to/criticizing a sculpt mode developer, right? Maybe if you want developers to take this forum seriously, you should… take developers seriously?
Like i said, already happy with most of the performance since realistic things are possible…
Just some missing features and a bit more optimizations and its a great addition otherwise use dedicated programs for sculpting and not inside blender…
Send a bug report with a video showing the before/after…
Do you have any idea how enormous Blender is feature-wise? Each part has different needs than the others; the needs of Geometry Nodes do not match up with the needs of sculpt mode, or the paint modes, or the animation system, etc.
It simply isn’t possible for one highly centralized development team to develop an application of this size. None of this is new btw, why do you think Ton came up with the concept of development modules?
Btw, for those who don’t know a “divisional corporate structure” is a company with distinct, mostly independent teams. The opposite is having either a single centralized team, or a series of specialized ones that work on the whole product line (e.g. so instead of having an IPhone division with hardware, software, and marketing teams, there’s three big uber-teams for hardware software & marketing).
This sounds good on paper, but it doesn’t work in practice and often leads to highly toxic workplace environments. The biggest weakness is when the incentives and experience of the uber teams don’t allow for the specialized knowledge needed for a major product; Blender has this problem for sculpting, projection paint, and CAD.
Well I’ll just say that I’m glad Blender developers aren’t agreeing with you on that one.
And yes, I know what “divisional corporate structure” is, I’m a political scientist by education. It was one of the very attractive things for us students back then, we were drawn to examples of that structure, but mostly because of “how dumb can management be” reasons…
I would encourage you to register an account on the Unity forums, Unreal forums, C4D Cafe, Autodesk AREA ect… to present your case on those apps. being broken up into little pieces and tied together with an I/O format (as codewise they are at least every bit as big, if not even bigger). I can assure you there are a lot of benefits to having a one stop shop for end-to-end content creation rather than having to make your way through more than half a dozen apps. just to put a scene together for rendering. Just the job of keeping them all updated and in synch would be a nightmare.
It might be less work for developers, but it greatly increases the amount of technical skill a user must have to manage a pipeline that long (to the point where hobbyists can no longer just jump in and make something, but instead we regress back to the days where one might need formal training first).
Yes, we are aware of the numerous areas where the BF needs to improve in terms of development management, but none of that is the direct result of Blender being a monolithic app.
Divisional structures have a lot of advantages compared to a centralized structure with uber-teams. Coordinating huge uber teams becomes exponentially more difficult as company size grows which can lead to toxic culture spirals and highly abusive workplaces. IMHO I think workplace abuse is actually the norm for highly centralized systems; it takes very strong senior leadership to avoid it and once they retire (or get cancer) things can get very bad very quickly (just look at Pixar).
Divisional structures solve this by having smaller units that each have their own teams. Company-wide teams still exist but are much smaller in size and scope. Senior management can detect and break up toxic cultures within divisions at earlier stages, and if they fail the division can be dissolved and a new one created to take its place.
On a personal note, I think divisional systems are much better at protecting employees. They don’t select for sociopathic behavior in senior leadership the way centralized (the word is actually “functional”) systems do, and they create a layer of middle management that’s invested in the success of individual line employees in a way five or six people at the top of the organization are not.
Eh I’m not suggesting tying things together with an IO format. There’s no need to have separate applications. This isn’t the 90s. I’m not suggesting Blender stop being a monolithic app, that’d be ridiculous. Just that we separate the teams a bit and, yes, the code but remain a monolith.
Even if we assume Blender just gets a package manager like Unity does now, it will still lead to nightmares for users (in the form of tracking dependencies and synching). It also does not guarantee better development as said packages are just as prone to being neglected as a traditional codebase (with the addition of potentially not working at all after a time).
Take a look at all of the stories of Unity users wrestling with the package architecture and you will find it does not exactly solve anything in the long term (but rather just leads to the same problems in a different form). The BF for starters has developers dedicated to code maintenance, and I assure you there are a lot of optimization routes the devs. can now take with the ongoing move of the codebase from C to C++.
