OpenSubDiv is on its way back

news

(Ace Dragon) #183

From the release notes.

https://wiki.blender.org/wiki/Reference/Release_Notes/2.80/Modeling

Note however there are still some missing features and performance problems in the new implementation. Particularly animation playback and moving of vertices in edit mode will be improved before the final 2.80 release, to bring it back to 2.7x level.

Further optimizations and features to be added later in the 2.8 series:

In short, the devs. are aware of the issues and have plans to work on them. It’s just that Sergey also has a bunch of depsgraph and modifier bugs to deal with too.


(Ace Dragon) #184

As for other pain points in OpenSubDiv, Sergey is now getting around to fixing a couple of issues.

An issue with vertex colors.
https://lists.blender.org/pipermail/bf-blender-cvs/2019-January/118532.html

And a memory leak.
https://lists.blender.org/pipermail/bf-blender-cvs/2019-January/118533.html

No big performance fixes yet though.


(Ace Dragon) #185

Sergey’s next major addition looks to be a topology cache.
https://developer.blender.org/rBb0c6c65e7b45bf66f2f9e0aa3718be7eb0f72f81

Reports from one user notes a significant speedup. Though it is still not close to realtime because the code is not being done on the GPU.

In addition, a couple of topology and creasing issues have been fixed. When the cache is in, then OpenSubDiv should take a decent step towards being fully usable.
https://lists.blender.org/pipermail/bf-blender-cvs/2019-January/118747.html


(Ace Dragon) #186

Sergey continues to lend priority to not only the new subsurf code, but also the new multires code that is based on it.

Spike prevention.
https://lists.blender.org/pipermail/bf-blender-cvs/2019-January/118839.html

Better preservation of continuity when doings things like a reshape operation
https://lists.blender.org/pipermail/bf-blender-cvs/2019-January/118843.html

More robust code in general to reduce the chance of a sculpt breaking somewhere.
https://lists.blender.org/pipermail/bf-blender-cvs/2019-January/118845.html


For those struggling with sculpts in 2.8, this will be welcome news.


#187

Thank you for doing this, saves me time from scanning the changelog for opensubdiv / multi-res related updates. :+1:


(rendetto) #188

Does anyone knows how the new Catmull-Clark implementation was done? Is there a way to make an option for backward compatibility, because now it causes a size difference (at subdiv level 1 and so…) between the old way and the new way which broke old files and other things.
Thanks


(artell) #189

You can play with the “Quality” setting, but there will certainly be subtle differences anyway… Opensubdiv is a different algorithm which uses approximation to speed up the performances, as far as I understand. If the differences are too visible, you can consider to increase the base mesh resolution. The subsurf modifier should generally be added to smooth the geometry, but, in a way that does not change too much the global shape. If it does, it means there are not enough polygons underneath.


(rendetto) #190

I tried the quality settings and this affects only the “star” points in a way so they are near to the “limit surface”.
Not everyone needs the limit surface as a result of using the Subdiv modifier, sometimes the first or second subdivisions are the goal for some workflows.
It was a predictable and controllable thing. If you apply the modifier once, then add a new and apply it again, you’ll always get a predictable result at the end.
Now if you apply the modifier, and add another one, the result mesh turns very different(shrink offset) from the “expected” result.
This affects “layering” the Subdiv modifiers. In 2.79 regardless of how many stacked Subdiv modifiers you use the end result is the limit surface of the original control mesh.
In 2.8 if you “layer” a couple of Subdiv modifiers you get shrunk mesh that never touches the original limit surface.
In the screenshot, there are 2 subdivided default planes, with and without layered modifiers.
in 2.7x the results match, in 2.8 are not.

And that destroyed my workflow. It’s strange that no one has raised a flag for that particular problem.


(stargeizer) #191

And did you report the bug???..

Just asking.


(rendetto) #192

I did ( https://developer.blender.org/T61245 ). But, technically, it’s not considered a bug. It’s just a backward compatibility problem. I’m sure that the new implementation have it’s advantages. I’m not against, but there should be a way to make things compatible - an option in the modifier itself or at least an option in the “Subdivide selected edges” command in Edit mode.


(anth455) #193

I agree. I think using the limit surface is a good idea if you want a final mesh that is not going to be subdivided again. But if you want to apply one level of subdivision then maybe cut some holes etc. then subdivide again it shrinks the final result. The amount of shrinking depends on how dense the mesh is to begin with. Applying two levels of subdivision then one more on top of that causes less shrinking.

Not sure how other programs do this? Do they use the limit surface?
On the plus side one or two levels of subdivision now is very near the final shape.

I think it would be nice to have an option for this. Another way would be to maybe shrink wrap to the original to prevent the change in size.


(rendetto) #194

I’m now checking how it is done in Maya.

After 2014 version there are options you can choose between, the classic Maya Catmull-Clark and the Uniform OpenSubdiv, both of those output results like in Blender 2.79.
There is a third option - OpenSubdiv Catmull-Clark Adaptive, where the result is exactly the one we see in blender 2.8. And the subdivision level is controlled via the “adaptive tessellation level” slider.

So it seems that we lack some options here.


(Piotr Adamowicz) #195

This is only really a problem for meshes with 1 level of subdivision. After that, the difference is negligible. Blender 2.8 is allowed to break compatibility, and it’s never a good idea to change versions mid-production, so it’s all fine.

What I’d love to see is an option to auto-crease open edges. And creased vertices.


(rendetto) #196

A difference in such core functionality is not a negligible difference imho. It messes up some workflows.
I agree, for straight organic modelling it may not be such a problem, but for precise modelling and mesh reconstruction it’s a disaster. You can never get reversibility to the original mesh.


(Piotr Adamowicz) #197

But it’s not a problem as long as you don’t switch to B2.8 mid project. And even then, how many precise modelling projects are there that demand exactly one level of subdivision, and not more? Those projects should have been based on the limit surface, and not level one from the get go. And even if they haven’t been, as long as you have slightly more geometry than the simple cube there, the difference really is quite small.

So I don’t see the issue.

On the other hand, maintaining two different code paths for subdiv is a burden on the B team and only gets you a feature few people will ever need, for a problem that can be solved in different ways (such as, trivially, applying the lv1 subdiv in 2.79 before switching).


(oaschwab) #198

When I compared the old Subdivision surface to open subdivision I found that in almost every case I preferred the old. It seemed slightly easier to control shape and form. Opensubdiv seems to be more smooth in every case. But progress is progress and there’s no use complaining about that. One thing I’ve noticed is that as of now, opensubdiv is a real dog. I mean it is insanely slow. It’s just strange because in 2.79 the opensubdiv actually ran faster than the blender subdivision. Turning down the quality to the lowest setting doesn’t make much of a difference in the subdivision result or the speed.


(Piotr Adamowicz) #199

In 2.79, OSD was never used in Edit Mode.


(oaschwab) #200

Thank you for clarifying.


(m9105826) #201

Blender’s implementation of OSD is… interesting to say the least. In my opinion it needs to be torn out and completely redone. It strays too far from the reference implementation IMO and has a lot of cruft left over from what I can only assume were the “figuring out OSD” days.


(oaschwab) #202

Yeah I’m not a programmer so it’s hard to say. I think even if I was a programmer it would be hard to pinpoint the best way to do it. Programs like Blender are so huge and interconnected that it could just be something that takes some optimizations to make it amazing.