Allow choosing spline index in sample curve node #92474

New Issue

Jacques Lucke · 2021-10-25T14:07:57+02:00

Jacques Lucke commented

2021-10-25 14:07:57 +02:00

Currently the "Sample Curve" node samples the entire spline, with cumulative lengths. This is problematic for a few reasons:

Most of the other curve nodes work "per-spline", so it breaks assumptions about how the node will work.
When designing the node, I assumed that separate splines are not that important for people, but they are actually essential for some cases.
It increases complexity when the user only wants to sample a single spline.

The solution is splitting up the "whole curve" sampling so the user can choose which to do.

There are two ways to do this:

Add an "All Splines" boolean input to the node.
The node gets a "Spline Index", which is ignored when the all splines option is on. The factor/length input meaning changes when all splines is on.
** The benefit is that the operation is still a single node
Add a new "Sample Spline Index" node and a "Spline Index" input
This node finds the spline index where a length or factor fits, and can be connected to the spline index option. This maps to the behavior users often want, where different logic is often desired to choose splines vs. location in spline.
** The benefits are flexibility and straightforward meanings for each socket.

Currently the "Sample Curve" node samples the entire spline, with cumulative lengths. This is problematic for a few reasons: - Most of the other curve nodes work "per-spline", so it breaks assumptions about how the node will work. - When designing the node, I assumed that separate splines are not that important for people, but they are actually **essential** for some cases. - It increases complexity when the user only wants to sample a single spline. The solution is splitting up the "whole curve" sampling so the user can choose which to do. There are two ways to do this: 1. Add an "All Splines" boolean input to the node. **The node gets a "Spline Index", which is ignored when the all splines option is on.** The factor/length input meaning changes when all splines is on. ** The benefit is that the operation is still a single node 2. Add a new "Sample Spline Index" node and a "Spline Index" input **This node finds the spline index where a length or factor fits, and can be connected to the spline index option.** This maps to the behavior users often want, where different logic is often desired to choose splines vs. location in spline. ** The benefits are flexibility and straightforward meanings for each socket.

Jacques Lucke commented

2021-10-25 14:07:57 +02:00

Added subscriber: @JacquesLucke

Hans Goudey was assigned by Jacques Lucke

2021-10-26 11:46:30 +02:00

Hans Goudey changed title from ~~Sample Curve node update~~ to Allow choosing spline index in sample curve node

2021-10-26 22:42:36 +02:00

Hans Goudey commented

2021-11-01 23:46:41 +01:00

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

Iliya Katushenock commented

2022-02-03 20:54:37 +01:00

Added subscriber: @mod_moder

Iliya Katushenock commented

2022-08-26 23:47:44 +02:00

Looking at the task and my patch, I might think that I already have a field generator to enter an index and a factor to get the global length. But putting this into a separate node will mean that we assume that the curve is always cyclical (That is, globality will not mean that we can ignore cyclicality). Always, even with a global factor, we will make a full circle around the curve (if cyclic) to go to the next one. Although this confuses me a little, it is most likely just a hasty thought.

Node:
  Name = "Curve Factor/Length at Spline"
  Inputs: Curve, Length/Factor, Index
  Output: Length/Factor (Or only one, or another rundom setting) in global (taking into account the cyclicity)

In this case, sampling is always global and no indexing is needed.
Or, if this is a mode of operation, then you still need to always have a global mode of operation, but now also with switching.

Looking at the task and my patch, I might think that I already have a field generator to enter an index and a factor to get the global length. But putting this into a separate node will mean that we assume that the curve is always cyclical (That is, globality will not mean that we can ignore cyclicality). Always, even with a global factor, we will make a full circle around the curve (if cyclic) to go to the next one. Although this confuses me a little, it is most likely just a hasty thought. ``` Node: Name = "Curve Factor/Length at Spline" Inputs: Curve, Length/Factor, Index Output: Length/Factor (Or only one, or another rundom setting) in global (taking into account the cyclicity) ``` ![image.png](https://archive.blender.org/developer/F13419190/image.png) In this case, sampling is always global and no indexing is needed. Or, if this is a mode of operation, then you still need to always have a global mode of operation, but now also with switching.

Mikhail Vigovskiy commented

2022-09-20 06:48:31 +02:00

Added subscriber: @upliner

炎臻 commented

2022-11-08 19:49:31 +01:00

Added subscriber: @PrettyFireNOI7

炎臻 commented

2022-11-08 19:49:31 +01:00

In my point of view, I think the new changes would optimize the node setup and make the thinking more natural. I would want to drop a few examples here to show the differences and mention a bug (#102358) I found through the process. Also some feedback.

{icon fa-plus} All-in-one .blend file:

3.5 Sample Curve Test.blend

First example :

In the pic above, two groups of nodes are used to show the differences between All Curves on and off.
What the nodes do is visualizing the mid point position of each spline in the curve through Viewer. Five splines in equal length 1(m) are positioned alone Y (world) axis and the curve object's origin is at world center.
The upper group of nodes represent the previous way to use Sample Curve. Since the Length should be used in an accumulated way so to sample the mid point in each spline, the input value should be like 0.5→1.5→2.5→3.5→4.5 matching the spline index which is 0→1→2→3→4. The Length output of the Spline Parameter can be turned into 0→1→2→3→4 in Spline Domain matching spline index 0→1→2→3→4. So adding 0.5 to the field can result in 0.5→1.5→2.5→3.5→4.5.
The lower group of nodes make use of the new changes to Sample Curve node. If All Curves option is unchecked, the node would calculate the Length input individually for each spline (if I would be right, I don't know coding). So to think of "mid point" for each spline with length of 1, a value of 0.5 can simply be the input. But in this case, the Curve Index should have each spline's own index, which as in the pic, having a index input calculated in Spline Domain or otherwise for example, if the default value 0(for now) is used, all the sampled result would be the first spline's mid point.
I think the way to think is more straight forward with the changes, and the node structure gets more optimized if things gets more complex.
Second example :
1-1 1-2 0001-0250.mp4
By making further from the first example, these nodes place a cube on each spline using the attribute sampled by Sample Curve node and instead of Length mode, the Sample Curve node switched to Factor mode. Additionally, those cubes have different positions on the spline, different moving speed ,cycling movement on respective spline and the number of cubes auto-matches the number of splines.
2-1 2-2 2-3
By comparing the new & previous method (pic 2-2 & 2-1), for myself I think the visual is already clearer. And by taking the benefit of the changes, it's more readable. The pre-calculation for the length/factor of the points is not needed.
Third example :
0001-0250.mp4
This is just one having more duplicated curves and randomly transformed control points, it's using the same GN as the Scecond example, with invisible splines option.

As for some feedback, I think the Sample Spline Index node could come in handy to replace the two-nodes set up for Curve Index input as above, or by default could make the input uses spline index. Though Sample Spline Index to me sounds like a curve sample node but not an input node (for me I thought it could be Index of Spline ? Or maybe the node has more functionalities? ).

In my point of view, I think the new changes would optimize the node setup and make the thinking more natural. I would want to drop a few examples here to show the differences and mention a bug (#102358) I found through the process. Also some feedback. ---- **{icon fa-plus} All-in-one .blend file:** [3.5 Sample Curve Test.blend](https://archive.blender.org/developer/F13869622/3.5_Sample_Curve_Test.blend) **First example :** ![image.png](https://archive.blender.org/developer/F13869130/image.png) ![image.png](https://archive.blender.org/developer/F13869146/image.png) - In the pic above, two groups of nodes are used to show the differences between **All Curves** on and off. What the nodes do is visualizing the mid point position of each spline in the curve through **Viewer**. Five splines in equal length 1(m) are positioned alone Y (world) axis and the curve object's origin is at world center. - The upper group of nodes represent the previous way to use **Sample Curve**. Since the __Length__ should be used in an accumulated way so to sample the mid point in each spline, the input value should be like 0.5→1.5→2.5→3.5→4.5 matching the spline index which is 0→1→2→3→4. The __Length__ output of the **Spline Parameter** can be turned into 0→1→2→3→4 in __Spline Domain__ matching spline index 0→1→2→3→4. So adding 0.5 to the field can result in 0.5→1.5→2.5→3.5→4.5. - The lower group of nodes make use of the new changes to **Sample Curve** node. If **All Curves** option is unchecked, the node would calculate the __Length__ input individually for each spline (if I would be right, I don't know coding). So to think of "mid point" for each spline with length of 1, a value of 0.5 can simply be the input. But in this case, the __Curve Index__ should have each spline's own index, which as in the pic, having a index input calculated in __Spline Domain__ or otherwise for example, if the default value 0(for now) is used, all the sampled result would be the first spline's mid point. I think the way to think is more straight forward with the changes, and the node structure gets more optimized if things gets more complex. **Second example :** 1-1 ![image.png](https://archive.blender.org/developer/F13869463/image.png) 1-2 ![image.png](https://archive.blender.org/developer/F13869466/image.png) [0001-0250.mp4](https://archive.blender.org/developer/F13869548/0001-0250.mp4) - By making further from the first example, these nodes place a cube on each spline using the attribute sampled by **Sample Curve** node and instead of __Length__ mode, the **Sample Curve** node switched to __Factor__ mode. Additionally, those cubes have different positions on the spline, different moving speed ,cycling movement on respective spline and the number of cubes auto-matches the number of splines. 2-1 ![image.png](https://archive.blender.org/developer/F13869477/image.png) 2-2 ![image.png](https://archive.blender.org/developer/F13869480/image.png) 2-3 ![image.png](https://archive.blender.org/developer/F13869484/image.png) - By comparing the new & previous method (pic 2-2 & 2-1), for myself I think the visual is already clearer. And by taking the benefit of the changes, it's more readable. The pre-calculation for the length/factor of the points is not needed. **Third example :** [0001-0250.mp4](https://archive.blender.org/developer/F13869571/0001-0250.mp4) - This is just one having more duplicated curves and randomly transformed control points, it's using the same GN as the Scecond example, with invisible splines option. ---- As for some feedback, I think the **Sample Spline Index** node could come in handy to replace the two-nodes set up for __Curve Index__ input as above, or by default could make the input uses spline index. Though **Sample Spline Index** to me sounds like a curve sample node but not an input node (for me I thought it could be **Index of Spline** ? Or maybe the node has more functionalities? ).

Iliya Katushenock commented

2022-11-08 19:59:20 +01:00

Please do not post your reports in unrelated places. The developer will see it when there is time

炎臻 commented

2022-11-08 21:37:39 +01:00

In #92474#1442755, @mod_moder wrote:
Please do not post your reports in unrelated places. The developer will see it when there is time

I think it's basically a demo to show how the changes from the patches optimize things, though based on my workflow.
Isn't this task in "waiting for product demo" state or I misunderstand the meaning?

> In #92474#1442755, @mod_moder wrote: > Please do not post your reports in unrelated places. The developer will see it when there is time I think it's basically a demo to show how the changes from the patches optimize things, though based on my workflow. Isn't this task in "waiting for product demo" state or I misunderstand the meaning?

Iliya Katushenock commented

2022-11-08 21:52:51 +01:00

I just took it as a reason to hurry up the bug fix. In this case, sorry, jumped to conclusions.

Jacques Lucke commented

2022-11-16 15:50:44 +01:00

Changed status from 'Confirmed' to: 'Resolved'

Jacques Lucke closed this issue

2022-11-16 15:50:44 +01:00

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

Allow choosing spline index in sample curve node #92474