Sergey has currently been busy with depsgraph work (fixes and general improvements) along with some remaining OSD fixes. I’m sure someone will post a link to the commit enabling OpenSubDiv for real when it comes.
1 Like
Thanks. I was just confused since there was a thread (I think) saying that it was working but I guess it must have been on some off branch version or something
The code is in master right now, but it needs to be enabled via a command in the console (it is more for the purpose of testing than actual use).
If you build your own Blender you have to activate it in cmake. Check this thread in the first post i m sharing my build Multi resolution modifier is working again in Sculpt mode in Blender 2.8
Surprise from Sergey
https://developer.blender.org/rB9abcf56fa88dd849bf0f83fafe5d4666d3531cd2
This means Multires should now be fully functional for the most part (with a few limitations that will be worked on before the final release).
6 Likes
Ok, I still had an instant crash with OpenSubdiv in my own builds.
I forced the reinstallation with:
install_deps.sh --force-osd
And this works now.
By the way, I’m not sure about why Fast Navigate is enabled by default for Sculpt mode.
What practical difference does this make to artists right now? Is it just better performance?
its not even better performance (on my machine compared to 2.79…) its much worse
Really? That’s worrying. Can anyone else confirm this?
Nudel; Is there anything in the preferences regarding OpenSubDiv at all in 2.8?
I know 2.79 had the option for multi-threaded calculation, is that option there?
Also to note, GPU compute for OSD is not going to be available for the initial 2.8 release due to the sizable amount of extra work needed (because of the new viewport code).
yeah some proper testing would be nice - simple test subdivide suzanne as high as possible, sculpt, switch subdiv levels, sculpt etc and compare that to 2.79
@ ace multithreading seems to work fine (on by default it seems)
I tried multires on sculpt mode and yes, terrible slow.
Can we expect a better performance for the final 2.8 release?
Used to be preferences for OSD, but no more in the latest version.
About GPU computing for OSD, I would not be too worried, in many cases CPU was faster in 2.79.
Anyway, for the moment it’s very slow with rigged characters.
Using build 26b1aa99436 Subdiv is now unusable for me in edit mode beyond around 2000 faces at 2 subdivisions.
2.79 by comparison only gets the same sort of performance at 2 subdivs at 30 000 faces on the same hardware.
I really really hope this is just unfinished code and serious optimization is in the works. Right now it’s more than an order of magnitude too slow, never mind any improvement over 2.79.
Sergey is behind this, so there are many chances that this will be very well optimized later on. I have confidence that this will be better than in 2.79.
Let’s hope so. Shipping 2.8 with anywhere near this level of subdiv performance would be a disaster.
1 Like
I think it would be help to be more specific on what has regressed performance-wise if possible.
I just made a quick 1000 face object using subdiv level 6…
- Moving/rotating the viewport, super fast
- Selection of vertices (left-click select and circle select) - fast
- Execution of tools like loopcut - reasonable
- Moving vertices - slow
So on my machine, the bottleneck is actually transforming and moving geometry.
1 Like
It’s not using the GPU yet… If I read correctly, and there was something about geometry editing that is still not totally optimize?
Oh what I remember now. Without the GPU, mesh editing takes a performance hit?