Why such a strong subdivision change?
Red - Maya
White - Blender
Violet - Zbrush
Files
1 Like
In your file Maya and Zbrush one aren’t using limit surface calculation, and Blender one does.
Hello,
I have a 2 simple questions:
-
What is Quality level for?
From the docs
“How precisely the vertices are positioned (relatively to their theoretical position of an infinitely subdivided mesh), can be lowered to get a better performance.”
So it cause for performance issue if it enabled and it distort subdivision in non industry shape… -
If Quality not industry standard, why it Enabled by Default? Maybe it need to be disabled by default to not mislead newcomers?
It would be best, if you go and take a look at OpenSubdiv documentation.
What osd does, it calculates limit surface as a set of bicubic patches, this is all fine for regions where there are only quads and 4 edge vertices, so in those regions you have pretty much one patch for every face of coarse mesh. It starts to get harder when you have 3 or 5+ vertices, around those, it subdivides patches to get quad topology, and quality is level of this subdivision. That’s why its called feature adaptive subdivision, features meaning those extraordinary vertices around which there is actual subdivision
If limit surface is disabled, all gets subdivided into bilinear patches, and separate quality and levels control doesn’t make sense. At the code level Blender’s quality parameter is hooked to OSD levels.
This is also the reason why quality has such impact on mesh with creased edges, if it’s to low, there might be not enough patches to represent surface accurately.
1 Like
One more thing that bother me, UV Smooth.
No difference between option change.
Is it work as intended? Or should the UV be smoothed as geometry in 3d view with some of this parameters?
Added:
it only can be seen by enabling this option
but if you have complex mesh it become mess…
As far as I can tell, it does. Blender doesn’t really have anything to do with this, it just sets up OSD options (and not all of them are exposed in UI) and gets whatever OSD calculates.
This was most important reason to use OSD, to not have to maintain algorithm implementation, but to use industry standard instead.
2 Likes
to see the difference of the UVs you have to display the modification in the uv editor, there is an option somewhere.
Sorry for late response.
What you are asking about, is, in OpenSubdiv terminology, Face Varying Data (FVars) interpolation modes. It’s quite easy to do in the middle of the mesh, but issues start to arise on the boundaries (and this, I think, is root cause of your problem), so OSD has six modes controling this, Blender only exposes 3 of them (UV drop down). I can, somewhere next week, prepare a build exposing them all for testing, from code point of view enabling them is trivial.
Issues with this, are potential bugs caused by different ways OSD interprets FVar input buffers, this was main problem with disabling limit surface. And second issue is, if there are to be exposed, I don’t want to be the one having to figure out artist-friendly labels and descriptions for those different modes 
1 Like
The option to enable access to these other modes could be kept in the Experimental tab for now if bugs and names are a concern.
1 Like
If you use the Crease functionality to assign sharpness to edges, a higher Quality value will yield a better result.
1 Like
Thanks to point me for this.
Made a comparison with other apps.
Cube with OpenSubdiv level 5 and Crease top Edges on 0.3:
- Blender 2.90 or 2.91 no matter on or off Use Limit Surface
- Max
- Modo
So blender has different, or I’m doing something wrong?
P.S. need I to hide this pictures?
1 Like
Interesting. It seems that Blender’s Crease value deviates from the other OSD implementations. I’ve noticed before that the crease strength increase does not seem to be linear in Blender.
What happens if you double the Quality to 6 in the Subdiv modifier?
Blender squares sharpness value, before passing it to OSD. Try using sqrt(0.3) = 0.547 in Blender, and see if it matches.
1 Like
I think I found what is problem.
Crease did not respect SDS level.
So if we have Crease 0.3 and SDS level 3 it should look like this
Sharp Edges, so normal OpenSubdiv calculate Edges with 0.3 crease and SDS level 3 as sharp.
If SDS level would be 3 and we use crease more then 0.3 nothing happen cos it calculate as 100% sharp for this case.
If SDS level would be 5 then sharp edges start from 0.5 crease.
I hope you understand me…
Blender have a bug or wrong calculation in this situation.
Yes, it match.
But should it be 0.547 or as other apps 0.3 for SDS level 5?
From my point of view it should look like OpenSubdiv standard values.
No idea, the fact is that Blender does additional manipulation on the value, and other apps apparently do not.
As for why Blender does it, I have a theory. Blender internally stores sharpness as 8 bit unsigned interger, so you have only 256 distinct values. Taking square has effect similar to gamma correction, it gives you more resolution on low end.
But I need to ask @sergey about this.
2 Likes
I exported as FBX with 0.547 and import to Modo, and it match 0.3 creases in modo.
But this is not acceptable because if I think I crease to 0.3 in blender I expect to see 0.3 in other apps…
At the moment I model completely in Blender, and would be use other apps for converting for customers.
But I see that I need to recalculate all my creased edges in blender to match in other apps…
2 Likes
