OpenSubdiv issues with large and complex meshes

Yeah, and works with subdivision activated to see the shape is impossible in a little complex objects

It sill be good a devs explanations about this problems of performance @jesterKing

Anyway I suppose that must be a serious problem if a clear perfomance regresion is not solved in few time.

The person best suited for doing anything useful to the subdiv code would be @sergey.

OpenSubdiv is having harder time dealing with non-quad faces because it tries to find a better smooth surface approximation. This is a known issue reported in T60733 and T58191.

From the initial post here it seems that OpenSubdiv is using about 20x more memory compared to similar setup in 2.79. This is something to be investigated, but for that we need a report in the bug tracker which follows the bug report guidelines.

2 Likes

I see that comment the last week but I tried the modifier on a normal grid and the problem with perfomance is the same. Maybe not so big like with other n-gons surfaces, but a problem if we compare with old subdivision

1 Like

Not really performance issue but could you take a look at T68200
I made it awhile ago but I’m unsure what to do since it hasn’t had anyone point out what I did wrong. It worked in 2.79

@sergey I post this example of other user in other thread here

I did other test, with a simple box subdivided and an armature, all quads. And I obtain similar results, with old OpenSubd the perfomance I obtained 130fps in play mode with GSLS, and 30fps with CPU. With the new OpenSubD I obtain 7fps (and it didn’t change with wuality settings that by now I don’t see the reason to use this parameter). Few more than old subdivision, 4fps

But also if when we edit a mesh the perfomance is bad compare with old Blender Subdivision. With a simple box with 3x subdivision in blender2.79 i can edit the mesh without problems, with the new subdivision it is lagged.

Similar example with lattice, both models have same number of faces.

It is a extreme high priority right now? because it is also one of the reasons of slow undo. Because the “start” time of the opensubdivision is slow and it happens each time that user do undo or activate the modifier or made any change in a modifier stack

Why we don’t have options to select the backend in new subdivision? why the old system is not optional?

3 Likes

@Alberto, it is not a fair comparison between OpenSubdiv option in the 2.7x series and 2.8 ones. In 2.7 even with CPU device there was a very minimal set of operations done on CPU, the rest was happening on GPU. Currently in 2.8 everything is happening on CPU, and the result of subdivision surface modifier is suitable for use as an input for other modifiers and parenting/collision system.

Valid comparison would be to compare 2.8 with old non-OpenSubdiv 2.7.

GPU integration is yet to be brought back. This is stated in the release notes.

Because it is also one of the reasons of slow undo.

This is one, but not only or main sources of slowdown. Those are being solved in general under T60695

Why we don’t have options to select the backend in new subdivision?

One aspect is that new developing features and fixes are relying on OpenSubdiv, and another aspect is that old code is always in a way and trying to keep it working ends up being a negative cost-benefit balance.

1 Like

Good to know that info

The video of the post was non-Opensubdiv 2.7 compared with 2.8

But for example, other video of Non-Opensubdiv in 2.79 (right) compared with Blender2.8 (left) with same mesh and subdivision level

When you have big scenes, yes, that is a problem, but in little scenes, 20-40 objects only to have one object with subdivision slowdown all the undo seconds in each press. Without the subdivision the lag is zero.

This is a big problem, actually the subdivision is useless or hard to use in blender. Is one of the main features of a 3D software.

1 Like

Other curiosly effect. If I edit with a Subdivision (it happens with array collapsed) and I made a slide, the subdivision perfomance go down only in one of the slide directions.

Other example of same difference between non-OpenSubDiv (right) in 2.79 and Blender2.8 (left).

" Optimized per-datablock global undo" …
this raises a question …
could be real benefits when this :

Switch Blender task scheduler to use TBB

will it begin, when piece by piece, to permeate these systems around subdivision surfaces too, especially the parts that concern the CPU to bring real advantages and improvements?
… I mean above all by minimizing bottlenecks

@Alberto, i can not be looking into issues reported to a forum in the form of videos. Make a report in the tracker, following the guidelines. It might or might not be a known issue.
This way you would also know when there is a progress in a specific task.

@nokipaike, those a unrelated. With TBB you’d have two things.
Thing number one: faster playback and some other areas which are using thread pools.
Thing number two: more developers working on an actual important things than trying to re-implement a wheel.

1 Like

How does it behave when you delete that central triangle fan part at the bottom? Do the fps go up?

I don’t want to @ Sergey more than this but if anyone knows is there timeline for OpenSubdiv on GPU?

On 2.8 the playback of a shape animation is very slow if we use the subdivision modifier. In Maya and Softimage but also the Blender 2.79 the speed is really much higher.
Slowness increases with detailed models with many vertices.
For realistic face and character animations having fast subdivision helps animators see animations in real time, at 24fps or higher. Opensubdiv allows this in many 3D software.
There was a 2014 video where Sergey showed an animated dragon with active and finally fast subdivisions. Now it seems to be back in 2013.
Blender 2.8 has great potential, I think the increased performance of OpenSubDiv is a priority for modeling and animation.

Try a 100 x 100 vertex sphere with a simple animated shape. I noticed a difference in playback between 2.79 and 2.8 (using 4 subdivision levels) of 100 times higher in 2.79 (60 fps vs 0.6 fps).

@3Rton It’s mentioned here https://developer.blender.org/T64282.
But I hope that list is not actual, as its priority is set to the lowest priority.
(marked as nice to have).

@RORU It’s solely running on cpu right now. You can expect quite some performance boost when gpu acceleration will be implemented.

1 Like

Playback in 2.79
OpenSubDiv compute CPU:
5fps
OpenSubDiv compute GLSL:
60 fps

Playback in 2.8
0.6 fps (CPU?)

4 levels of subdivision on a 100x100 sphere (I animated a shape) are an exaggeration but serve to highlight the problem that seems very serious

3 Likes

That is a shame but I guess for now just have to hope they will have time for it after the bigger projects solidify.

If we are on MacOS, that won’t happen, right? Blender GPU accel isn’t supported on MacOS. MacOS will still have very slow performance even after GPU support is fixed/ready.

Omg, i didn’t notice that yet.
Low prio? plz guys this is an important thing for character animation, shape animation and so on.
I hope you can provide GLSL as soon as possible.
The difference is HUGE between 2.79 and 2.8x
Thanks!

1 Like