Now that’s something we can (well almost) all agree to…
The only problem is how to convince Sergey & Co. that the OSD implementation has issues that need to be addressed, since they are considering that any breakage in this area is not a bug… 
guys, look what performances are achieved with the radeon mesa opengl as using the technique of Primitive Culling With Async Compute , I strongly think that the guys of blender should take a look at the source code of mesa radeonsi and adopt similar techniques directly on EEVEE for all GPU 
someone who has one of these gpu can do tests with these mesa drivers?
I’m curious to know what happens with opensubdiv
https://www.phoronix.com/scan.php?page=news_item&px=RadeonSI-Prim-Culling-Async-Com
I do think there’s a good chance OpenSubDiv will be improved a bit yet, as I don’t know how the BF can even do their own open movie projects if slowdowns in deformation performance can occur even with simple models.
Getting the performance back to 2.7x levels is on the todo list at least.
The problem is not performance, the problem is going from “predictable results” to “results may vary”. (compared with 2.7x series). It depends of what is important here.
In the end, since it only appears to affect few people, probably it doesn’t matter that much at this point. It will matter when 2.8x becomes stable… As usual, waiting game.
The topology cache is now in for animation work.
https://lists.blender.org/pipermail/bf-blender-cvs/2019-February/119957.html
This gives deformation performance a bit of a boost. However, there is more work needed before this can speed up editmode (so no speed up there yet).
4 Likes
i don’t really get the opensubdiv problems. 
why is it so hard to integrate? because blenders mesh format isn’t really compatible?
what other programs use it? was it as tricky for them too?
i thought opensubdiv is supposed to make things easier than rolling your own subdiv code.
1 Like
its the wrong tool for the job (modeling / sculpting)
aren’t subdivision surfaces basically just a relatively simple formula/recursive algorithm kind of like bezier curves?
wikipedia says:
https://wikimedia.org/api/rest_v1/media/math/render/svg/724c5c389f8665440609b8aeac791a5325f1ba90
why can’t blender’s old formula/algorithm not simply be adapted for the new improved creasing and so on?
i don’t understand all of this.
It’s kinda complicated as I understand. There are different rules for specific cases, that vary from one implementation to another. For example how it should handle corner vertices, boundary vertices, non-manifold geometry, face-less edges etc… To be honest, I think that the original Blender implementation gives the most clear results especially with the non-manifolds.
2 Likes
Just learn programming and see how “easy” it is. if it’s easy as you think, I’m sure they will pay you if you promise to integrate it yourself.
i know that it is not easy and i didn’t want to bash the blender developers.
i just wondered why it is so hard. to me opensubdiv sounded like: ready to use library with simd/gpu optimizations, industry standard and industry proven, just put it into your app and all will be good,…
i know how to program and would be able to implement a basic version of the algorithm described on wikipedia. but i am not experienced with huge projects like blender and all its intricacies.
OSD has built in flags and options for all of those things. I’m not sure why Sergey has made such a big deal out of them.
Think of integration libraries (this goes for all, not just opensubdiv) more like ikea furniture less like buying a microwave for in your kitchen, a microwave you unpack and you’re ready to go! boom! easy! Ikea you get all the pieces and you kinda have to put them together your self, using the little booklet that comes with it, now this doesn’t apply to all libraries and I haven’t seen the opensubdiv documentation, but for some libraries this booklet is missing, and for others it switches in between Korean and japanese and they hired picasso on LSD for their drawings. Others come with a perfect booklet but with 23.748 parts in the kit it’s still gonna take a while to get it into a usable state.
What I’m wondering is why they decided to get rid of the old algorithm for good, instead of have them available side by side with the ability to choose which one you want to use, as seen in most SDS modifiers out there. 
3 Likes
That would’ve been the likely outcome had they been working on the full integration in a production-ready branch like 2.7x.
2.8 though has not gotten to the point where the devs. consider it a production branch, so they can break things and users are not to expect a totally smooth experience until they declare it as such.
Plus it’s probably a lot more maintenance
Fracture Mod 2.8 branch now has an option to use the old subdivision code. See:
https://lists.blender.org/pipermail/bf-blender-cvs/2019-March/120332.html
3 Likes
Do you know if changes in geometry with new Subsurf modifier that spoil old scenes deserve to be reported? Or is it expected that these things happen?
Another step in the right direction, the topology cache now works in editmode.
https://developer.blender.org/rB8fb0b9aebbd409216dec77c4b1bf2a2fbba80698
The speedups will mainly be noticed for operations that don’t change topology, but in my experience that was where the biggest bottleneck was anyway.
4 Likes
So will this change be in tomorrow’s build?