Make hair on scalp results in bad viewport performance with Voss Hair

Issue #767 resolved
Dareos Meyer created an issue

Hi, I first want to start with saying thank you for spending so much time and effort building this incredible tool, it really is amazing. Second, I am very new to working with Daz models in Blender and wouldn’t be surprised if my issue here has a simple fix, but I looked through the excellent documentation for Diffeomorphic as well as the issues reported here so far and haven’t found anything that addresses this issue. But I apologize in advance, regardless, for wasting anyone’s time with an issue that could be due to my inexperience.

So the issue:

I am trying to create a skullcap for the Voss Hair in blender which I can then attach to any character I import from Daz. I was following this post about how to do it: http://diffeomorphic.blogspot.com/2020/11/preparing-mesh-hair.html.

The issue is that when I choose Make Hair with the separated scalp mesh from the Voss hair selected as “human” and attach that mesh now with the hair particle system to my character armature and then apply an action to the armature my viewport fps drops to about 3. Doing this same process with a hair like Toulouse works perfectly with a solid 24fps. Another interesting part is that if I don’t separate the Voss hair scalp and just Make Hair with a low poly model like a deflection mesh of my character selected as “human”. It also works perfectly with a solid 24fps. Seeing that the hair particles didn’t seem to be the issue I tried weird things like Making Hair on the Voss scalp but adding the armature modifier after the particles to see if the scalp was screwy but that resulted in 24fps as well.

I should also note that all of this is done with the main high poly mesh of the character disabled so that isn’t affecting performance. And I have also made the particle hair directly on the high poly character mesh and while of course it does cause low fps, it isn’t anywhere near as low as when the issue is occurring.

At this point I am assuming that this is some weird quirk of the Voss hair and not Diffeomorphic since the process works correctly with other hairs. But I would be interested to see if anyone had any thoughts since I am partial to this hair style.

Comments (11)

  1. Alessandro Padovani

    If the issue is limited to the Voss hair then it means there’s something to fix in that particular hair style. Some PAs don’t make too much attention on what they’re doing while modeling and this could affect performances as well as the correct behaviour of modifiers.

    You may try to “select > by trait > loose geometry” in edit mode to see if there’s anything to be deleted before converting to particles.

    Then for viewport performances you can always use the simplify tab to limit the visible particles. Also you can use the resize hair option in the make hair tool to get a single particle system.

    edit. On my system I get about 12 fps with the converted Voss hair while playing the dance animation. It’s a ryzen 2200G for the viewport. With the particle modifier disabled I get about 20 fps. Using simplify I can easily drop the frame rate if I increase the child particles visible in the viewport, but that’s expected. Didn’t find anything odd with the Voss hair itself.

  2. Alessandro Padovani

    IMPORTANT NOTE. There’s one possible optimization that may be good for most hairs though. I see that, when we separate the scalp, it gets an armature modifier and is driven by the armature as any outfit is. This is fine with geometry hair if the hair gets some custom bones for posing. But once we convert to particles and possibly use dynamics, we may just parent the scalp to the head bone of the figure armature. I mean we don’t need the armature modifier anymore for the scalp. This way I get from 20 to 30 fps in my system with the particle modifier disabled.

    I don’t know if it is possible to automate this. I mean we have to separate the scalp by hand anyway, so it makes sense to also remove the armature and parent by hand. But this may be a useful note to add to the docs.

    Please note that for parenting to work for the head bone we must use relative parenting, that’s a sort of “parent in place“ when we parent the scalp. This is done in pose mode.

  3. Dareos Meyer reporter

    Hey, thanks so much for the help. I went through the steps you suggested and was able to replicate the performance you got with the hair by resizing the hair as well as by disabling the particle modifiers in the viewport. However, this doesn’t explain why I can get perfect performance when the hair is made on another model such as the deflection mesh without resizing hair or disabling the particles.

    I also tried as you suggested, getting rid of the armature modifier and parenting directly to the head (thanks very much for that tip btw, i didn’t know the part about relative parenting) but this didn’t have much affect on the performance issue.

    After fiddling around I have a new curve ball to throw which is: if I run a “Make faithful low poly“ on the separated scalp and then make the hair on it, I get perfect 24fps performance which essentially solves my issue. However this solution makes absolutely no sense to me as the poly count of the Voss scalp mesh is less than half the count of the toulouse hair scalp to begin with and that one has no issues at all. Maybe it is as you said Alessandro, that there is some quirk with how this hair mesh was originally made. Maybe it is some interaction between the scalp and the particle system? Which would explain why there is no issue when the hair is made on the deflection mesh because the scalp mesh from the hair is gone? I am way out of my depth here…

    I guess the takeaway is that the issue is solved and if anyone else has a similar issue: Try running “Make Faithful Low-poly” on the separated scalp mesh before making the particle hair.

  4. Dareos Meyer reporter

    Running “Make Faithful Low-poly” on the separated scalp mesh before making the particle hair seems to solve all the performance issues which I was experiencing.

  5. Alessandro Padovani

    @Dareos Meyer , I can confirm that using a low poly scalp goes from 12 to 30 fps here, with particles visible on the viewport. I wasn’t able to find any bad geometry myself on the scalp though. If you may please reopen the issue I’d like to hear from @Thomas Larsson what he thinks of this.

    So to recap. If we delete the armature from the scalp and parent it to the head bone, then we get full fps with particles disabled, but low fps with particles anabled. If we make a low poly scalp then we get full fps with the armature and particles enabled. This may suggest to always use both the tricks and make a low poly scalp parented to the head for maximum performance.

    Then stills odd that this only seems to happen with some scalps. Probably reducing to low poly also fixes some geometry quirks.

    It would be useful anyway to add these notes to the docs for everyone to be aware of.

  6. Alessandro Padovani

    As for the implementation it could be provided a “make optimized scalp“ tool to automate it. Where the user selects the scalp and the figure then the tool does the necessary steps. Please note that the head bone for G1-G8 will be different.

    Or we just write a note in the docs.

    # make optimized scalp, this gets full fps with all hairs
    delete armature if any
    delete vertex groups if any
    make faithful low poly
    parent to the head bone for G1-G8 with relative parenting
    

  7. Thomas Larsson repo owner

    I can confirm the speedup with the faithful lowpoly. There is also some gain with the simple lowpoly but not so much, presumably because it produces a rather bad mesh in this case. Replacing the armature modifier with a bone target didn’t make a difference for me, but perhaps I set it up wrong. I had never heard about this relative parenting before.

    I don’t think there is nothing to do here, except perhaps write a blog post about this nice trick.

  8. Alessandro Padovani

    Thank you Thomas, a note in the blog or the docs is ok for me we may mark as resolved.

    As for relative parenting we should use it whenever we parent something to a bone, so to preserve the child original location. It’s a sort of “parent in place“.

  9. Dareos Meyer reporter

    Thanks so much to both of you for looking into this. A note about this in the docs would be awesome in case anyone else needs help with this issue in the future.

  10. Log in to comment