Custom normals design for curves #100859

New Issue

Hans Goudey · 2022-09-06T16:59:29+02:00

Hans Goudey commented

2022-09-06 16:59:29 +02:00

Currently curve normals are calculated automatically. We have two modes, Z-Up, and "Minimum Twist".
We probably want to introduce X-Up and Y-Up too, just for consistency, but this won't give enough control in some cases still. So we still need some ability to make normals more custom.

Option 1: Custom Normals
One solution is to use a "Set Custom Normals" node. However, that requires accepting that the normals might not be orthogonal to the tangent, or making it a lossy operation.

Option 2: "up" Attribute
Another option is adding another attribute that influences the automatic calculation of normals like tilt does currently.
The up attribute would be an initial starting direction for the normal. The final normal would be the direction most aligned with the up direction that's still orthogonal to the tangent.

Currently curve normals are calculated automatically. We have two modes, Z-Up, and "Minimum Twist". We probably want to introduce X-Up and Y-Up too, just for consistency, but this won't give enough control in some cases still. So we still need some ability to make normals more custom. **Option 1: Custom Normals** One solution is to use a "Set Custom Normals" node. However, that requires accepting that the normals might not be orthogonal to the tangent, or making it a lossy operation. **Option 2: "up" Attribute** Another option is adding another attribute that influences the automatic calculation of normals like `tilt` does currently. The `up` attribute would be an initial starting direction for the normal. The final normal would be the direction most aligned with the up direction that's still orthogonal to the tangent.

❤️ 1

Hans Goudey commented

2022-09-06 16:59:29 +02:00

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

Hans Goudey commented

2022-09-06 16:59:29 +02:00

Added subscriber: @HooglyBoogly

Iliya Katushenock commented

2022-09-06 17:25:40 +02:00

Added subscriber: @mod_moder

Iliya Katushenock commented

2022-09-06 17:25:40 +02:00

I think that the normal should only be set for the first point of the curve (and then auto calculation)
And also, changing the curve should automatically change the normal, but for this, the change in the curve must have a basis. Since we can't change a simple translation into a transformation with a matrix and a translation vector, it's better to give this right to the user.
That is, we recognize that the seed of the normal was set by the user. But if the curve has been changed, then the correctness of the normal is not guaranteed. The user himself must write it down the way it is in his opinion.
However, the properties of the normal (length, perpendicularity) remain the same. If the specified normal does not match this, or it did after transforming the curve, the custom normal will be changed to correct it.

I think that the normal should only be set for the first point of the curve (and then auto calculation) And also, changing the curve should automatically change the normal, but for this, the change in the curve must have a basis. Since we can't change a simple translation into a transformation with a matrix and a translation vector, it's better to give this right to the user. That is, we recognize that the seed of the normal was set by the user. But if the curve has been changed, then the correctness of the normal is not guaranteed. The user himself must write it down the way it is in his opinion. However, the properties of the normal (length, perpendicularity) remain the same. If the specified normal does not match this, or it did after transforming the curve, the custom normal will be changed to correct it.

Yuro commented

2022-09-06 17:26:40 +02:00

Added subscriber: @Yuro

Hadrien Brissaud commented

2022-09-06 18:22:27 +02:00

Added subscriber: @hadrien

Hadrien Brissaud commented

2022-09-06 18:22:27 +02:00

In #100859#1413127, @mod_moder wrote:
I think that the normal should only be set for the first point of the curve (and then auto calculation)
And also, changing the curve should automatically change the normal, but for this, the change in the curve must have a basis. Since we can't change a simple translation into a transformation with a matrix and a translation vector, it's better to give this right to the user.
That is, we recognize that the seed of the normal was set by the user. But if the curve has been changed, then the correctness of the normal is not guaranteed. The user himself must write it down the way it is in his opinion.
However, the properties of the normal (length, perpendicularity) remain the same. If the specified normal does not match this, or it did after transforming the curve, the custom normal will be changed to correct it.

I think this could work best in order to achieve continuity along the curve : specify first point normal (or let Blender figure it out using the up attribute), then compute the rest through parallel transport or some other technique.

> In #100859#1413127, @mod_moder wrote: > I think that the normal should only be set for the first point of the curve (and then auto calculation) > And also, changing the curve should automatically change the normal, but for this, the change in the curve must have a basis. Since we can't change a simple translation into a transformation with a matrix and a translation vector, it's better to give this right to the user. > That is, we recognize that the seed of the normal was set by the user. But if the curve has been changed, then the correctness of the normal is not guaranteed. The user himself must write it down the way it is in his opinion. > However, the properties of the normal (length, perpendicularity) remain the same. If the specified normal does not match this, or it did after transforming the curve, the custom normal will be changed to correct it. I think this could work best in order to achieve continuity along the curve : specify first point normal (or let Blender figure it out using the up attribute), then compute the rest through parallel transport or some other technique.

Hans Goudey commented

2022-09-06 18:31:55 +02:00

Ah, I forgot to mention that the up attribute could be added to the point of curve attribute domain. If it was on the curve domain it would work like you suggested.
This behavior could also be achieved with a more explicit "Set Custom Normals" node, or maybe even something more general.

Ah, I forgot to mention that the up attribute could be added to the point of curve attribute domain. If it was on the curve domain it would work like you suggested. This behavior could also be achieved with a more explicit "Set Custom Normals" node, or maybe even something more general.

Bastien Montagne commented

2022-09-08 11:46:25 +02:00

Added subscriber: @mont29

Bastien Montagne commented

2022-09-08 11:46:26 +02:00

I think a custom normal is different than that 'up' attribute? The former would indeed allow non-orthogonal normals, just like it does with meshes. The later is only a way to choose a direction on the normal plane of the curve, which would still always produce a 'real' orthogonal normal.

So I think option 2 would make more sense for now, not even sure if option 1 would have practical usages with curves actually? Might be missing some important points here though.

I think a custom normal is different than that 'up' attribute? The former would indeed allow non-orthogonal normals, just like it does with meshes. The later is only a way to choose a direction on the normal plane of the curve, which would still always produce a 'real' orthogonal normal. So I think option 2 would make more sense for now, not even sure if option 1 would have practical usages with curves actually? Might be missing some important points here though.

Paul Larson commented

2022-09-10 09:14:39 +02:00

Added subscriber: @GeorgiaPacific

Luis Pereira commented

2022-09-10 23:37:05 +02:00

Added subscriber: @LuisPereira

Luis Pereira commented

2022-09-10 23:37:05 +02:00

Hi!
I'm new here but I'm very interested in this design task. In fact, I've more or less built my own custom node group (in current Blender) that achieves something very similar to the design goal (I'm attaching a blend file with that node group). So hopefully my thoughts will be of some use (apologies for the lengthy post... I've spent quite a bit of time thinking about this).

An application:
The main application I have in mind is something like the image below (which is from the blend file I attached at the end), where we wrap strips of fabric/bandages around a character's body.

Overview of the geo nodes in the application:
If you enlarge the picture, you should be able to see the curve from which the bandages are generated using geo nodes. The geo nodes are doing 3 things here:

slightly shrinkwrapping the curve around the arm (though it started pretty close);
(the main part) adjusting the curve's tilt (using Set Curve Tilt Node and plenty of math) so the curve's normals point in about the same direction as the mesh normals (transferred to the curve from the mesh). Naturally, the mesh's normals might not be precisely perpendicular to the curve's tangents (although the shrinkwrapping ensures they'll be close to perpendicular), and I address this as suggested in option 2, by projecting the mesh's normals onto the planes perpendicular to the respective tangents, then renormalizing;
extruding the curve.

A key difficulty
In effect, my node group is more or less achieving option 2 via the Set Curve Tilt Node, though this required a lot of care and some frustrating mistakes. At first sight, one might think that building this node group is just a matter of determining the angles between the current normals and the intended normals (which is just a bunch of linear algebra plus trigonometry), then setting that as the tilt (while using the tangent to decide if the tilt is positive or negative).
However... the naive procedure above will invariably lead to examples as below, where the curve does a 360 degree flip over a short segment.

Fixing these 360 flips was a huge pain, since normally (i.e. while coding) it would require using a for loop to iterate over the curve's points, which geo nodes don't really allow... I eventually got around this by using the accumulate node to implement the for loop in a non obvious way, though I can't say I recommend that workflow to anyone...

Which leads me to a key remark: my node group using Set Curve Tilt assumes that the original curve was using "Minimum Twist".
Or to be more specific, had the curve started as Z-up then I believe my node group would still produce 360 flips on occasion, due to the fact that the "rest position" (i.e. zero Tilt) in the Z-up mode includes some twisting, which my node group does not account for.

A limitation
My node group has one limitation when compared to a true implementation of option 2.
When the curve is a loop, my node group can only produce strips that are obtained by twisting a cylindrical strip (on the left below). This excludes surfaces like the Moebius strip on the center (generated by a loop with a "total tilt" of 180 degrees) or the "double Moebius strip" on the right (generated by a loop with a "total tilt" of 360 degrees).

I think neither the Moebius strip nor the double Moebius strip can currently be generated by Blender by extruding curves.
And while generating the Moebius strip is out of the question (since it doesn't have a well defined normal), I believe that a full implementation of option 2 would allow for generating a double Moebius strip.

AlignNormalsExample.blend

Hi! I'm new here but I'm very interested in this design task. In fact, I've more or less built my own custom node group (in current Blender) that achieves something very similar to the design goal (I'm attaching a blend file with that node group). So hopefully my thoughts will be of some use (apologies for the lengthy post... I've spent quite a bit of time thinking about this). **An application:** The main application I have in mind is something like the image below (which is from the blend file I attached at the end), where we wrap strips of fabric/bandages around a character's body. ![bandages_on_arm.png](https://archive.blender.org/developer/F13478009/bandages_on_arm.png) **Overview of the geo nodes in the application:** If you enlarge the picture, you should be able to see the curve from which the bandages are generated using geo nodes. The geo nodes are doing 3 things here: 1) slightly shrinkwrapping the curve around the arm (though it started pretty close); 2) (**the main part**) adjusting the curve's tilt (using Set Curve Tilt Node and plenty of math) so the curve's normals point in about the same direction as the mesh normals (transferred to the curve from the mesh). Naturally, the mesh's normals might not be precisely perpendicular to the curve's tangents (although the shrinkwrapping ensures they'll be close to perpendicular), and I address this as suggested in option 2, by projecting the mesh's normals onto the planes perpendicular to the respective tangents, then renormalizing; 3) extruding the curve. **A key difficulty** In effect, my node group is more or less achieving option 2 via the Set Curve Tilt Node, though this required a lot of care and some frustrating mistakes. At first sight, one might think that building this node group is just a matter of determining the angles between the current normals and the intended normals (which is just a bunch of linear algebra plus trigonometry), then setting that as the tilt (while using the tangent to decide if the tilt is positive or negative). However... the naive procedure above will invariably lead to examples as below, where the curve does a 360 degree flip over a short segment. ![bandages_on_arm_twisted.png](https://archive.blender.org/developer/F13478092/bandages_on_arm_twisted.png) Fixing these 360 flips was a huge pain, since normally (i.e. while coding) it would require using a for loop to iterate over the curve's points, which geo nodes don't really allow... I eventually got around this by using the accumulate node to implement the for loop in a non obvious way, though I can't say I recommend that workflow to anyone... Which leads me to a key remark: **my node group using Set Curve Tilt assumes that the original curve was using "Minimum Twist"**. Or to be more specific, had the curve started as Z-up then I believe my node group would still produce 360 flips on occasion, due to the fact that the "rest position" (i.e. zero Tilt) in the Z-up mode includes some twisting, which my node group does not account for. **A limitation** My node group has one limitation when compared to a true implementation of option 2. When the curve is a loop, my node group can only produce strips that are obtained by twisting a cylindrical strip (on the left below). This excludes surfaces like the Moebius strip on the center (generated by a loop with a "total tilt" of 180 degrees) or the "double Moebius strip" on the right (generated by a loop with a "total tilt" of 360 degrees). I think neither the Moebius strip nor the double Moebius strip can currently be generated by Blender by extruding curves. And while generating the Moebius strip is out of the question (since it doesn't have a well defined normal), I believe that a full implementation of option 2 would allow for generating a double Moebius strip. ![moebius.png](https://archive.blender.org/developer/F13478145/moebius.png) [AlignNormalsExample.blend](https://archive.blender.org/developer/F13478011/AlignNormalsExample.blend)

Charlie Jolly commented

2022-10-03 12:45:37 +02:00

Added subscriber: @CharlieJolly

Hans Goudey referenced this issue

2023-06-12 18:30:25 +02:00

WIP: Curve-to-Mesh node Even Thickness #108700

Bruno referenced this issue

2023-06-12 21:56:27 +02:00

WIP: Curve-to-Mesh node Even Thickness #108700

Bruno referenced this issue

2023-06-13 12:03:18 +02:00

WIP: Curve-to-Mesh node Even Thickness #108700