I was in the middle of a comparison and I found that Blender subdivide the mesh in a different way compared to other softwares, like ZBrush and Maya. It looks like blender is using a different algorithm (?)
Since at work I often go back and forth from other packages it would be cool if the subidivsion surface model was the same of the other software.
I think they need to inplement subdiv as all the other software do.
subdivision surface is so a common and standard technique that it should give the same exact effect across multiple app, in this case Blender is the one that behave differently (considering the standard)
low poly mesh made in blender >
zbrush for detailing >
bake displacement >
aplly displacement to blender, bjt the result is different form the zbush one.
This is a huge problem if the production is not entirely blender based.
the old good 2.7x produced just fine results.
Of course I reported this as a bug, but they closed it as invalid, even this is a clear regression.
Maya should be using OpenSubDiv by default now as well in recent versions. 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.
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.
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.
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.
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 “subdivision” is iterative. Applying the subdivision of level 2 is the same as applying the subdivision of level 1 twice.
The positions of the vertexes get closer and closer to the limit surface, but they never reach it. Typically, the surface shrinks with each iteration. The smoother the surface, the smaler this shrinking effect. So the change in size is less for each further iteration.
Each iteration (except first) multiplies the dencity of the subdivided surface by 4. Each quad turns into 4 after each level. For example, level 0 - 1 quad; level 1 - 4 quads; level 3 - 16 quads, level 4 - 64 quads, …
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:
The vertices of the tessellated surface are always on the limit surface. The positions of the corresponding vertices remain stable regardless of the level of tesselation. The surface does not shrink (well, actually, in a sence, it shrinks once, when going from the control cage to the tesselated surface)
The tesselation is not iterative. Tesselation of level 2 is not the same as applying the tesselation of level 1 twice.
The density of the tesselated surface does not have to be controlled by the tesselation level. The number quads resulting from a quad on a limit surface does not have to be a power of 4. Nothing prohibits from, say, tesselating each quad into 9 (each edge into 3) or 25 (each edge into 5).
The density does not have to be uniform (different quads of the control cage can have different density on the tesselated surface).
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.
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.