OpenSubdiv issues with large and complex meshes


I’ve filed a bug report on this issue, but wanted to elaborate a little and thought this might be a good place to do so.

When using modifiers, I tend to use subdivision surfaces more than once in the stack.
Since the old subdiv code was removed, I’m having a lot of issues trying to do certain things than were no problem in 2.79 without using OpenSubdiv.

I have a basic example that can be replicated really easy and the difference in performance is quite staggering.

If you create Monkey model and add a Subsurf set to 4 subdivisions, then add a Wireframe and add another Subsurf to smooth it, this is the difference:

  • Blender 2.79 (without OpenSubdiv): ~5 seconds, ~2GB RAM usage
  • Blender 2.79 (with OpenSubdiv): ~15 seconds, ~3.5GB RAM usage
  • Blender 2.80 (with OpenSubdiv): ~3m, 52s, ~64GB RAM usage

Would there be an option to bring back the old way of subdividing a separate option on the modifier? I understand OpenSubdiv is great for all kinds of things but right now a lot of modifier workflows I use are completely hampered by new defaults. The faster, older one is enough for quick subdivs in the stack and works great on more complex meshes or weird geometry.

I’ve attached two files so you can test it yourself, might be worth getting benchmarks from a few people to eliminate it being something specific to my system.
All you need to do is turn on the second Subsurf in the modifier stack and keep an eye on your system resources.

2.79 File | 2.80 File

I have a more extreme example for testing as well. This is a static mesh as an alembic file (~250MB) that you can import, but be warned (!) it’s quite heavy. (~8Mil Polys)
This is just to illustrate what happens when really pushing Blender with this kind of workflow, but might be an interesting litmus test.

  • 2.79 without OpenSubdiv takes a while but uses about 30GB of RAM and handles it fine.
  • Both 2.79 with OpenSubdiv and 2.80 max out 64GB RAM + 64GB swap on my machine and crash out without ever finishing.

I’m all for cleaning up the codebase to make the load on developers easier to maintain, but there’s an extreme loss of performance here for something as widely used as a Subsurf modifier.


As you illustrated yourself, OpenSubdiv was faster and more efficient in 2.79 and earlier. Therefore it follows that the slow speed and high memory usage don’t have to be so severe with OpenSubdiv - it just needs to be optimised.


True, but some things just aren’t possible anymore with OpenSubdiv, it would be a shame to lose funtionality for high polycounts or odd-shaped geometry.

Would it be possible to make a compromise and keep the old way in the modifier by adding a “Legacy” option (Like the OpenSubdiv" tick in 2.79, or make it three buttons like OpenSubdiv | Catmull-Clark | Simple?

I just feel that replacing the current solution with something that, even when optimized, still runs three times slower and uses double the ram isn’t the best way forward.

Don’t get me wrong, I’m not hating on the advantages that the new stuff brings, I welcome them. But completely replacing something that is still incredibly useful in situations where the new tech fails seems like a bit of a step back to me is all.


@Mantissa also demonstrated the reverse, namely that Opensubdiv takes twice the amount of memory, no matter which Branch of Blender. That seems like a potentially massive problem that shouldn’t be taken lightly, and until optimisation’s effect is proven, it’s okay to want a stable, proven algorithm to be available as well.
I’m all for making Blender’s codebase lean and easier to manage, but at the moment this seems like a serious regression!


Hi everybody, so glad to see that I’m not the only one having performance issues with the new Subdivision Surface. I created a simple script for compare the computing time in Blender 2.79b and Blender 2.80, and the results are:

  • Blender 2.79b: 0.13sec
  • Blender 2.80: 4.49sec

This is the script:


Just ran it myself, similar results.

2.79: 0.12s
2.80: 2.49s


i heard not long ago that some studios dropped the use of Opensubdiv because it might be fast ish on the GPU but on the cpu it’s sloooooow.


I’ve submitted a bug in regards to OpenSubDiv as well. Seems to do pretty well with all-quad meshes, but when you have triangles or n-gons, it becomes really, really, slow. I’m hoping this gets remedied as one of my major complaints about Blender is how slow it is when manipulating and animating sub-div meshes (yes, even 2.79 was much slower than I am used to). In Softimage, I could have a fairly complex, rigged mesh, running an animation at 60 fps with two subdivisions on the mesh. The same mesh in Blender (2.79 and 2.8) barely runs 24 FPS with no subdivisions and drops to the 4-6 FPS range with a subdivision of one.


So, umm, when is this fabled optimization work scheduled to begin?

After all, the old viewport was replaced because it was dog-slow (with subsurfs and edit mode in general being the worst offenders). I’m very anxious to see some kind of speedup compared to 2.79.


I’ve never fully documented …
so I ask some of you…
classic blender subdivision surface vrs OpenSubDiv …
What are the pros and cons between the two technologies? …
Someone who is better informed can make me a quick comparison list?

  • OpenSubdiv is an industry standard, meaning that results will look identical in all apps that use it, when you transfer subdivided objects between apps
  • OpenSubdiv supports improved creasing support compared to the old method Blender used.
  • OpenSubdiv supports vertex creasing too
  • OpenSubdiv supports GPU tesselation. This can make it orders of magnitude faster, making it possible to play back fully subdivided and animated characters in real-time.

The last item is, to me at least, the most exciting thing about it. It means animators can see the deformations in final subdivided form, without paying a big penalty in playback speed.


well …
I hope these benefits are absorbed by blender 2.8 as soon as possible, because as is known, the situation is disappointing and a bit funny.

And going logically, achieving these standards should be in the priorities.