patch on google drive? why not submit it on the dev site?
1 Like
I want to know if it has any chance of being accepted before I put more work into it. Thatâs why I want to know if there are any fundamental reasons, why more opensubdiv capabilities arenât exposed to the user. I admit I donât have âbig pictureâ.
2 Likes
There are several things which made us to switch to the limit surface (what OpenSubdiv calls adaptive refinement).
From overall system overview we do need to have similar behavior of multiresolution modifier and subdivision surface modifier. From multiresolution modifier point of view using limit surface is what allowed to eliminate sculpting artifacts when changing preview level (this comes from the fact that tangent space used for displacement does not depend on the subdivision level).
There is also LANPR which, to my knowledge, uses OpenSubdiv to get derivatives. First derivatives are not accurate when using uniform refinment, which makes second order derivatives not usable in practice.
One thing to keep in mind is that having all modules using same basement eliminates unpredictable from user perspective questions like why feature A does not match feature B exactly (although from an intuitive level they are doing similar things).
From GPU integration point of view (which we do want to bring back, and which is in our roadmap) some features are either impossible to have or arr every expensive. For example, smooth normals are very expensive to calculate on GPU because they depend on vertex neighborhood, which is not (easily) accessible from GPU shader. Other example is that it is not possible to have screen-space adaptive subdivision.
5 Likes
From a user perspective I just need to be sure to have the same predictable result in Blender when switching between applications. Unlike other things that are more on the âannoyanceâ side this one is actually a grave problem that needs to be sorted out. Would be really good to know if this is going to be changed and has priority.
3 Likes
From an engineering point of view, everything is clear.
From an artistic point of view, the behavior that is present now makes the Blender in some cases completely unsuitable for use in the studio pipeline (in a certain number of cases, perhaps specifically in my studio, but nevertheless).
I think we would all like to know if this issue is considered significant for developers and if there are plans to do something about it in the future.
5 Likes
Those are valid points, and, I think, good arguments, for going this route: https://developer.blender.org/T68891.
But it neglects use case for subdivision as modelling tool where applying subdiv levels one by one and adding detail is valid workflow, and this workflow is disrupted by treating tesselated limit surface of one modifier as input to another, you get this âvolume lossâ problem. Allowing uniform subdivision (aka finite number of Catmull-Clark iteration) solves this by keeping (by definition, ignoring edits) limit surface in place.
So itâs not question of using solely one or other method, they both have itâs uses. Also why not expose boundary interpolation mode and Chaikin rule in context of modelling? And I agree that keeping it user friendly may be a challenge.
BTW For multires volume loss is also visible when pressing subdivide first time when mesh jumps from coarse to limit surface, but in sculpting workflow starting from 100-1000s polygon base mesh this is probably less of an issue, and given what you said may not be solvable.
7 Likes
Hello
Thank you for this patch!
But it failed for blender-2.9*
With 2.8* patching susses!
Can you update patch for 2.9*?
Yes, when I have some spare time I intend to prepare patch for review by blender devs.
Reason why this patch stopped working is that with introduction of modifier drag and drop feature, modifier ui code got a complete rewrite, for eg. mod panels are no longer created in python but in c, so parts of the code this patch is against are literally no longer there.
4 Likes
ok, cool
hope blender devs add your usefull patch to upstream!
1 Like
any news on this? 
Iâve update the code, will submit patch soon.
7 Likes
thanks!
finger crossed 
2 Likes
Hi guys, sorry to bother you again, but can we have an updated version of this patch?
thanks~~
4 Likes
If the two patches (D8485, D8413) have chance to land before bcon1 ends, there is no need for new build. If not, i will try and make updated build.
@brecht?
2 Likes
I really hope it will be fixed soon. Interoperability is no issue for us since we only use blender. Thing is this change broke compatibility with all blender subsurf models made before 2.8! Huge regression. 
5 Likes
Non-adaptive subdivision (https://developer.blender.org/D8413) marked as âready to landâ
12 Likes
Brecht committed changes to master.
https://developer.blender.org/rB53f20b940a1e520e131b8bb31cf0529ed4d30f9e
https://developer.blender.org/rB6070f92ab94be7bd1d6729f178d71c71c4245fbb
15 Likes
You are my hero! Thank you for your efforts!
4 Likes