Any progress made on this?
Impossible to work with hair when Multires modifier is added. Last working version was from november 2018.

That's basically the only thing stopping me from switching to 2.8, and yes strange thing that in early builds of 2.8 hair editing was much faster than 2.79

I remember an old Gsoc or something like that that had GPU generated children, it was like a modifier. Really cool. I wish we had that, for the viewport and editing. Even if it doesn't match the same seed as the Render and Render uses CPU

It's weird that 2.81 will be out soon, but hair still do not work properly :-(

In T59077#791429, @Thomas (TomyB) wrote:

It's weird that 2.81 will be out soon, but hair still do not work properly :-(

Well it doesn't crash blender so it's not high priority, but it makes doing animals or anything with fur and hair just broken and not doable

They are adding features like custom color for folders in File Open dialog. How is that a higher priority thing?
I don't get how they pick what's important and what's not. We are still stuck in 2.79 because of this hair bug.

In T59077#791640, @Thomas (TomyB) wrote:

They are adding features like custom color for folders in File Open dialog. How is that a higher priority thing?
I don't get how they pick what's important and what's not. We are still stuck in 2.79 because of this hair bug.

Yeah, was a bit surprised seeing roadmap for 2.81 they're planning to add pretty big and awesome features while we can't do fur or hair ><
There were other bugs in 2.79 like disconnecting hair not working with modifiers, devs said that the particle system needs a full on rewrite so they're not gonna fix that. So maybe we'll havta wait till they do that? I donno, for now we just gotta bug developers to fix it>:3

The plan for 2.82 is to rip out the entire particle system and replace it with a new one. So issues like this will probably not be worked on until the new system is in place.

Tbh, I see the particle system being replaced, but this will not really include hair [at least not in a first step, I might be mistaken, but I'm not aware of anything related to hair really in the works...], so if time permits, this should still be looked at... [that is my opinion at least...]

It's a shame that every time something is suggested, it's always turned down if it looks like it will interfere with a future deep systemic change. The problem is that those deep systemic changes take a long while to come to fruition or never happen at all. Think of all the modifiers that are in the burner because the modifier system is always promised to be replaced. A lot of times not having a feature in the present hurts Blender more than dealing with maintaining that feature through systemic changes in the future.

On top of that, will hair performance improvements really be that interfering or hard to maintain with the future hair object+nodes system? Or a weld modifier with the future node system for that matter? Judging by the kind of performance bottlenecks Pablo Dobarro is able to find, I wouldn't be surprised if there were other places where doing small stuff like reducing brush updates or excesive loops helps.

Delaying features for systemic changes is not a silver bullet either. Sometimes features get cut because it's not feasible to put it back with the new system in time (RIP Ghosts and DupliFrames), so if you risk losing old features, might as well risk losing new features too.

If it were by me, the burden of proof would fall on the developer to provide a clear roadmap and a good design document for a systemic change if he wants the privilege to halt new features.

out of curiosity, is this a slow or acceptable performance?
I want to check how much hardware is dependent

In T59077#791834, @noki paike (amonpaike) wrote:

out of curiosity, is this a slow or acceptable performance?
I want to check how much hardware is dependent

That's not acceptable, basically not working performance, on i7 8700k and Vega 56 have the same fps, even though in earlier versions of blender 2.80 it was working perfectly fine

Tbh, I can edit the hair from FurBall.blend with much better performance than the video [linux, i7-6700, 970m, 435.21 drivers], simple children have no lag at all, interpolated just a tiny bit...
Will run some test against 2.79 tomorrow...

This sphere thing is not a good example of this issue (it doesnt reflect what happens with true sculpted character with multires on). Unfortunately i can't share my scene file online, but i'll try to make a screen recording.

Scene works fine in 2.79, but is not usable in 2.80

Enjoy the Silence... :-)

Yes, that looks horrible.
Is there a file you can share, that has a similar setup [seems like there is multires involved as well?]
Preferrably saved from 2.79 so this is easy to compare results?
Just so we have something reproducable? [like I said, FurBall is not much of an issue on my machine... (and thats a laptop)]

In T59077#795889, @Philipp Oeser (lichtwerk) wrote:

Yes, that looks horrible.
Is there a file you can share, that has a similar setup [seems like there is multires involved as well?]
Preferrably saved from 2.79 so this is easy to compare results?
Just so we have something reproducable? [like I said, FurBall is not much of an issue on my machine... (and thats a laptop)]

Can you show your performance? Maybe it works fine on linux for some reason, but not on windows.

It is definitely slower than 2.79, just not that drastic (I can comb 10.000 hairs with 10 visible children without lag, starts getting bad with 25 visible children)...

Trying to do some profiling now...

It seems for me, that it's not related to count of hair strands or amount of children. I have less than 500 strands on my model and no children and it's still laggy as f*** in 2.8.
Since i can't figure out what makes it slow, then it's hard to make a simplified example scene. I'll keep trying when i get some free time again.
One thing i know, that if i remove or even apply the MultiRes modifier, then it gets fast. Same amount of polygons as with MultiRes on and it's fast. So it has something to do with MultiRes modifier.

Is it not possible to compare last working 2.8 version to new one and see what has changed in hair particles code? I can give you the exact date and hash code for last 2.8 where hair were still working.

In T59077#797289, @Thomas (TomyB) wrote:

It seems for me, that it's not related to count of hair strands or amount of children. I have less than 500 strands on my model and no children and it's still laggy as f*** in 2.8.
Since i can't figure out what makes it slow, then it's hard to make a simplified example scene. I'll keep trying when i get some free time again.
One thing i know, that if i remove or even apply the MultiRes modifier, then it gets fast. Same amount of polygons as with MultiRes on and it's fast. So it has something to do with MultiRes modifier.
Is it not possible to compare last working 2.8 version to new one and see what has changed in hair particles code? I can give you the exact date and hash code for last 2.8 where hair were still working.

That is indeed useful information (multires being the culprit), the last "working" hash would be very good to have, yes

Damn, tested it again and nope, deleting MultiRes didn't make it faster anymore. Im 100% sure it did last time i tried.
Im clueless now. What can it be..
Hash for working 2.8 is c4c62e6df55 and it's from 2nd of November 2018.

@Thomas (TomyB) : what about T59077.blend posted above?

• file has 10.00 hairs, 25 children (visible in the viewport), this one is a bit laggy for me as well
• reducing to 10 or 5 children eliminates lag for me (watch out to go out of particle editmode once -- children related settings are not updated immediately, see D5914, T69000)
• turning off Tool > Options > Viewport Display > Children in particle editmode, should make it butter-smooth, no?

Could you check this please? If this is still lagging for you, then this might be a Windows thingie? or GPU related?

I can confirm a performance hit somewhere between rBc4c62e6df55 and rB1b870bce85d [Nov 28th] though (in rBc4c62e6df55 I can go as high as 100 children), checking...

@Philipp Kant (philipp)
I made a short screen recording for you. T59077.blend works smooth when no children enabled.
Also you can see from the 2nd half of the video, that my character also has children turned off and only has a few hair strands, but is still super laggy
I place my hair manually and they have different lengths. Can this length difference cause any issues?

Thx for getting back about the T59077.blend [so the problem seems to be more specific]

I cannot reproduce any issues placing hair manually (Add brush):

• can set this to count 100 and place around 10.000 hairs, then comb without lag
• can also change their length (either by using the Cut or Length brush), still comb without lag

At this point, it would really be good if we had access to any reproducable test file [isnt there a way for you to reproduce this in a file you can share?]

It's the main character of our project so unfortunately i can't share the file.
Will get back to you if i manage to reproduce this kind of behaviour in another scene. (will keep on testing and trying)

@Philipp Oeser (lichtwerk), what is most likely happening here is that in 2.8 we need to do depsgraph tag to poke hair paths to be re-cached and this involves a copy-on-write operation, which is fine for simple meshes, but once you start having high-poly mesh with a lot of deform groups and such it becomes more and more expensive.

We need to find a way to make particle edit to fully live in original object (similar to sculpt or edit mode), or find a way to avoid full object copy and only copy particles.

The rest seems quite similar in a profiler for 2.7 and latest master.

@Sergey Sharybin (sergey): I am getting the performance hit from this commit rBd3c08b1aa62d (is that the one you are talking about?)

I am not talking any specific commit, i am talking state of the code as it is now.

I was able to reproduce it with your test scene. I subdivided the cube a couple of times, added Multires modifier and 3 UV maps. Looks like having UV's affects the performance in combination with polygon count. Try it yourself. The more UV maps you add to the cube the slower it gets in 2.8, but it stays buttery smooth in 2.79. The blend file is in attachment. Please test it.

@Sergey Sharybin (sergey) Is there any rough ETA on when it's going to be fixed? I don't know anything about coding, but that doesn't seem like a simple fix ><