Yeah, I feel the same. It’s really only now that they’re firmly acknowledging and communicating on these issues.
It be interesting to see how this works out, I mean most the core devs are generally still hard at work on bcon3/4 of the current release during those first few weeks of bcon1.
Not all. Subsurf modelling performance seems conspicuously absent. But a good number of them, yeah. Unless “without modifiers” is only there because subsurfs are supposed to stop being modifiers now. Let’s hope that’s the case.
1 Like
The todo point to take subsurf out of the modifier system is still an open task on the developer site.
I would think that it will technically be considered “not a modifier” once that happens 
I hope they don’t remove Subdivision as a modifier. That would shoot the “double turbosmooth” high poly method dead in the street, and it’s probably my most used hard surface high poly workflow.
2 Likes
It says on the design task that they plan to keep the subsurf modifier too.
2 Likes
Yes, though it reads like it’d be “want performance - go destructive”, want modifiers - suffer. Unless I’m not reading it right.
Subsurf used to be a mesh property back in Blender’s early days. Your post makes it sound like we would press a button to permanently increase the polygon count and smoothness of our meshes (with no way back later on), but even before modifiers it was by no means like that.
1 Like
What does it matter how it used to be? There used (and not) to be great many things. It used to be rendering was done with BI.
Subsurf being a modifier is an important part of modeling workflow. It’s used far more than just for rendering. If subsurf is made a mesh property, that becomes impossible. If it’s kept also as a modifier with no performance improvements, that leaves such modeling in a sad slow state that it is now. But then he’s talking about nodes, while still somehow leaving subdivision “up to the renderer” which makes me question if I understand the intent correctly.
If I do understand it correctly, then that’s a huge step backward.
Most modifiers aren’t that big a deal IMHO. It’s really just modelling with subsurfs that’s super important to get as performant as humanly possible.
And yeah, I imagine even if subsurfs will be a mesh property, we will still need a subsurfs modifier for those cases where you want it in the middle of your stack. Maybe that version could actually follow the spec too instead of the Opensubdiv limit surface shenanigans.
Actually, if they could bring back the old code, even without the fancy drawing or previews, that would be fine with me, leaving Opensubdiv for the use case where it belongs - at the end of the stack.
2 Likes
For me it reads “the performance will not be dependent on using modifiers” so you don’t need to use a Modifier with GPU acceleration to get good performance.
And obviously if they can figure it out for normal mesh editing they can figure it out for modifiers
I imagine they want to get subsurf and the OSD code away from the whole mesh > derived mesh > mesh conversion logic so as to make it easier to optimize or something. A couple of subsurf-related features (adaptive displacement and UV subdivision) already more or less require subdivision to be at the end of the stack.
That is personal speculation, not developer quotes.
It should be supported both ways actually.
Implicit subsurf including proper displacement handling should be a mesh/material property, because that’s what it basically is. But yet there’s a necessity to have the modifier (or later node) around to be used in stacks (or networks) for later processing by other modifiers. The object/material property subsurf could be treated differently, handled by OSD, no relations to a modifier stack or alike, also there’s no need for levels here, that type of subsurf should be adaptive and good.
1 Like
I hope they achieve all of them in 2020!!! This year will be amazing for blender ! It will put blender face to face against the giants without the fear to look into they’re eyes😀
I love blender
2 Likes
Is it just me, or am I missing the ‘Animation 2020’ project?
Or are all animation goals now integrated into the new 2020 goals?
Other than that, some things like full Alembic I/O support, better/fixed FBX I/O, VDB I/O and USD I/O would be awesome to get this year. Blender is not an island, and hopefully we see some things finally materialize in Blender, so exchange between various applications isn’t such a pain in the behind.
1 Like
It can’t be a step backward. Blender never had an efficient non-destructive workflow with ability to accumulate dozens of modifiers without issues.
Situation is just : Improvements for animators in object mode. No change for modelers using modifiers, for the moment.
But improvement for modelers will happen when modifiers will be transformed into nodes.
It does not make sense to lost time during the whole year to improve behavior of a modifier’s stack that is supposed to dissappear, next year or in 2 years.
We can expect a nodetree to be evaluated in a more efficient way by depsgraph than current modifier stack.
What kind of argument is that? Performance was never superb, so why not accept it being even worse, is that it? 2.79 subsurf is miles ahead of 2.8x in speed!
Does not make sense to improve modifier stack… what?! That must be why Bevel and Solidify modifiers are improving, that must be why the Weld modifier is added…
Modifiers exist, today. People are working with them, today. Performance of Subsurf in particular got ridiculously low, today. However the future nodes will work is in the future. Distant future. You don’t optimize that which does not exist.
I will in part agree that Blender team sometimes prioritizes new features of fixing/optimizing current features.
I doubt that will change anytime soon. I have similar experience with OpenCL, where blender dev team with 2.81 introduced a significant slowdown in rendering. They slightly fixed it, but currently its still over 30% slower. The bug was related to a new feature. Instead of removing it untill it wont’ have reduction in performance, they priroritized new feature.
But luckily we are not stuck with Cycles, and integrate various other renders. So not a “major” issue, but still a tad sad.
And in 2.79, there was no workbench, no overlays system etc…
I don’t deny that 2.79 subsurf could be better. But miles ahead that is an exaggeration.
Imrproving performance of the stack and allowing new tools to be part of it : that are different things.
If they had a clue about what to do, they would have done it in 2.8 betas.
If they are facing serious problem with handling of new releases of Opensubdiv library since 2 years, solution will not come up to their mind by magic.
There will dedicated task for multires and to find a solution for sculpting. If that brings things that can be applied to subsurf, that will be added to subsurf.
But if they don’t promise a super high speed subsurf ; they probably realized a long time ago ; that will be a time-consuming task and will imply to a too big refactor about too much things.
We are talking about task for this year. Another year or two, that is same scale.
What I am saying is : Does it worth it to make sergey focusing on nothing else during one half of a year ; to through everything to trashcan, 1 or 2 years, later ?
And I am not alking about improving what is not there, yet.
I am saying that in theory, by design, nodes should be faster.
Instead of checking at each step, if each modifier of pile is activated or not ; just execute connections until active node or until there is no more connection.
I don’t even… Yes, yes it is worth it, not only is it worth it, it was their (never fulfilled) goal:
Note however there are still some missing features and performance problems in the new implementation. Particularly animation playback and moving of vertices in edit mode will be improved before the final 2.80 release, to bring it back to 2.7x level.
Miles ahead isn’t an exaggeration in the slightest, it’s a fact. See this and that. 16 times slower than 2.79 OpenSubdiv, and ~50 times slower than old built-in implementation. Exaggeration?..
Now, getting back on track, what I understand from that “todo” task, is that in addition to the modifier/node, they’re thinking of adding a mesh property that would be used in lieu of placing subsurf last on the modifier stack, i.e. it will affect subdivision of the final mesh after all modifiers, similar to how Auto-Smooth, for example, splits normals of the final mesh. That is all well and good.
What I’m not sure about from reading that task is how the actual modifier/node would work in the modeling workflow. It looks like the task isn’t making any provisions for improvement there, which is to say, may be leaving it up to other work. Now if that’s the case, fine, eventually things will improve. But this part confuses me:
When we add modifier nodes support, the concept of a last modifier in the stack becomes fuzzy. Being able to pass along a subdivision surface Mesh to another node without actually subdividing is important for performance and to leave subdivision to the renderer.
What does that mean? On one hand, he’s clearly talking about using subsurf somewhere in the middle of the stack/node tree. On the other hand, how would you “pass” it further up the stack/node tree without subdividing, if further modifiers/nodes need that geometry?