Hair object - design proposal #78606

New Issue

Daniel Bystedt · 2020-07-04T17:14:01+02:00

Daniel Bystedt commented

2020-07-04 17:14:01 +02:00

IMPORTANT: Please note that this document is subject to change and will most likely not represent the final product of the new hair object in Blender

Reference links

Hair object - project description
#68981 (New curves object type)
Hair object - node design
#78515 (Hair object - Node types design)

Hair object design

Guide curves
This is a list of guides in the hair object. "myGuides" in image example. On the same hair object there can be multiple guide curves ("eyebrows", "hair", "eyelashes" etc). Guide curves are the curves are what the user grooms with the particle brush. The guide curves are sourced into the node tree graph via an input node.

Growth mesh
This is the mesh that the guide curves are attached to.

Node tree
This is a slot that referers to the node tree containing the nodes for creating and deforming the instanced hair curves. See design task #78515 (Hair object - Node types design) for more info regarding hair object node design

Hair simulation properties
I don’t currently have a strong opinion about where to place simulation related controls/UI. Perhaps this could be integrated somehow with particle nodes? See example of simulation influence node in #78515 (Hair object - Node types design). We should check with @JacquesLucke, since he is working on particle nodes and physics.

Alembic cache

Reading curves from alembic file as hair is supposed to be implemented as noted in the project description #68981 . I've been going back and forth regarding if I think alembic settings should be placed in the Hair object UI or in the Input node in the node network. I ended up with the conclusion that alembic settings should be placed in the hair object node networks input node.

{F8664085, height = 400}

Notes on guide curves geometry data

This is likely relatable to
https://developer.blender.org/T76659

Deformed instances
Imagine the blue poly strip on the image to the left is a deformed instance along a guide curve. The goal is to have it conform to the normal of the surface of the growth mesh (head geometry). This type of workflow is important for creating hair for real time rendering (e.g games) or feathers for offline rendering

{F8664030, height = 400}

Sometimes the sampled normals from the surface is too noisy (ear area) and needs to be averaged based on neighboring guide curve vertex normals. The smoothing should propably be done with an operator that is triggered by the user.

{F8664033, height = 400}

Normal per guide curve vertex
Transfer normal vector from growth mesh surface (CYAN) to guide curve vertices. This normal vector is not used for shading, but for aligning tilt/twist of instances to the growth mesh surface. This is very important for creating hair cards for real time graphics/games.

Guide curve vertices that does not get a ray hit from growth mesh surface can inherit normal vector from the closest guide curve vertex that got a ray hit (YELLOW). We could also use this normal vector to displace the guide curves along the normal of the growth mesh surface with the deform node that is described in the Hair object node design https://developer.blender.org/T78515

If transferring normal vectors from the growth mesh is slow, perhaps it’s a good idea to transfer normals with an operator that is run by the user when desired. I guess it’s important to note that we would not want normal transfer to happen post simulation

It seems likely that this task is related to storing custom data on hair vertices: #76659 (Geometry Attributes Design)

Direction per guide curve vertex
Another important vector to use would be the direction of the guide curve. The direction of the last guide curve vertex will need to be inherited from its closest neighbor. The direction could be used by the tilt for deformed instances and also, the deform node that is described here: #78515 (Hair object - Node types design)

Tangent per guide curve vertex

The cross product of the transferred surface normal and guide curve direction would result in a tangent. One potential problem is that the transferred surface normal and guide curve direction could sometimes be almost aligned (eg when hair is pointing along the surface normal). I’m not sure how big of a problem that could be. In case the tangent is zero, perhaps it should just get some arbitrary vector? Perhaps pointing along the X-axis?

The tangent can be used by the deform node that is described here: #78515 (Hair object - Node types design)

Operators

IMPORTANT: Nodes are to be developed first, so operators will not be a first priority

select random
existing operator that is extremely useful while grooming. Selects random hair/points

transfer normals from growth mesh
Transfer growth mesh normals to guide curves. Vertecies that does not get a ray hit to growth mesh should inherit from closest guide curve vertex on same guide curve. Normals on guide curves can be useful for aligning instanced mesh. Very important for real time hair (eg hair cards) or feathers in off line rendering

smooth guide curve normals
sometimes growth mesh normals might be pointing in a lot of different directions (close to an ear for example). Then smoothing out normals can be useful. This is very simililair to smooth curve tilt for curves

{F8664672, height = 150}

create guide curves from curves
Useful for interoperability between other softwares. I think it would be useful to rearrange vertex order per guide curve so that vertex index 0 is closest to growth mesh surface. Only the two ends of the curve needs to be sampled to determine which is closer to the growth mesh. This would be very useful for converting hair using old hair system to the new hair system

{F8664681, height = 400}

resample guide curves
Based on current selection. Change number of vertices per guide curve. Vertices should always be equally spaced. When going from a low amount of vertices to a higher amount, it might be needed to "change curvature" in order to avoid linear interpolation between each new vertex. The current operator Rekey does a very good job, but doesn't solve issues where hair vertices that is not evenly spaced per hair.

{F8664686, height = 200}

Create curves from hair nodes
Convert current hair node setup to curves. Useful for interoperability with other softwares. Current operator hides in the particle system modifier

{F8664691, height= 300}}

Tilt normal
Tilt normal on selected guide curve vertices. Very similair to tilt operator for curves

{F8664702, height= 200}

select by length
usable for deleting/pruning very small hairs. Small hairs can sometimes be accidentally too short by using the "cut brush"

{F8664699, height= 200}

smooth length
smooth length on selected guide curves by sampling surrounding guide curves. This is useful for making sure there are no guide curves that are shorter or longer than they should be

{F8664705, height = 200}

IMPORTANT: Please note that this document is subject to change and will most likely not represent the final product of the new hair object in Blender --- **Reference links** Hair object - project description #68981 (New curves object type) Hair object - node design #78515 (Hair object - Node types design) --- ## Hair object design **Guide curves** This is a list of guides in the hair object. "myGuides" in image example. On the same hair object there can be multiple guide curves ("eyebrows", "hair", "eyelashes" etc). Guide curves are the curves are what the user grooms with the particle brush. The guide curves are sourced into the node tree graph via an input node. **Growth mesh** This is the mesh that the guide curves are attached to. **Node tree** This is a slot that referers to the node tree containing the nodes for creating and deforming the instanced hair curves. See design task #78515 (Hair object - Node types design) for more info regarding hair object node design **Hair simulation properties** I don’t currently have a strong opinion about where to place simulation related controls/UI. Perhaps this could be integrated somehow with particle nodes? See example of **simulation influence node** in #78515 (Hair object - Node types design). We should check with @JacquesLucke, since he is working on particle nodes and physics. |![image.png](https://archive.blender.org/developer/F8664056/image.png)|![image.png](https://archive.blender.org/developer/F8664059/image.png)| | -- | -- | --- ## Alembic cache Reading curves from alembic file as hair is supposed to be implemented as noted in the project description #68981 . I've been going back and forth regarding if I think alembic settings should be placed in the Hair object UI or in the Input node in the node network. I ended up with the conclusion that alembic settings should be placed in the hair object node networks **input node**. {[F8664085](https://archive.blender.org/developer/F8664085/image.png), height = 400} ![image.png](https://archive.blender.org/developer/F8664063/image.png) --- **Notes on guide curves geometry data** This is likely relatable to https://developer.blender.org/T76659 Deformed instances Imagine the blue poly strip on the image to the left is a deformed instance along a guide curve. The goal is to have it conform to the normal of the surface of the growth mesh (head geometry). This type of workflow is important for creating hair for real time rendering (e.g games) or feathers for offline rendering {[F8664030](https://archive.blender.org/developer/F8664030/image.png), height = 400} Sometimes the sampled normals from the surface is too noisy (ear area) and needs to be averaged based on neighboring guide curve vertex normals. The smoothing should propably be done with an operator that is triggered by the user. {[F8664033](https://archive.blender.org/developer/F8664033/image.png), height = 400} **Normal per guide curve vertex** Transfer normal vector from growth mesh surface (CYAN) to guide curve vertices. This normal vector is not used for shading, but for aligning tilt/twist of instances to the growth mesh surface. This is very important for creating hair cards for real time graphics/games. Guide curve vertices that does not get a ray hit from growth mesh surface can inherit normal vector from the closest guide curve vertex that got a ray hit (YELLOW). We could also use this normal vector to displace the guide curves along the normal of the growth mesh surface with the deform node that is described in the Hair object node design https://developer.blender.org/T78515 If transferring normal vectors from the growth mesh is slow, perhaps it’s a good idea to transfer normals with an operator that is run by the user when desired. I guess it’s important to note that we would not want normal transfer to happen post simulation It seems likely that this task is related to storing custom data on hair vertices: #76659 (Geometry Attributes Design) ![image.png](https://archive.blender.org/developer/F8664042/image.png) --- **Direction per guide curve vertex** Another important vector to use would be the direction of the guide curve. The direction of the last guide curve vertex will need to be inherited from its closest neighbor. The direction could be used by the tilt for deformed instances and also, the deform node that is described here: #78515 (Hair object - Node types design) ![image.png](https://archive.blender.org/developer/F8664045/image.png) --- ## Tangent per guide curve vertex The cross product of the transferred surface normal and guide curve direction would result in a tangent. One potential problem is that the transferred surface normal and guide curve direction could sometimes be almost aligned (eg when hair is pointing along the surface normal). I’m not sure how big of a problem that could be. In case the tangent is zero, perhaps it should just get some arbitrary vector? Perhaps pointing along the X-axis? The tangent can be used by the deform node that is described here: #78515 (Hair object - Node types design) ![image.png](https://archive.blender.org/developer/F8664052/image.png) --- ## Operators IMPORTANT: Nodes are to be developed first, so operators will not be a first priority **select random** existing operator that is extremely useful while grooming. Selects random hair/points ![image.png](https://archive.blender.org/developer/F8664665/image.png) **transfer normals from growth mesh** Transfer growth mesh normals to guide curves. Vertecies that does not get a ray hit to growth mesh should inherit from closest guide curve vertex on same guide curve. Normals on guide curves can be useful for aligning instanced mesh. Very important for real time hair (eg hair cards) or feathers in off line rendering ![image.png](https://archive.blender.org/developer/F8664042/image.png) **smooth guide curve normals** sometimes growth mesh normals might be pointing in a lot of different directions (close to an ear for example). Then smoothing out normals can be useful. This is very simililair to **smooth curve tilt** for curves {[F8664672](https://archive.blender.org/developer/F8664672/image.png), height = 150} **create guide curves from curves** Useful for interoperability between other softwares. I think it would be useful to rearrange vertex order per guide curve so that vertex index 0 is closest to growth mesh surface. Only the two ends of the curve needs to be sampled to determine which is closer to the growth mesh. This would be very useful for converting hair using old hair system to the new hair system {[F8664681](https://archive.blender.org/developer/F8664681/image.png), height = 400} **resample guide curves** Based on current selection. Change number of vertices per guide curve. Vertices should always be equally spaced. When going from a low amount of vertices to a higher amount, it might be needed to "change curvature" in order to avoid linear interpolation between each new vertex. The current operator **Rekey** does a very good job, but doesn't solve issues where hair vertices that is not evenly spaced per hair. {[F8664686](https://archive.blender.org/developer/F8664686/image.png), height = 200} **Create curves from hair nodes** Convert current hair node setup to curves. Useful for interoperability with other softwares. Current operator hides in the **particle system modifier** {[F8664691](https://archive.blender.org/developer/F8664691/image.png), height= 300}} **Tilt normal** Tilt normal on selected guide curve vertices. Very similair to tilt operator for curves {[F8664702](https://archive.blender.org/developer/F8664702/image.png), height= 200} **select by length** usable for deleting/pruning very small hairs. Small hairs can sometimes be accidentally too short by using the "cut brush" {[F8664699](https://archive.blender.org/developer/F8664699/image.png), height= 200} **smooth length** smooth length on selected guide curves by sampling surrounding guide curves. This is useful for making sure there are no guide curves that are shorter or longer than they should be {[F8664705](https://archive.blender.org/developer/F8664705/image.png), height = 200}

Daniel Bystedt commented

2020-07-04 17:14:01 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

Daniel Bystedt commented

2020-07-04 17:14:01 +02:00

Added subscribers: @sebbas, @DanielBystedt, @JacquesLucke, @lichtwerk, @ideasman42

Joseph Brandenburg commented

2020-07-04 22:00:49 +02:00

Added subscriber: @Josephbburg

Joseph Brandenburg commented

2020-07-04 22:00:49 +02:00

Hello, I created a discussion thread on Devtalk, since I expect people will have a lot to say about this. (And we're not supposed to use the task page for discussion, right?)
Feel free to remove this comment and put the discussion thread in the task, if you want.

Hello, I created a [discussion thread on Devtalk](https://devtalk.blender.org/t/discussion-thread-for-new-hair-object/14220), since I expect people will have a lot to say about this. (And we're not supposed to use the task page for discussion, right?) Feel free to remove this comment and put the discussion thread in the task, if you want.

Jacques Lucke commented

2020-07-06 16:38:52 +02:00

Thanks for preparing this. :)

It seems you put a lot of focus on the transfer of a coordinate system along a hair strand. I understand that this is important, but it's probably not the right abstraction level for this task. Also, the solution you propose probably won't work well, for the reason you mentioned already. I'm quite sure that this will become a problem, because hair goes in many directions and some will come close to the singularity with high probability. It's probably best to just define a coordinate system at the root of a strand and then move that along the hair (instead of the normal and tangent separately). I've implemented something similar for Animation Nodes in the past and Blender probably has some code for this already, because it's doing the same thing when you select the "Minimum" twist method on curves.

The other examples for operators seem sensible. I don't really have anything to add to them yet.

Thanks for preparing this. :) It seems you put a lot of focus on the transfer of a coordinate system along a hair strand. I understand that this is important, but it's probably not the right abstraction level for this task. Also, the solution you propose probably won't work well, for the reason you mentioned already. I'm quite sure that this will become a problem, because hair goes in many directions and some will come close to the singularity with high probability. It's probably best to just define a coordinate system at the root of a strand and then move that along the hair (instead of the normal and tangent separately). I've implemented something similar for Animation Nodes in the past and Blender probably has some code for this already, because it's doing the same thing when you select the "Minimum" twist method on curves. The other examples for operators seem sensible. I don't really have anything to add to them yet.

Daniel Bystedt commented

2020-07-06 17:03:59 +02:00

In #78606#973963, @JacquesLucke wrote:
Thanks for preparing this. :)

It seems you put a lot of focus on the transfer of a coordinate system along a hair strand. I understand that this is important, but it's probably not the right abstraction level for this task. Also, the solution you propose probably won't work well, for the reason you mentioned already. I'm quite sure that this will become a problem, because hair goes in many directions and some will come close to the singularity with high probability. It's probably best to just define a coordinate system at the root of a strand and then move that along the hair (instead of the normal and tangent separately). I've implemented something similar for Animation Nodes in the past and Blender probably has some code for this already, because it's doing the same thing when you select the "Minimum" twist method on curves.

The other examples for operators seem sensible. I don't really have anything to add to them yet.

Thanks for the feedback, @JacquesLucke. I'm very open to any type of solution for aligning deformed instances to the growth mesh. Perhaps I was to keen on suggesting a solution instead of presenting clearly what the goal is. I'm just going to drop the image of the "goal shape" of deformed instances in this post so that it's clear.

https://dev-files.blender.org/file/data/5hmrqbjg42uuipiu5kkz/PHID-FILE-ker5nuslhpfll7gdempy/image.png

Cheers :-D

> In #78606#973963, @JacquesLucke wrote: > Thanks for preparing this. :) > > It seems you put a lot of focus on the transfer of a coordinate system along a hair strand. I understand that this is important, but it's probably not the right abstraction level for this task. Also, the solution you propose probably won't work well, for the reason you mentioned already. I'm quite sure that this will become a problem, because hair goes in many directions and some will come close to the singularity with high probability. It's probably best to just define a coordinate system at the root of a strand and then move that along the hair (instead of the normal and tangent separately). I've implemented something similar for Animation Nodes in the past and Blender probably has some code for this already, because it's doing the same thing when you select the "Minimum" twist method on curves. > > The other examples for operators seem sensible. I don't really have anything to add to them yet. Thanks for the feedback, @JacquesLucke. I'm very open to any type of solution for aligning deformed instances to the growth mesh. Perhaps I was to keen on suggesting a solution instead of presenting clearly what the goal is. I'm just going to drop the image of the "goal shape" of deformed instances in this post so that it's clear. https://dev-files.blender.org/file/data/5hmrqbjg42uuipiu5kkz/PHID-FILE-ker5nuslhpfll7gdempy/image.png Cheers :-D

Brecht Van Lommel changed title from ~~Hair object - design~~ to Hair object - design proposal

2020-07-06 17:32:54 +02:00

Brecht Van Lommel commented

2020-07-06 18:11:59 +02:00

Added subscriber: @brecht

Brecht Van Lommel commented

2020-07-06 18:11:59 +02:00

Hair geometry consistents of curves that may be used as guides, or that may be the final geometry. So I generally refer to them as curves, not guides.
#74967 (Geometry Nodes Design) is a related task. We want a consistent modifier stack and nodes design for all geometry types. The way I see it, the modifier stack can continue to exist, with individual modifiers that can contain more complex node graphs.
Physics simulation would be a node / modifier, referencing a simulation datablock. In the simplest case, that simulation is just a preset that exposes a few high-level parameters to the node / modifier, and you wouldn't have to dig into the simulation node setup.
For hair cards, the end results would be mesh geometry, not hair. Blender objects don't currently supporting having different geometry types as input and output, but this is something we want to support to make such node setups more self-contained without needing to create multiple objects. The other way around is also imaginable, where you model a mesh and through various nodes, the end result is hair curves distributed within the mesh.
Converting to curves should not be necessary for interop, since Hair geometry should export to appropriate curve primitives in USD / Alembic (but converting may be useful for other reasons).

* Hair geometry consistents of curves that may be used as guides, or that may be the final geometry. So I generally refer to them as curves, not guides. * #74967 (Geometry Nodes Design) is a related task. We want a consistent modifier stack and nodes design for all geometry types. The way I see it, the modifier stack can continue to exist, with individual modifiers that can contain more complex node graphs. * Physics simulation would be a node / modifier, referencing a simulation datablock. In the simplest case, that simulation is just a preset that exposes a few high-level parameters to the node / modifier, and you wouldn't have to dig into the simulation node setup. * For hair cards, the end results would be mesh geometry, not hair. Blender objects don't currently supporting having different geometry types as input and output, but this is something we want to support to make such node setups more self-contained without needing to create multiple objects. The other way around is also imaginable, where you model a mesh and through various nodes, the end result is hair curves distributed within the mesh. * Converting to curves should not be necessary for interop, since Hair geometry should export to appropriate curve primitives in USD / Alembic (but converting may be useful for other reasons).

Daniel Bystedt commented

2020-07-07 06:02:39 +02:00

Thanks for the feedback @brecht. This really helps with refining the Hair object design proposal :-)

In #78606#974035, @brecht wrote:

Hair geometry consistents of curves that may be used as guides, or that may be the final geometry. So I generally refer to them as curves, not guides.

I feel that it is important to distinguish the hair curves that the user groom with the particle edit brush and the hair curves that are procedurally generated by nodes/modifiers with two different names. Both for communicating clearly and also to align with the terminology used in other software used for grooming.

Based on your input I will use the following names
Guide curves = Curves that the user groom with the particle edit brush (no primarily render visibility)
Hair curves = Curves that are procedurally generated with nodes/modifiers (visible in render)

#74967 (Geometry Nodes Design) is a related task. We want a consistent modifier stack and nodes design for all geometry types. The way I see it, the modifier stack can continue to exist, with individual modifiers that can contain more complex node graphs.

Good point. I hadn't concidered modifiers in the hair object design proposal. I'll have a look at that

Physics simulation would be a node / modifier, referencing a simulation datablock. In the simplest case, that simulation is just a preset that exposes a few high-level parameters to the node / modifier, and you wouldn't have to dig into the simulation node setup.

That sounds really good and aligns with what @JacquesLucke wrote above

For hair cards, the end results would be mesh geometry, not hair. Blender objects don't currently supporting having different geometry types as input and output, but this is something we want to support to make such node setups more self-contained without needing to create multiple objects. The other way around is also imaginable, where you model a mesh and through various nodes, the end result is hair curves distributed within the mesh.

Great feedback! I think that this is something to consider for further discussions. It will be mostly up to you developers to decide on how instances and deformed instances technically should be implemented. I'm thinking that I should add an object output node for geometry instances (trees/rocks) and deformed geometry instances (game hair / feathers) in #78515 (Hair object - Node types design). The only thing that is important to me is to add functionality to add deformed geometry instances with random/multiple geometry input so that we can get random hair shapes and uv for feathers and game hair (current modifier particle instance does not support this)

Converting to curves should not be necessary for interop, since Hair geometry should export to appropriate curve primitives in USD / Alembic (but converting may be useful for other reasons).

I totally agree when it comes to export/output of curves. Importing curves from another software and converting them to hair would be really useful, since that functionality is currently missing in Blender (unless using external addons)

Thanks for the feedback @brecht. This really helps with refining the Hair object design proposal :-) > In #78606#974035, @brecht wrote: > * Hair geometry consistents of curves that may be used as guides, or that may be the final geometry. So I generally refer to them as curves, not guides. I feel that it is important to distinguish the hair curves that the user **groom** with the particle edit brush and the hair curves that are **procedurally generated** by nodes/modifiers with two different names. Both for communicating clearly and also to align with the terminology used in other software used for grooming. Based on your input I will use the following names **Guide curves** = Curves that the user groom with the particle edit brush (no primarily render visibility) **Hair curves** = Curves that are procedurally generated with nodes/modifiers (visible in render) > * #74967 (Geometry Nodes Design) is a related task. We want a consistent modifier stack and nodes design for all geometry types. The way I see it, the modifier stack can continue to exist, with individual modifiers that can contain more complex node graphs. Good point. I hadn't concidered modifiers in the hair object design proposal. I'll have a look at that > * Physics simulation would be a node / modifier, referencing a simulation datablock. In the simplest case, that simulation is just a preset that exposes a few high-level parameters to the node / modifier, and you wouldn't have to dig into the simulation node setup. That sounds really good and aligns with what @JacquesLucke wrote above > * For hair cards, the end results would be mesh geometry, not hair. Blender objects don't currently supporting having different geometry types as input and output, but this is something we want to support to make such node setups more self-contained without needing to create multiple objects. The other way around is also imaginable, where you model a mesh and through various nodes, the end result is hair curves distributed within the mesh. Great feedback! I think that this is something to consider for further discussions. It will be mostly up to you developers to decide on how instances and deformed instances technically should be implemented. I'm thinking that I should add an **object output** node for geometry instances (trees/rocks) and deformed geometry instances (game hair / feathers) in #78515 (Hair object - Node types design). The only thing that is important to me is to add functionality to add deformed geometry instances with random/multiple geometry input so that we can get random hair shapes and uv for feathers and game hair (current modifier particle instance does not support this) > * Converting to curves should not be necessary for interop, since Hair geometry should export to appropriate curve primitives in USD / Alembic (but converting may be useful for other reasons). I totally agree when it comes to export/output of curves. Importing curves from another software and converting them to hair would be really useful, since that functionality is currently missing in Blender (unless using external addons)

Brecht Van Lommel commented

2020-07-07 11:08:38 +02:00

In #78606#974279, @DanielBystedt wrote:
I feel that it is important to distinguish the hair curves that the user groom with the particle edit brush and the hair curves that are procedurally generated by nodes/modifiers with two different names. Both for communicating clearly and also to align with the terminology used in other software used for grooming.

Based on your input I will use the following names
Guide curves = Curves that the user groom with the particle edit brush (no primarily render visibility)
Hair curves = Curves that are procedurally generated with nodes/modifiers (visible in render)

But what does it mean exactly to give them two different names? Are you also proposing that they would be two different data structures, that we would have two different Hair geometry types? Or would it be the same data structure but a different name is used in different parts of the UI? Or is it just something to describe workflow, but there would be only one name in the Blender UI?

At least with the design I had in mind, there would be one data structure, and nodes and modifiers would work on both curves used for guiding and rendering. The distinction between the different types of curves would basically be a node that converts hair geometry to more dense hair geometry, like a subdivision surface modifier for meshes.

> In #78606#974279, @DanielBystedt wrote: > I feel that it is important to distinguish the hair curves that the user **groom** with the particle edit brush and the hair curves that are **procedurally generated** by nodes/modifiers with two different names. Both for communicating clearly and also to align with the terminology used in other software used for grooming. > > Based on your input I will use the following names > **Guide curves** = Curves that the user groom with the particle edit brush (no primarily render visibility) > **Hair curves** = Curves that are procedurally generated with nodes/modifiers (visible in render) But what does it mean exactly to give them two different names? Are you also proposing that they would be two different data structures, that we would have two different Hair geometry types? Or would it be the same data structure but a different name is used in different parts of the UI? Or is it just something to describe workflow, but there would be only one name in the Blender UI? At least with the design I had in mind, there would be one data structure, and nodes and modifiers would work on both curves used for guiding and rendering. The distinction between the different types of curves would basically be a node that converts hair geometry to more dense hair geometry, like a subdivision surface modifier for meshes.

Daniel Bystedt commented

2020-07-07 12:02:27 +02:00

In #78606#974364, @brecht wrote:

In #78606#974279, @DanielBystedt wrote:
I feel that it is important to distinguish the hair curves that the user groom with the particle edit brush and the hair curves that are procedurally generated by nodes/modifiers with two different names. Both for communicating clearly and also to align with the terminology used in other software used for grooming.

Based on your input I will use the following names
Guide curves = Curves that the user groom with the particle edit brush (no primarily render visibility)
Hair curves = Curves that are procedurally generated with nodes/modifiers (visible in render)

But what does it mean exactly to give them two different names? Are you also proposing that they would be two different data structures, that we would have two different Hair geometry types? Or would it be the same data structure but a different name is used in different parts of the UI? Or is it just something to describe workflow, but there would be only one name in the Blender UI?

At least with the design I had in mind, there would be one data structure, and nodes and modifiers would work on both curves used for guiding and rendering. The distinction between the different types of curves would basically be a node that converts hair geometry to more dense hair geometry, like a subdivision surface modifier for meshes.

When I read your description it seems to align with how I picture the hair object as well. Much like a mesh object with modifiers where each modifier is a node in the hair object node graph editor and

The purpose of having two different names (Guide curves & Hair curves) is mainly for communicating which "thing" we are talking about during development and describing workflow. It's basically the same as things are in the current version of blender where there are particles and children. I want to change the name so the definition is more clear and also to align with the terminology used in other software used for grooming.

Here is an example of where the guide curves are accessed in the hair object UI mockup. This specific part is very much how hair works today in blender (i.e. you currently select a specific particle setting in the hair particle properties UI in order to groom those particles.

> In #78606#974364, @brecht wrote: >> In #78606#974279, @DanielBystedt wrote: >> I feel that it is important to distinguish the hair curves that the user **groom** with the particle edit brush and the hair curves that are **procedurally generated** by nodes/modifiers with two different names. Both for communicating clearly and also to align with the terminology used in other software used for grooming. >> >> Based on your input I will use the following names >> **Guide curves** = Curves that the user groom with the particle edit brush (no primarily render visibility) >> **Hair curves** = Curves that are procedurally generated with nodes/modifiers (visible in render) > > But what does it mean exactly to give them two different names? Are you also proposing that they would be two different data structures, that we would have two different Hair geometry types? Or would it be the same data structure but a different name is used in different parts of the UI? Or is it just something to describe workflow, but there would be only one name in the Blender UI? > > At least with the design I had in mind, there would be one data structure, and nodes and modifiers would work on both curves used for guiding and rendering. The distinction between the different types of curves would basically be a node that converts hair geometry to more dense hair geometry, like a subdivision surface modifier for meshes. When I read your description it seems to align with how I picture the hair object as well. Much like a mesh object with modifiers where each modifier is a node in the hair object node graph editor and The purpose of having two different names (Guide curves & Hair curves) is mainly for communicating which "thing" we are talking about during development and describing workflow. It's basically the same as things are in the current version of blender where there are **particles** and **children**. I want to change the name so the definition is more clear and also to align with the terminology used in other software used for grooming. Here is an example of where the **guide curves** are accessed in the hair object UI mockup. This specific part is very much how hair works today in blender (i.e. you currently select a specific particle setting in the hair particle properties UI in order to groom those particles. ![image.png](https://archive.blender.org/developer/F8675192/image.png)

Jacques Lucke commented

2020-07-07 12:16:49 +02:00

On a high level, I have the following design in mind currently:

There is a Geometry and Simulation ID type.
There is a Geometry Node Editor and a Simulation Node Editor.
Both of these ID types contain a node tree that is edited in the respective editor.
Nodes in these node trees can reference other data in the .blend file that they depend on.
Other data in the .blend file can reference specific data/nodes within a Geometry and Simulation node tree. (Similar to what the Simulation modifier is doing currently.)
Geometry node groups that have a single input and a single output geometry of the same type can be used in the modifier stack.
Within a geometry/simulation node tree different kinds of geometry can be generated/simulated. That includes meshes, point clouds, hair, volumes, curves, ...

[EDIT] Maybe I should have posted this in one of the other threads regarding hair or geometry node design..

On a high level, I have the following design in mind currently: * There is a `Geometry` and `Simulation` ID type. * There is a `Geometry Node Editor` and a `Simulation Node Editor`. * Both of these ID types contain a node tree that is edited in the respective editor. * Nodes in these node trees can reference other data in the .blend file that they depend on. * Other data in the .blend file can reference specific data/nodes within a `Geometry` and `Simulation` node tree. (Similar to what the `Simulation` modifier is doing currently.) * Geometry node groups that have a single input and a single output geometry of the same type can be used in the modifier stack. * Within a geometry/simulation node tree different kinds of geometry can be generated/simulated. That includes meshes, point clouds, hair, volumes, curves, ... [EDIT] Maybe I should have posted this in one of the other threads regarding hair or geometry node design..

Sam Van Hulle commented

2020-07-20 18:01:53 +02:00

Added subscriber: @frameshift

Pipeliner commented

2020-07-22 12:01:09 +02:00

Added subscriber: @Pipeliner

Kenzie commented

2020-08-05 23:06:48 +02:00

Added subscriber: @KenzieMac130

Mark Koczwara commented

2020-08-08 12:13:28 +02:00

Added subscriber: @KidTempo

Daniel Salazar commented

2020-08-11 00:34:40 +02:00

Added subscriber: @zanqdo

Don commented

2020-08-22 17:25:13 +02:00

Added subscriber: @DonCoyote

CobraA commented

2020-09-13 18:37:22 +02:00

Added subscriber: @CobraA

CobraA commented

2020-09-13 18:37:22 +02:00

Have you guys checked Pixar's system? they made a SIGGRAPH talk & published some docs.

Bruno commented

2020-09-15 08:34:55 +02:00

Added subscriber: @Brunomendesgussoni

Bruno commented

2020-09-22 06:59:32 +02:00

Removed subscriber: @Brunomendesgussoni

sj commented

2020-11-21 08:08:58 +01:00

Added subscriber: @nox.cg

Donald A. Dade commented

2021-05-04 22:08:03 +02:00

Added subscriber: @ddade

Roman commented

2021-09-08 13:17:28 +02:00

Added subscriber: @rwman

Roughy commented

2022-02-21 19:35:30 +01:00

Added subscriber: @Roughy

Basil commented

2022-02-27 21:24:41 +01:00

Added subscriber: @Defka

Seby commented

2022-04-27 14:17:53 +02:00

Added subscriber: @1seby

Floreum commented

2022-06-01 11:43:47 +02:00

Added subscriber: @Floreum

Robert Hintz commented

2022-07-13 15:34:59 +02:00

Added subscriber: @Robert-Hintz

Robert Hintz commented

2022-07-13 15:34:59 +02:00

There needs to be a function where you can create vector fields to groom short fur or hair. Houdini and the Ornatrix plugin for Maya have this function.
https://www.sidefx.com/docs/houdini/shelf/sop_groom_curveadvect.html
https://ephere.com/plugins/autodesk/maya/ornatrix/docs/3/Surface_Comb_Operator.html

There needs to be a function where you can create vector fields to groom short fur or hair. Houdini and the Ornatrix plugin for Maya have this function. https://www.sidefx.com/docs/houdini/shelf/sop_groom_curveadvect.html https://ephere.com/plugins/autodesk/maya/ornatrix/docs/3/Surface_Comb_Operator.html

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Hair object - design proposal #78606

Hair object design

Alembic cache

Tangent per guide curve vertex

Operators