OpenSubDiv is on its way back


(Ace Dragon) #102

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.

(Cheinu) #103

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

(Ace Dragon) #104

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).

(erickBlender) #105

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

(Ace Dragon) #106

Surprise from Sergey

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).

:partying_face: :fireworks:

(English is not my native language) #107

Ok, I still had an instant crash with OpenSubdiv in my own builds.
I forced the reinstallation with: --force-osd
And this works now.

By the way, I’m not sure about why Fast Navigate is enabled by default for Sculpt mode.

(captainkirk) #108

What practical difference does this make to artists right now? Is it just better performance?

(nudelZ) #109

its not even better performance (on my machine compared to 2.79…) its much worse

(captainkirk) #110

Really? That’s worrying. Can anyone else confirm this?

(Ace Dragon) #111

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).

(nudelZ) #112

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)

(Thinking Polygons) #113

I tried multires on sculpt mode and yes, terrible slow.

(servapunk) #114

Can we expect a better performance for the final 2.8 release?

(artell) #115

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.

(Piotr Adamowicz) #116

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.

(English is not my native language) #117

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.

(Piotr Adamowicz) #118

Let’s hope so. Shipping 2.8 with anywhere near this level of subdiv performance would be a disaster.

(Ace Dragon) #119

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.

(wph4) #120

It’s not using the GPU yet… If I read correctly, and there was something about geometry editing that is still not totally optimize?

(wph4) #121

Oh what I remember now. Without the GPU, mesh editing takes a performance hit?