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.

18 Likes

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.

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

4 Likes

@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!

4 Likes

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: http://alessandrozomparelli.com/Share/subdivision_speed_test.py

2 Likes

Just ran it myself, similar results.

2.79: 0.12s
2.80: 2.49s

1 Like

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.

4 Likes

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.

Any update on this? Having subdivision speeds being 10 times slower is kinda a downer when modelling anything or animating.

Speed aside, I want to talk about the shape.

The current Opensubdiv is great at calculating the vertices at their final boundary position even at low levels of subdivision. Which is great and I didn’t know I needed it. But sometimes I’m modelling applying multiple subdivision levels, or using several Subdivisions modifiers. In that sense, the mesh becomes thinner and thinner.

To illustrate the difference, the mesh in magenta is uses 3 opensubdiv modifiers with 1 level each, while the transparent green mesh uses 1 opensubdiv modifier with 3 levels. In 2.79 both methods would give the same result. It would be nice to have the option to use the old boundary calculation back

6 Likes

No, as a modifier, OpenSubdiv is fine. What you’d really want is a separate Catmul-Clark subdiv operator for edit mode that strictly adheres to the original algorithm. It should also be able to handle partial subdivision of a mesh, which would make it ideal for this kind of modelling.

There are times when multiple subdivision modifiers is useful too, with other modifiers in the middle. It’s not like shapes would be that much different but still, it would nag me on the back of the head to know the shape is not quite right

Interested if there’s any updates regarding this issue?

Why is every reply: “OpenSubdiv is faster and better” when obviously and provably it’s slower and worse for some people?

Count me in the slower/worse camp. I literally have to turn off subdiv everytime I do anything serious with my model. Sometimes I forget to turn it off, and wonder why the UI is freezing up. Oh yeah. Subdiv. Turn that off and I can work again.

I’m using an extremely modern (2017) high-dollar iMac, so I would expect something that used to take a couple hundred milliseconds to take at most a second… not 4-8 seconds.

Is anyone even trying to optimise this code? Or are we just on our own here? Can I pay someone to optimise it? I’d drop a couple hundred bucks on it if someone who has familiarity with the code would dig into it.

Even just give me a hint how to start. I’ll do it myself. I’ve slung some C++ in my day.

1 Like

THe idea after OpenSubD is that devs doesn’t need to optimize because the took a external library. BUt with this performance problems I preffer to have the option to use the old system, really better.

Actually the performance of my old quad core, 7 years old, is better than the new ryzen 3700x… and this problem is extended to undo (with any subdivide mesh the undo operation is hundreds of times slower.)

Could be good a official response about this feature that so many problems are creating

1 Like

Same here. On all counts.

From my POV, definitely a checkbox on the Subdiv modifier to say: “Use old broken ugly horrible terrible really you shouldn’t use this Subdiv library from Blender 2.79” would be great. I would totally check that checkbox, and feel fine about it. Because it’s either that or…

  1. Copy the base mesh somewhere else, with all its vertex colours, modifier stack, etc.
  2. Delete the armature modifier from the copied base mesh (just so it doesn’t look weird)
  3. Apply the subdiv on the uncopied mesh
  4. Re-parent the subdiv-applied mesh to the armature
  5. Work with the mesh
  6. Discover a minor tweak I need to do
  7. Delete the subdiv mesh, move the original mesh back into place
  8. Parent to armature
  9. Make my tweaks
  10. Go to 1. Curse.

That is my actual workflow now. I hate it enough I might try to figure out another work-around.