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.
3 Likes
That and the buggy state of the undo redo system
1 Like
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.
3 Likes
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
2 Likes
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.
7 Likes
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?â
1 Like
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.
2 Likes
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.
1 Like
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.
1 Like
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.
1 Like
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).
2 Likes
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.