Thats only in fracture modifier branch not in 2.8
Oh sorry my mistake:(
Is there any news on subdiv editing performance? I’d love to start migrating to 2.8 about now, but the performance is a total dealbreaker for me.
That and the buggy state of the undo redo system
i assume the opensubdiv speed up will come in the final month after all the bug fixes
It’s not just in edit mode - getting abysmal performance in object mode when translating a mesh with ~1000 faces and a lvl 2 subdiv modifier. Navigating the viewport seems unaffeted, though.
Well I hear everyone saying that performance optimizations usually come in last after everything else is fixed up and the official release won’t come until April, so there’s still some time left. Anything further like GPU acceleration for Opensubdiv won’t be coming until 2.81. Kind of sad but keep in mind the devs are aware of performance issues and have this known for some time. After I took a look at their blog post and the upcoming features I have renewed confidence that the devs are listening to the users and they absolutely know what they are doing. We just have to be patient.
After the bug fixes, OpenSubDiv and multi-threaded modifiers are my most wanted features. I’m new to Blender and just started Sculpt January, and I thought it was odd that my newly built pc would slow down (or freeze for a few seconds) when working on ~1m faces objects.
If OpenSubDiv won’t be coming back anytime soon, I should probably just use 2.79 for now if my focus in on sculpting / modeling right?
you guys need to give time to the developers
the statment of blender foundation right now is -do no use blender 2.8 in production-
speed comes at the final stage when everything its getting optimized
Yes, but the devs should be more realistic. There’s no good reason for keeping openSubDiv in master over the older legacy subdivision till they have ironed out all the kinks.
Right now, it’s important to cut out the parts that aren’t working yet (like they did with the override system) and save them for when it’s been properly worked out.
How exactly do you iron out performance kinks without putting the code in and testing? This is software in development and the stable release is months away. Anyone working in 2.80 right now should expect things to break and should avoid using it in production if you’re on any kind of time schedule.
Sure, that’s totally true. However if you put a feature in and it’s far worse than it was expected to be, you should at least allow a transition period where you have the old technology along side the new. Or, you can assemble it in its own branch and merge it in when it’s fully ready like it’s usually done.
It’s obvious that the main advantages of opensubdiv have not been implemented yet. So… what’s the point? What are we testing? How much is, “Hey it’s way slower than it used to be!” Helping them? It’s fine if they leave it in to work on it, but what I object to is removing old tech for new when the new is clearly not better.
I have the same issue with Mantaflow. One day it will suddenly replace elbeem and there will be a flurry of people asking, “wait, I just want good looking smoke, why is it worse now?”
That, and also there won’t be much real world testing going on unless it’s actually usable for a real world scenario. The bad performance just means people will limit tests to silly boxes and such instead of the often very heavy loads production demands. So it’s kind of an egg/chicken problem.
This type of thing would be true in the middle of a release cycle if not for 2.8’s intention to be a major overhaul that breaks workflows, old scenes, and old knowledge.
During the 2.6x and 2.7x days, the point would be valid because the master branch was supposed to remain usable. For 2.8, the devs. have no obligation to make sure it’s fully usable for production until it hits the release stage (which means they can swap/replace technology as needed to prepare Blender for the future).
That’s not to mention what we know about the behavior of the average software user. For most people, if they can choose between a stable, working feature with notable weaknesses and a new feature with advantages but not yet fully stable, they will choose the stable one and more or less ignore the experimental one. Sometimes, you have to take a leap of faith and remove the old feature if you want to ensure it gets a maximum amount of testing and generated reports.
Behavior similar to what it mentioned above is also a rationale for more frequent releases, bugs will always slip through because the majority of users will never use dev. or beta builds.
Sigh. I realize all this. It’s just that it would have been nice is all. It was not my intention to argue about this at all. For the most part you guys are all totally right. I’m just personally disappointed by the current OpenSubDiv. But you’re right. It’s a work in progress.
We’ve had this transition period for a long while now. Opensubdiv has been in Blender as an optional switch on the modifier for a while. 2.80 is the right time to finalize the transition.
not if it hurts performance
When the BF tells us a build of Blender is not yet suitable for serious production, they usually have a good reason for saying it.
What seems to be happening is a rise in the dangerous idea that now with 2.8 in beta, users are entitled to full use of the developing version without having to endure any kind of regression in workflow and stability (which in this case should only be a thing once the beta period is over and development goes to bugfixing only).
It’s only the right time to finalize it if it isn’t a horrible regression like this one - unless the devs know for a fact they’ll be able to push the performance back up in the coming months. But none of them to my knowledge has stated anything to that effect, and there have been no performance-related commits since November when it was set as default. Well, none other than today - but this one just slows it down some more.
I’m not knocking anyone here, it’s just that the lack of communication is somewhat frustrating.
I’m well aware that 2.80 is currently under development, however wasn’t it mentioned that OpenSubDiv wont have proper acceleration on initial 2.80 release? So there is good reason for being concern about it.