Subdivision surface in Blender 2.8 behave different compared to Maya and ZBrush

Hi people.

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.

ps: in blender 2.79 it was correct.


1 Like

The only project that I know of that would solve this problem is a OpenMeshEffects but it is in its a very early stage and is not ready for production.

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.


1 Like

I don’t know what subdivision algorithm Zbrush and maya use but I know blender uses opensubdiv

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.

1 Like

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.

1 Like

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))

1 Like

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

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.


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


Brecht committed changes to master.


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

1 Like

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.

1 Like

Anyway now it works as expected at least with one subdivision modifier :smiley:


Try comparing 2 modifiers with level 2 with one with level 4 …

it matches perfectly. how weird! :smiley: