Maya should be using OpenSubDiv by default now as well in recent versions[1]. However, there is a note in their documentation about non-manifold meshes like Suzanne. Strange that it would still apply in this day and age[2].
[1] OpenSubdiv is the default subdivision method when you smooth a mesh using Mesh > Smooth or when you create a subdiv proxy.
[2] Maya automatically defaults to Maya Catmull-Clark for meshes that contain non-manifold components.
Blender will indeed match other apps and renderers that use OpenSubdiv or similar subdivision surface algorithm.
Part of the reason Pixar released OpenSubdiv was to get a common standard across various application, and Blender is now following that. It may not match the specific apps and settings you tested, but it will match others.
Hi @brecht
thanks for the reply.
So it is something planned for the future?
I made a comparison with the 2 most used software in the industry (maya and zbrush), so since Blender is going in the “industry standard” direction and since blender 2.79 behavied just fine I was wondering why now is so different.
Here another example, as you can see the difference is huge in 2.8.
those are the default settings in maya (the ones I used for the comparison, that match with b2.79 and zbrush))
Blender always positions vertices on the limit surface, what you get when you would subdivide the surface an infinite number of times. I think this is closer to what you would get with adaptive subdivision in the Maya viewport and USD viewers, or adaptive subdivision in a renderer like Arnold or PRMan.
It means that your vertex position (and the displacement on it) stay the same regardless of the subdivision level, which by itself is generally a good thing if you intend to use adaptive subdivision and not bake a displacement map that is only valid for one particular subdivision level.
ZBrush may not be able to bake for that case, or maybe it’s a matter of tweaking settings, I’m not sure. We could consider supporting the subdivision where vertex positions change at every subdivision level, but this will not work for adaptive subdivision in Cycles or OpenSubdiv GPU acceleration.
From looking at this: http://graphics.pixar.com/opensubdiv/docs/osd_overview.html#refinement it seems to be possible to evaluate control cage on GPU.
I think the “adaptive” word is a bit overloaded as it means different things in Cycles and in OSD docs.
The OpenSubdiv manual uses terms “subdivision” and “tesselation” to address these differences:
http://graphics.pixar.com/opensubdiv/docs/subdivision_surfaces.html#subdivision-versus-tessellation
The “subdivision” is the Catmull-Clark algorithm as it is. It is an iterative process. On each step, each quad of a control cage is subdivided into 4 and the resulting surface is smoothed out. And then the same process is repeated while using the result of the previous step as the control surface for the new one.
Each step brings the surface closer and closer to the “limit surface”, but it is never reached.
Key factors here:
The “tessellation” is acheived by representing the limit surface of the Catmull-Clark algorithm as a set of spline surface patches (in trivial case, each quad converges to a B-spline patch). And positions of points on these patches can be computed directly, without iterative refinement of the whole cage.
Key factors here:
Most of the 3d software (including Blender up to 2.7) uses “subdivision” in their “subdivision surface” modifiers.
The blender 2.8, for some reason, decided to use what essentially a form of “tesselation”.
In general, the “subdivision” and its iterative nature is useful during modeling. For example in workflows that generate a base shape using a coarse control cage, then apply a couple of iterations of the subdivision surface and then modify the resulting topology to model the finer details.
(The current Blender’s multires does not facilitate such workflows since many refinements require changes in topology)
The “tesselation” is useful when applied to a final control cage (when subdivision surface is used purely for controlling the level of detail of the resulting surface), since it produces more sable results (no shrinking). This includes all forms of adaptive subdivision, obviously.
In my opinion, the “subdivision” (pre 2.8 version of subdivision surface) must return to Blender.
There must be an option to disable snapping to limit surface.
It is completely ok if it comes at the cost of disabling the GPU acceleration for modifiers that have snapping to limit surface disabled. Acceleration is never needed in such cases anyway.
Excellent summary and explanation. This is a really big compatibility problem when working in a multi-tool pipeline. Blender is behaving in a nonstandard way.
Great description, I allowed myself to link to it in patch enabling back iterative subdivision https://developer.blender.org/D8413
Brecht committed changes to master.
https://developer.blender.org/rB53f20b940a1e520e131b8bb31cf0529ed4d30f9e
https://developer.blender.org/rB6070f92ab94be7bd1d6729f178d71c71c4245fbb
I’m so happy I wanna cry! thank you, thank you, thank you!
You really saved my ass.
It looks like that the volume loss is still present when the subdiv is applied multiple time like in picture.
The black Suzanne has the subdiv modifer applied once at level 3, the red Suzanne has three subdiv modifers at 1.
That may be actual OpenSubdiv bug, I will need to look into this. It may be much more difficult to track
Also, I checked against 2.79, and single modifier result for 3 level is the same to the point of z-fighting. Something strange is going on with stacking.
yeah…
Anyway now it works as expected at least with one subdivision modifier 
thanks!
Try comparing 2 modifiers with level 2 with one with level 4 …
it matches perfectly. how weird!
Isn’t it? 
For some reason blender forces OpenSubdiv internal level (aka ‘Quality’) to be at least 2 when there are non-quads in the mesh, on limit surface its fine, but for regular subdivision it makes 1st level wrong.
I created a fix for that, and asked Sergey for comment.
https://developer.blender.org/D9076
very cool! thanks again man.
