Hair Particle system not behaving #65565

New Issue

Mark Kenworthy · 2019-06-06T15:24:18+02:00

Mark Kenworthy commented

2019-06-06 15:24:18 +02:00

System Information
Operating system: Windows 10 Pro 1809 64bit
Graphics card: NVIDIA GeForce GTX 1060 6GB

Blender Version
Broken: 2.80, 8fa65ed31b, 2019-06-05
Short description of error
Following along with a hair tutorial when at a certain point attempting to comb the hair makes all the children expand and fly-off.
Exact steps for others to reproduce the error
I have been following a particular hair tutorial by Nazar Noschenko,
https://www.youtube.com/watch?v=KpVyTc_72z0&t=44s
It's done in 2.79, but I found nothing that would prevent following it in 2.8
I will create the hair cap, create hair particle system and name it. Adjust length as instructed and set particle length to 0.
Use the 'Add' brush to create a line of particles for the nape. keys set to 12, steps to 10.
proceed to use comb to brush out the particle to desired shape. Then add children set to simple. increase radius to .07. Increase display to 60. Set to B-spline (which doesn't seem to do anything).
Proceed back to Comb to make more adjustments. That's when the children seem to expand and go outside the parameters of the original particles.
TY_HairProblem.blend
Based on the default startup or an attached .blend file (as simple as possible).

**System Information** Operating system: Windows 10 Pro 1809 64bit Graphics card: NVIDIA GeForce GTX 1060 6GB **Blender Version** Broken: 2.80, 8fa65ed31b7f, 2019-06-05 **Short description of error** Following along with a hair tutorial when at a certain point attempting to comb the hair makes all the children expand and fly-off. **Exact steps for others to reproduce the error** I have been following a particular hair tutorial by Nazar Noschenko, https://www.youtube.com/watch?v=KpVyTc_72z0&t=44s It's done in 2.79, but I found nothing that would prevent following it in 2.8 I will create the hair cap, create hair particle system and name it. Adjust length as instructed and set particle length to 0. Use the 'Add' brush to create a line of particles for the nape. keys set to 12, steps to 10. proceed to use comb to brush out the particle to desired shape. Then add children set to simple. increase radius to .07. Increase display to 60. Set to B-spline (which doesn't seem to do anything). Proceed back to Comb to make more adjustments. That's when the children seem to expand and go outside the parameters of the original particles. [TY_HairProblem.blend](https://archive.blender.org/developer/F7090091/TY_HairProblem.blend) Based on the default startup or an attached .blend file (as simple as possible).

Mark Kenworthy commented

2019-06-06 15:24:18 +02:00

Added subscriber: @MarkKenworthy

Garry R. Osgood commented

2019-06-09 21:49:27 +02:00

Added subscriber: @grosgood

Garry R. Osgood commented

2019-06-09 21:49:27 +02:00

These remarks are based on version: 2.80 (sub 74), branch: master, commit date: 2019-06-09 00:10, hash: 8452673a01. See also gosgood-system-info.txt.

I have seen this here as well.

In working with an object with very simple geometry, and with a one hair particle system, it seems that child hair particles are previewed in the viewport as only first degree (linear) curves. There appears to be no mechanism to change this.

I surmise that the necessarily coarse character and poor approximation ability of 1st degree curves gives rise to @MarkKenworthy 's "expand-and-fly-off" description of the problem.

In particular, the Path Steps parameter and B-Spline checkbox appears to have no effect in 2.80. As a consequence, it is almost impossible to shape hair in the particle editor when the ratio of children to parents is about 6:1 or more.

As a workaround, check off Children in the Properties panel, Tool tab, Viewport Display and set Path Steps to a fairly high value. It is not a good workaround. One can only make limited judgements about hair shaping when just the parent particle hairs are previewed.

To reproduce:

Open hairsimple_280.blend.

 a. It contains one piece of geometry: **Plane**.
 b. A hair particle system modifies the object which has a particle edit data block. Only one hair particle has been added.
 c. Otherwise, hair particle edit and particle system settings are those as suggested by @odysseus93

Find that it is in particle edit mode and the Comb brush is selected.
Comb the single hair. Observe:

 a. The underlying parent hair appears to be cubic; 2.80 renders this in black.
 b. The children are little more than staight line segments. 2.80 renders these in light gray.
 c. Attempting to adjust Path Steps affects only the parent curve; children remain as first degree linear curves.

Children of hair particles are also rendered as first degree curves in various viewport displays (workbench, cycles).
Only in rendering circumstances (F-12) do children of parent hair particle render as high degree curves.

In contrast, during editing sessions using 2.79b, child hair particles match the degree and rendering characteristics of parents. Only in viewport display in a 2.79b editing session, are child hair particles inaccurately displayed - but not as a linear representation, but as (apparently) cubics with seemingly incorrectly set control points, an ancient bug that is not at the heart of this matter.

The video clip bugreport_T65565.mkv depicts a 2.79b/2.80 side-by-side particle edit session using this sparse scene. The 2.79b session is on the left, the 2.80 session is on the right. hairsimple_279.blend was used for comparison with 2.80.

gosgood-system-info.txt
gosgood-system-info.txt

bugreport_T65565.mkv
bugreport_T65565.mkv

hairsimple_280.blend
hairsimple_280.blend

hairsimple_279.blend
hairsimple_279.blend

These remarks are based on version: 2.80 (sub 74), branch: master, commit date: 2019-06-09 00:10, hash: 8452673a0189. See also **gosgood-system-info.txt.** I have seen this here as well. In working with an object with very simple geometry, and with a one hair particle system, it seems that child hair particles are previewed in the viewport as only first degree (linear) curves. There appears to be no mechanism to change this. I surmise that the necessarily coarse character and poor approximation ability of 1st degree curves gives rise to @MarkKenworthy 's "expand-and-fly-off" description of the problem. In particular, the Path Steps parameter and B-Spline checkbox appears to have no effect in 2.80. As a consequence, it is almost impossible to shape hair in the particle editor when the ratio of children to parents is about 6:1 or more. As a workaround, check off Children in the Properties panel, Tool tab, Viewport Display and set Path Steps to a fairly high value. It is not a good workaround. One can only make limited judgements about hair shaping when just the parent particle hairs are previewed. **To reproduce:** 1. Open **hairsimple_280.blend**. ``` a. It contains one piece of geometry: **Plane**. b. A hair particle system modifies the object which has a particle edit data block. Only one hair particle has been added. c. Otherwise, hair particle edit and particle system settings are those as suggested by @odysseus93 ``` 2. Find that it is in particle edit mode and the Comb brush is selected. 3. Comb the single hair. Observe: ``` a. The underlying parent hair appears to be cubic; 2.80 renders this in black. b. The children are little more than staight line segments. 2.80 renders these in light gray. c. Attempting to adjust Path Steps affects only the parent curve; children remain as first degree linear curves. ``` 4. Children of hair particles are also rendered as first degree curves in various viewport displays (workbench, cycles). 5. Only in rendering circumstances (F-12) do children of parent hair particle render as high degree curves. In contrast, during editing sessions using 2.79b, child hair particles match the degree and rendering characteristics of parents. Only in viewport display in a 2.79b editing session, are child hair particles inaccurately displayed - but not as a linear representation, but as (apparently) cubics with seemingly incorrectly set control points, an ancient bug that is not at the heart of this matter. The video clip **bugreport_T65565.mkv** depicts a 2.79b/2.80 side-by-side particle edit session using this sparse scene. The 2.79b session is on the left, the 2.80 session is on the right. **hairsimple_279.blend** was used for comparison with 2.80. [gosgood-system-info.txt](https://archive.blender.org/developer/F7096632/gosgood-system-info.txt) gosgood-system-info.txt [bugreport_T65565.mkv](https://archive.blender.org/developer/F7096635/bugreport_T65565.mkv) bugreport_T65565.mkv [hairsimple_280.blend](https://archive.blender.org/developer/F7096636/hairsimple_280.blend) hairsimple_280.blend [hairsimple_279.blend](https://archive.blender.org/developer/F7096638/hairsimple_279.blend) hairsimple_279.blend

Sebastian Parborg commented

2019-06-14 10:44:47 +02:00

Added subscriber: @ZedDB

Clément Foucault was assigned by Sebastian Parborg

2019-06-14 10:44:47 +02:00

Sebastian Parborg commented

2019-06-14 10:44:47 +02:00

Because the children are renders correctly with cycles (and not eevee/workbench) I'm guessing this is a bug with those systems.

Garry R. Osgood commented

2019-06-14 14:35:39 +02:00

Ah, @ZedDB ! Welcome back to bug triage.
I disagree (a little bit) with your evaluation. There are Viewport side-by-sides near the end of video clip bugreport_T65565.mkv; Both the 2.79b and 2.80 viewport examples are both cycle-rendered previews and note that the 2.80 children are rendered as essentially first order straight line segments. My impression is that the issue is render-independent and I'm guessing differences in depsgraph evaluation in Viewport/render engine contexts is more pertinent, but I have not done any serious stepping through the code to substantiate that idea. Perhaps this weekend...

Ah, @ZedDB ! Welcome back to bug triage. I disagree (a little bit) with your evaluation. There are Viewport side-by-sides near the end of video clip **bugreport_T65565.mkv**; Both the 2.79b and 2.80 viewport examples *are* both cycle-rendered previews and note that the 2.80 children are rendered as essentially first order straight line segments. My impression is that the issue is render-independent and I'm guessing differences in depsgraph evaluation in Viewport/render engine contexts is more pertinent, but I have not done any serious stepping through the code to substantiate that idea. Perhaps this weekend...

Sebastian Parborg commented

2019-06-14 14:38:32 +02:00

I'm talking about when rendering with F12. At least for me, it is only cycles that shows up correctly in that case.

I'm talking about when rendering with `F12`. At least for me, it is only cycles that shows up correctly in that case.

Clément Foucault commented

2019-07-03 20:29:13 +02:00

I think there is a confusion because parameters kind of changed places.

In particle edit mode: The parent curve path step is inside the toolsettings (options in the toolbar) > Viewport Display > Path Steps. This changes the smoothing of the black curve.

The smoothing of the actual gray hairs is controlled by Particle System Tab > Viewport Display > Strand Steps.

The Bspline option does work. There is just a missing tagging, if you click the viewport it works.

The Steps just beneath the Spline option is only for render (but not working for Eevee.

Note that in the viewport/eevee we re-subdivide the actual shape to ensure we have the
same number of points for all hairs. The resubdivision happens on top of the parent subdivision so if parent Path Step in Particle Edit mode is not the same as the Viewport Display's Strand Steps a different will occur when leaving the edit mode.

So taking everything into account I can't think this is a bug. Or maybe i'm missing something?

I think there is a confusion because parameters kind of changed places. In particle edit mode: The parent curve path step is inside the toolsettings (options in the toolbar) > Viewport Display > Path Steps. This changes the smoothing of the black curve. The smoothing of the actual gray hairs is controlled by `Particle System Tab > Viewport Display > Strand Steps`. The Bspline option does work. There is just a missing tagging, if you click the viewport it works. The Steps just beneath the Spline option is only for render (but not working for Eevee. Note that in the viewport/eevee we re-subdivide the actual shape to ensure we have the same number of points for all hairs. The resubdivision happens on top of the parent subdivision so if parent Path Step in Particle Edit mode is not the same as the Viewport Display's Strand Steps a different will occur when leaving the edit mode. So taking everything into account I can't think this is a bug. Or maybe i'm missing something?

Garry R. Osgood commented

2019-07-04 00:40:25 +02:00

The Bspline option does work. There is just a missing tagging, if you click the viewport it works.

@fclem : Yes. That bit me in the posterior regions. I remember going over very carefully relevant parameters and remember looking at Strand Steps, changing it - seeing nothing happen. But, of course, I actually didn't kick the viewport display with a left mouse click. I made a little clip showing that it really does work, as you said - once a deliberate left mouse click was made on the viewport.
fixed_T65565.mkv fixed_T65565.mkv

So taking everything into account I can't think this is a bug. Or maybe i'm missing something?

You're fine - not missing a thing. On the narrow technical content of this report, you are right: the bug isn't there. I'd vote for closure.
But mouse clicking in the viewport is still a PITA - a UI papercut kind of bug, methinks that's just going to confuse people. Should I open another bug report confined to just that issue?
Thanks for all your great work by the way - you and the rest of the crowd.

>> *The Bspline option does work. There is just a missing tagging, if you click the viewport it works*. @fclem : Yes. That bit me in the posterior regions. I remember going over *very carefully* relevant parameters and remember looking at Strand Steps, changing it - seeing nothing happen. But, of course, I actually didn't kick the viewport display with a left mouse click. I made a little clip showing that it really does work, as you said - once a deliberate left mouse click was made on the viewport. [fixed_T65565.mkv](https://archive.blender.org/developer/F7565284/fixed_T65565.mkv) **fixed_T65565.mkv** >> *So taking everything into account I can't think this is a bug. Or maybe i'm missing something?* You're fine - not missing a thing. On the narrow technical content of this report, you are right: the bug isn't there. I'd vote for closure. But mouse clicking in the viewport is still a PITA - a UI papercut kind of bug, methinks that's just going to confuse people. Should I open another bug report confined to just that issue? Thanks for all your great work by the way - you and the rest of the crowd.

Clément Foucault commented

2019-07-04 00:49:18 +02:00

Changed status from 'Open' to: 'Archived'

Clément Foucault closed this issue

2019-07-04 00:49:18 +02:00

Clément Foucault commented

2019-07-04 00:49:18 +02:00

Yes create a new bug report for the missing update. I'm not sure if we have a bug report for that already.

Will close this report one at least :).

Yes create a new bug report for the missing update. I'm not sure if we have a bug report for that already. Will close this report one at least :).

Prince commented

2020-07-08 16:09:16 +02:00

Added subscriber: @Princesgs77

Prince commented

2020-07-08 16:09:16 +02:00

I also had this problem by watching this tutorial.
But when I adjusted the "radius" in the children tab, it got fixed

I also had this problem by watching this tutorial. But when I adjusted the "radius" in the children tab, it got fixed

Rombout Versluijs commented

2021-04-02 06:06:14 +02:00

Added subscribers: @Garry-6, @RomboutVersluijs

Rombout Versluijs commented

2021-04-02 06:06:14 +02:00

After reading this, is sort see the sluggish viewport still in 2.91 when your in combing mode and do edits. not everything seems to be updating properly. It was until i read this comment Garry R. Osgood stating, simply click in side the 3dv to "force" update it. I even downloaded files from this thread its either they are buggy for new Blender or its really blender viewport update issues. It took me many ticks and unticks to even get the children to show

Well tagging people just doesnt seem to go well. It tags the wrong person
@grosgood

After reading this, is sort see the sluggish viewport still in 2.91 when your in combing mode and do edits. not everything seems to be updating properly. It was until i read this comment Garry R. Osgood stating, simply click in side the 3dv to "force" update it. I even downloaded files from this thread its either they are buggy for new Blender or its really blender viewport update issues. It took me many ticks and unticks to even get the children to show Well tagging people just doesnt seem to go well. It tags the wrong person @grosgood

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Hair Particle system not behaving #65565