Yeah, I think i read somewhere that there is an idea to make “subdivision surface” a mesh property instead of an object modifier.
1 Like
I’m also not clear on what they mean here. It doesn’t make much sense to me.
Maybe some kind of instancing/array scenario? But then the renderer would also need to implement modifiers, which would be nonsense.
Blender has often a non realistic communication. The whole 2.80 release was supposed to be feature complete with all 2.79 feature supported.
We always knew that will not be the case because of a deadline to release 2.80.
Now, release cycle is one new release every 3 months. We know that things that we are lacking will still not be there in 2.85.
And the same way, anticipated targets for 2015 are still targets for 2020, we know that there is still a chance that what was announced , will not be done this year.
I don’t wish that. Devs are more serious, nowadays.
But we should doubt that Bastien or Sybren will be able to work Asset Browser same year that they will work on Library Overrides and USD.
Although Brecht is fast and there was already work done in a GSOC about Volume object, we should doubt that he will assimilate feedback about that and finish Hair object, the same year.
About improvements relative to viewport (fast playback, scene editing in object mode and edit mode for high poly meshes), we should doubt that everything could be reviewed by Clément and Jereon and ready to land, this year.
It is sure that devs will work on all these tasks in 2020. But that does not mean that, for all these tasks, benefits for user will end-up in official release of Blender, before end of 2020.
In posted links, sergey starts to explain that is not fair to compare 2.79 Opensubdiv working on GPU and 2.8 Opensubdiv working on CPU.
Then, he find that there were threading issues and provided a patch in november applied before 2.81 release.
That did not fix everything. But what is sure is that current situation is not as bad as in 2019.
The task is about making subdivision surface a mesh property executed by GPU.
So, changing mesh property should have an impact whatever modifier nodetree is applied to it.
The paragraph just reveals that they don’t know how to do it, for the moment.
Their interrogation is not really what should produce a subsurf node modifier.
The question is how you avoid to lock mesh property in Properties Editor by adding modifier nodes to mesh in a Modifiers node editor.
Or in other words, how you structure depsgraph to make it possible to evaluate this specific mesh property after nodetree ?
I like the fact that Dalai is starting a priority scale on projects …
There are projects that have concrete priority, and they are to dissolve the known problems even before inserting new great features. Bravo Dalai, Excellent Initiative.
“Is it worth it?”
“Yes, and they wanted that.”
“But it’s unrealistic because it always was.”
About what Sergey “starts to explain”… Those are implementation details and of no concern to users. Users suffer from low performance. Much lower than it was in 2.79. That’s the end of it. Be it due to incomplete implementation, Brexit, or insufficient amount of virgins sacrificed under blood moon is to us irrelevant. Users don’t (and shouldn’t) care how it works.
Of course the subject is complex and there are multiple causes of reduced performance, and not everything can be fixed right away. But I’m sorry, @zeauro, you simply can’t argue against it being much worse than it was, nor can you justify that with new bells and whistles such as workbench or overlays. But if you’re content to live with it until the nodes arrive (which isn’t that likely to happen two years from now), that’s your choice.
2 Likes
it would be interesting if the multires and subsurf modifiers managed to be unified.
After all they have similar utilities …
Actually Both currently have problems,
Therefore a good developer could work at least better for this unification and also to take the most of some peculiarities of the opensubdiv libraries.
(the video is at the minute of what I want to highlight)
1 Like
Yup. People always wanted OpenSubdiv because it is supposed to be fast. That was its killer feature. If that feature can’t be delivered, they never should have bothered with it.
And that was in the 2.7x days, when subsurfs were “fast”. Because 2.7x “fast” was still painfully slow.
3 Likes
I am obviously aware of the problems, my reasoning was more like:
Since the acceleration opensudiv on GPU (the implementation) and the multires modifier currently have problems that must be solved, it would be strategic to consider unifying the two modifiers (and as far as possible the mesh-drawing system in general) at “the core level rewriting from scratch” since however the features are similar trying to take the best of the opesubdiv libraries on GPU
Not just you, I noticed that too and asked about it under the article. And, no, not all animation goals are integrated. E.g. editable motion trails, streamlined and intuitive animation layers, etc.
I sincerely hope the effort isn’t dropped, but with the sheer amount of things they want to get done, I don’t know if Animation 2020 is something we can hope for.
I think it is obvious that at the moment the priorities are those of stability and performance, and simply the discussion on animation 2020 has not yet started, this does not exclude that someone is not starting to collect information and putting up a project that could still start in parallel, perhaps as a new code quest ??
Right, they may surprise us with a new Code Quest or something. But, as much as I’ve been waiting for Animation 2020, I think the smarter thing for Blender might be to focus their manpower on stability and performance.
Or we get another significant funding and Blender foundation gets to hire people just for Animation 2020. =D
As I mentioned, most of the speed regression is initialization and mesh > derived mesh conversion. The latter especially appears to use very primitive logic because the whole process is redone whenever a vertex moves.
It’s much like what we learned about why editmode (without modifiers) can be slow with high-density meshes, many tools rely on a very basic loop that goes through every vertex to find the ones selected. The Blender code can be an enigma in this case, it’s very smart and sophisticated in some areas while it borders on a beginner level in others.
3 Likes
this confirms my opinion to take advantage of Open Subdiv libraries on GPU and take more pigeons with one stone
Code Quest was before they were getting massive donations and sponsors. At this point they able to have at least 18 devs working full time…
Which makes the absence of older but announced projects, -and- the slow integration of proper industry standards a bit worrisome… Even Pablo giggled at the idea of adding things like UDIM to Blender in one of his last videos. This worries me, as they see Blender as a one-fits-all shop. It isn’t, and it never will be.
With 18 devs, some of them should be working full time on things like working I/O, a enhanced outliner, viewport speed and things like UDIM. You know… The things people expect to have when they switch to Blender. If not, it will take a long time to see Blender becoming a real alternative for apps like Maya, Max and Cinema. Houdini is it’s own powerhouse.
1 Like
UDIM is close to done and dusted one of the bigger things left outstanding is probably baking but what is in the 2.82 builds is quiet good for what it is.
2 Likes
Er… UDIM will be in 2.82 and it fully supports things like Eevee/Workbench, Cycles, and painting across tiles.
In addition, there’s still movement on making sure industry veterans can be eased into Blender, as seen by a number of recent commits regarding the industry-compatible keymap.
2 Likes
Yes, I know UDIM will be in 2.82, but the fact it took them ages to do so is not a good sign.
The same that import/export on FBX or Alembix is still not fully featured or bugfree.
The fact that another developer fixed some of the outstanding issues in the Outliner, not the guys at BF etc.
Again, I really would like them to stop adding new features for a release or two, and start fixing all the big bugs and outstanding requests on some of the things everybody else is already enjoying.
pablo more or less said in his video the devs don’t like ’ bug duty’ , but rather spend their time on creating new stuff. I understand that, but it feels like nobody is telling them ‘enough is enough, and start fixing bugs now’ 
Isn’t that part of the reason why they have been making an effort to get more volunteer developers on board (by way of devtalk and other means)? Blender is an Open Source Project, and for it to be truly robust you don’t want nearly all development coming from the core team on paid contracts (though the size of Blender’s team makes that harder to achieve).
Community-powered bugfixing, for instance, has been working extremely well for Godot (where there’s been hundreds of fixes from hundreds of contributors).
That said, the meeting notes state that a greater focus on bugfixes will come with phase 2 of the tracker curfew (which starts the moment all tracker entries are triaged).
2 Likes
core functionality should always come from the base team, not let this be done by volunteer devs.
At least imho…
If someone has to stop due to time issues, certain parts will just stall for long periods of time.
That’s why things like I/O, performance, outliner, asset manager etc. should be core functionality dev wise.
Volunteers can build on that.
But I’ll stop now