I cannot open these in the opensubdiv branch without crashing. They open fine in the general 3.0 alpha. I am certain there are more rigs that crash these just happen to be the latest ones im playing with.
These rigs are fairly complex so I don’t really know what aspect makes these crash everytime compared to say Red Nelb. I’d need some time to find what aspect causes the crashing exactly (assuming I can find it).
An amazing job, it becomes a pleasure to work in production.
And there is a question here:
Why is the" slide " of the vertex recalculated much longer than the grab or scale operation, for the subdividing of surfaces, the slide is very important?
Will there be a fix?
don’t take it as a claim)
and thank you again
Awesome to hear you got one bug down. If I save one of the settler rigs outside of pose mode I am able to open it in the current OSD branch but it will crash as soon as I go into pose mode.
With Red Nelb I did not understand what you were talking about so I used the link I supplied myself to download it and… it crashes in the subdiv branch
I was not aware of this at all! I’ve made quite a few changes to that rig locally before making that walk cycle and apparently, whatever issues that file has were solved in that process because I could open it and experience the benefits in the subdiv branch just fine.
I’ve just rewritten this post a bit. Sorry about the confusion. The Red Nelb trouble kinda came out of left field for me. I had no idea the original file before my edits was exhibiting this behavior.
Small display bug. In object mode with X-ray enabled the outline around the selected object is not drawn correctly if the object has a subd modifier on it.
Steps to reproduce:
Select the default cube when opening a new scene
Press Ctrl - 1 to assign a subd modifier with level 1
Thanks for the update!
UVs now work, nice. Going for another round of testing then, if you need feedback on it.
Unfortunately I got mixed results for character animation.
[Subdivided Cube, 4 bones]
Blender 3.0: 2 fps
Subdiv Branch: 29 fps
This first test went obviously very well with huge speed up (x14).
Other rigged characters don’t crash on file opening now. Here are two cases.
[Rigged Character 1]
Blender 3.0:
Solid preview: 29 fps
Material preview (textured): 16 fps
Subdiv branch:
Solid preview: 22 fps (-7)
Material preview (textured): 17 fps (+1)
This second test did not go so well unfortunately.
Tested with another computer just in case, but got similar results.
[Rigged Character 2]
Blender 3.0:
Solid preview: 13 fps
Material preview: 8 fps
Subdiv branch:
Solid preview: 7 fps (-6)
Material preview (textured): 6 fps (-2)
Similar performance regression to character 1 unfortunately.
Other issues found:
Faces are always shaded flat, not smooth if “Use Limit Surface” is disabled
I would be curious about one of your testfiles Lucky.
From looking at that wireframe the topology looks very random. It looks more like a game model then a model that is supposed to be subdivided. OSD works best with quad based topology. That might explain the performance difference you are experiencing.
I also noticed what Lucky said about smooth shading failing when “use limit surface” is not enabled. Here is a screenshot to illustrate the issue clearly.
@regis3d The second character case is this one above. Then it doesn’t matter if it’s quad based topology, same performance issues. Before making assumptions, you can test yourself.
Thanks for clarifying Lucky! I guess you just used it to illustrate the wireframe overlay not working properly. Better safe then sorry in cases like this right?
I am testing things myself. The rigs I’m testing with are probably less complex so I see more benefit. No ill intentions from my side here.
I know, the message was mainly targetting @regis3d. It’s always disappointing when taking the time to test features properly, establishing a clear report to be helpful, and seeing such messages thrown by users who don’t know what they’re talking about, without even taking the time to verify their statement.
My point is, on the contrary, it’s important to test both case, triangles and quad based model, to check there’s no performances regression in both of them, and hope for the best!
I am not see much point of testing half implemented features by my self, better to wait when it will be in master. Brunches is closed for bug reports. Developers usually have in mind most of problems in unfinished patches. I believe Kevin take care of it.
In regards to the wireframe overlay its actually the drawing of the wireframe in general for a model with a subdivision modifier on it. Just to clarify it a little bit.
When enabling wireframe through overlay settings
Through object settings > viewport display > wireframe
By going into wireframe mode
This makes perfect sense since its probably all the same code but just thought I’d mention it.
Its also regardless of “optimal display” being on or off
Its easily reproducible by assigning a subdivision modifier to the default cube with Ctrl + 1 and going into wireframe mode.
I wrote about my self, not about other people. Read comment more carefully. It is always good when someone help with testing. I wrote because I saw bad topology for testing. Just wanted to save time for developers to not worry much about topology with almost no use cases.
P.S. Saying ,I am " do not know what I am talking about " is pretty rude.
I don’t know, I can look into it and see what is happening.
The crash is caused by a subsurf modifier which is on some armature object. I don’t know how it got there, but it is not supported. This has nothing with the branch, but still should be fixed I guess.
It’s always a good things to share files, then I can also run them in a profiler.
The goal of this thread is to test this feature before going to code review/master, so we don’t end up in a situation where there is some design issues that prevents it to be merged, or forces it to be reverted. It’s ok not to test though.
Even if the topology is bad I would only expect a slow down when the data is initialized. After that we only sample points using precomputed weights. The only way to know is to have the file and profile what the code is doing.
While the performance is better than the CPU that we had to deal with for the past years but it’s nowhere near 2.7x yet especially for viewport playback as the others have mentioned.
Hopefully it’ll get better since this is WIP, but it looks like there is no option ,so does that mean it’ll use the GPU automatically?.
I am currently looking into performance so hopefully the situation will be a lot better next update. And yes, we automatically use the GPU, as long as the modifier is the last in the stack.
You may not be directly involved with this as it is mostly UI (as I understand it), but any idea what happened to making subdivision an object property ?
I guess you just used it to illustrate the wireframe overlay not working properly. Better safe then sorry in cases like this right? 
