Blender 3.0 OpenSubdiv development

Hi all,

I have been working on some improvements to the Blender OpenSubdiv implementation, and I am sharing some builds for anyone who would like to try it out, test it, and make sure it’s all working good. Please note that the work is not finished yet.

There are 3 main features:

GPU acceleration

This only happens if the modifier is the last in the stack. Although performance is improved, there is still one expensive operation which is done on the CPU, work is being done to port it to the GPU. For now this will only affect performance in Edit Mode when modifying the topology (e.g. changing the polygon count, or adding creases).

This will only work if your graphics driver has compute support (OpenGL 4.3 or compute ARB extension).

Here is a quick comparison moving vertices around for Suzanne at 6 levels of subdivision between Blender 2.93 and the branch (about 25x times faster for this case):

Vertex Creasing

This allows to create sharp corners:

Face Holes

A face hole is a face which influences the subdivision process but is deleted (with all its sub-faces) after the subdivision. Below is a visual representation, the left cube has a face tagged as a hole, so it looks sperical but one part is missing; while the other cube has the face deleted, so it looks more like a parabola:

All those features are available for Workbench, Eevee and Cycles (although Cycles does not have GPU acceleration support).

The builds are available for all platforms on the experimental builds donwload page, under the name “subdivision_work” (which is also the name of the development branch).

Direct download links (builds from July 14th):

Let me know if you have any issues.


With a 250000 triangles 3d scan:
Subdiv level 3. + proportional editing on: 4.2 Fps
I’m impressed !! THANKS A LOT
(Specs : AMD Ryzen 9 3900X + Rtx 2070)

I’ve got drawing issues when optimal display is turned on, and when i link duplicate objects with a subdiv modifier (with Alt + D) , the shaded surface isn’t displayed. Only the wireframe is displayed

Hi. Thank you for this!

Just in case this report has been forgotten:
there are some performance related problems still unsolved, like this one that I shared there:

In that .blend file for example, when you try Merge the selected ring > Collapse or At Center for example, Blender hangs working for a long time with a single CPU thread.
The same happens if you Collapse without Subdivision Surface modifier in Edit mode, and then you try to add Subdivision Surface modifier in Object mode.


Not a lot is supported right now in terms of display, but basic modeling from scratch (as in, creating meshes with Ngons and the like) is so much faster that master can not even compare.

I can tell this is still a WIP though, as editing complex creature meshes with many modifiers (with subdivision last in the stack) does not seem to have a serious performance boost at this time.

1 Like

Will the crease weight be animatable?

I created a model a few months back that I morphed using shape keys which involve morphing between two sets of vertex positions on a model with consistent topology. Being able to animate the edge crease as well as the vertex positions would have given another dimension to the model and would give a much greater level of control with a simpler mesh.

Unfortunately, at the moment it would appear that edge crease weights are not preserved in the shape key and cannot be key framed.

I thought Blender 3.0 was going to be Vulkan?

1 Like

This is SO promising - thank you for putting work into this! One of my main complaints about Blender is the horrific sub-d performance (speed-wise). When I was using XSI, I could have an animated character with 3 subdivisions running at 60FPS on much, much older hardware - and Blender can only run the same character at 20FPS at only 1 subdivision.

As mentioned, there are display issues and other “alpha-esque” problems, but when it does work, this works really well. Even proportional editing on a heavily subdivided mesh is very fast.

I tested a rigged character and the performance increase in Pose mode is also incredibly welcome. This will make posing and animating so much more fluid and enjoyable.

I did have a lot my scenes with sub-d’s crash this version of Blender (on file load) - but man, this is a very welcome improvement! Keep up the good work!

The other functionality is awesome, too - I miss vertex creasing from XSI … :slight_smile:

interesting - what if gpu did not support opengl 4.3 (this mean for oGL need approximately GTX 750 and up for 4.3 ver…) - modifier will work on cpu or not works at all?

  • just wondering…

my gpu’s much better than 750…
i wondering for render farm’s where some time no opengl 3.3 even no 2.1…

He stated in his post that the operation already exist for the CPU, but is slow. The GPU alternative is to accelerate it, so no OpenGL 4.3 → No acceleration → will use the CPU → Business as usual.

I can look into some of this, but this is kinda out of scope for this project. So I am not promising anything. The main performance issue I think is that the CPU code works on a per-vertex basis (for each subdivided vertex), maybe it can be made to work on multiple coordinates at the same time to improve cache coherency.

No it will not, it is implemented as a static custom data layer (edge creases are stored directly in the polygon datablock). If it is not too complicated, maybe it can be made to work more like shape keys, with multiple interpolated layers. But edge creases will have to be converted to a custom data a layer first.

I don’t think Vulkan support is quite ready yet for 3.0. Either way, this does not prevent the use of compute shaders here, we can also compile the shaders to SPIR-V.

As @stargeizer said, we simply fallback to the CPU version if it cannot be done on the GPU.


As said already, so glad you are working on this @KWD .
Is the Subdivision setting per mesh postponed?
Unlike @JoeW stated, no performance improvement when testing rigged characters here. It crashed with most of files on opening, and those that did not crash did not result in noticeable speed improvement when using subsurf (8 vs 9 fps). Anyway this is still WIP, will wait until smooth faces shading is computed.

1 Like

Yes, there is quite a lot of changes to be done for it to work, as well as handling many edge cases.


I am super happy you are working on Opensubdiv @KWD but its a complete surprise to me. This may well be on me since I haven’t been following blender development super close lately but I tried to actively find information on you starting work on OpenSubdiv and I couldn’t really find any.

I can’t find it announced on I can’t see where its part of the roadmap? I went to and if I Search on opensubdiv I get zero results. I can’t see when its supposed to be done or what its supposed to include and/or support?

Is this like an official task? I looked on to see if this branch was mentioned and I saw nothing.

When I look at and search on your name and commits I see none relating to OpenSubdiv?

When I look at I see OpenSubdiv mentioned under the modelling module with Sergey specifically assigned to it.

This matches with what I remember: Sergey actually being the one that has done most work on it in the past. I remember this video vividly from seven years ago:

Is what is mentioned at the very start of that video actually the goal this time?

"Meant to be used for realtime playback in animation software"

It specifically also states its intended purpose in the very first paragraph on

"This code path is optimized for drawing deforming surfaces with static topology at interactive framerates."

In other words, real time playback of animated characters with a few levels of subdiv active so you can actually judge how your animation looks and pose them easily.

Everything the OpenSubdiv implementation in blender currently is not.

So I guess, before I explode from happiness, what is actually happening here? Is this just some side project that can be abandoned at any moment since I can’t find any official mentioning of you working on this? Or is this actually part of the 3.0 roadmap and a hard goal for its delivery?

I am also curious wether the intention is to have OpenSubdiv meet the criteria for what it was designed for (this time)? Will we be able to have interactive posing and 24fps playback for our animated characters at close to render level subdivision? Is this the actual goal this time?

If I have missed the official announcements or the page where I can follow progress on this official 3.0 goal I’d love to hear where to go so I can follow the progress closely. I can’t imagine one thread on blender artists is the official place to get info for this branch that is so important and has been the request of so many blender users every since the first implementation of OpenSubdiv.

Its great to see you working on this, I’ve downloaded the build and will give it a spin shortly, but it would be fantastic if you could answer my questions. :+1: Thanks


D10145: Subdivision: add support for vertex creasing, as far as I understand performance improvement is part of this patch (which is apparently related to rendering, not modeling). And also T68891: Subdivision surface settings part of the Mesh.
You can also look at his weekly reports


Well this message is rather long, but my reply will be short.

  • Yes this a target for Blender 3.0, although it is not officially on some roadmap.
  • I don’t think working on this render specific feature is worth me being added to the list of developers for the modeling side of OpenSubDiv in Blender (along Sergey).
  • This is not a side project, I am still paid to be here (via the development fund).
  • To add to what @Garek said, the development can also be followed via the weekly rendering meetings.
  • The branch is called subdivision_work, as metioned in my first post.

That’s also the goal here.


Thanks for replying, I don’t mind short to the point messages. :laughing: Ill quickly go through your replies in order (forgive me for not quoting).

Weird to not see it as an official target. I’m well aware things can (and will) change and targets being on roadmaps are no guarantees of them being met but at least it shows a certain intent.

Unless I’m mistaken (which I could be) GPU acceleration wasn’t present before (at least not for 2.8/2.9) The amount of likes and views of this topic should give you somewhat an idea of its desirability. While I’m not arguing you should be added to the list of developers I’m certain you can somewhat understand my surprise to see you being the one to implement this. :slight_smile:

Yes @Garek already pointed me in the right direction. I quickly scanned the commits by topic looking for opensubdiv. I clearly should have spend a little more time or used the search. At least I know where to look for updates now under rendering. Although its now quite unclear to me what your scope is for OpenSubdiv and whether you will actually “bring it home” or not. It seems it has multiple owners at this point.

I knew what branch it was, your links helped me to find it easily and download it so thats all good. My point was that its not mentioned, at all, on I think this branch deserves a little more attention/celebration. As you have yourself pointed out you’d like people to test it thoroughly at some point as well.

The “also” surprises me. From reading what OpenSubdiv is about that is its main goal. I feel how blender has treated OpenSubdiv is a bit in reverse order. It probably has to do with compatibility with existing assets that were modelled with OpenSubdiv from other apps or something to that extend (im open to being corrected). I am very much looking forward to seeing OpenSubdiv in blender grow into its purpose for animation.

Thats all. Thanks for clarifying and your work so far! :heart:

The strange part is the Blender devs. were well on their way to getting the implementation right in 2.79 (where deformation was quite fast), then somehow created a new implementation that was a big performance downgrade from the original one. At that point I at times wondered if Dreamworks should’ve never made the library compatible with the GPL, because literally every other software including DAZ saw their products get a boost from it (this also includes a bevy of more obscure 3D products like Japan’s Shade 3D).

Fortunately we can let that fade into the past, because the bottom line is Blender 3.0 will end up having higher subdivision performance across the board compared to 2.79, which then eliminates the last notable regression in 2.8 onward.

1 Like

Did a little bit of playing around and the speed up is already quite significant. I tested it with a little walkcycle I made with the Nelb character. Its free and you can get the updated version (2020) at:

The walk cycle:

With 2.93.0 I can only set the subdiv level at 1. At 2 it drops well below 24fps (~15fps).

With the OpenSubdiv branch I can go to level 4 and it will still play at 24fps!

While I feel you would be fine with subdiv level 3 (or perhaps even 2) for judging animation work most of the time its very promising to see it perform this well with a simple mesh. It makes me excited to try this with more complex characters who’s control cages are more detailed.

For the people who want to try this out. There are obviously some things that don’t work this early on. the flatshading is known but there is also the fact material assignments get all messed up (I think everything goes back to 1 material slot or something to that extend).

Other then that it seems to work fine. If your mesh seems to explode when you open old files just delete the Subsuf modifier and add it again. This solved any issues I had.

Have fun everyone! :slight_smile:


@KWD Is there any date for these optimization to be completed?

If it can be useful to anyone, since Blender 2.91 there is a useful toggle in the Subdivision modifier to improve performances: “Use Limit Surface”.

Quick benchmark with a fully rigged character:
Enabled, Quality level 3 (default): 10 fps
Enabled, Quality level 1: 14 fps
Disabled: 20 fps

Yup, it reaches 20 fps, that is starting to be interesting for realtime performances.
This only changes the smoothness output, then if you don’t need perfect smoothness this is totally acceptable.
With @KWD GPU optimizations, this could reach lightspeed!