Subdivision behaviour is different than in any other software causing compatibility issues

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”.


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.


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.


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.


Those are valid points, and, I think, good arguments, for going this route:
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.


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.


ok, cool
hope blender devs add your usefull patch to upstream!

1 Like

any news on this? :slight_smile:

I’ve update the code, will submit patch soon.


finger crossed :smiley:



Boundary interpolation option seems good to go:


Hi guys, sorry to bother you again, but can we have an updated version of this patch?


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.


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. :confused:


Non-adaptive subdivision ( marked as ‘ready to land’


Brecht committed changes to master.

:fireworks: :fireworks: :fireworks:


You are my hero! Thank you for your efforts!