Array Along Curve has uneven spacing #84073

New Issue

Mark Stead · 2020-12-23T09:47:10+01:00

Mark Stead commented

2020-12-23 09:47:10 +01:00

System Information
Operating system: Windows-10-10.0.19041-SP0 64 Bits
Graphics card: GeForce GTX 970/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 460.79

Blender Version
Broken: version: 2.91.0, branch: master, commit date: 2020-11-25 08:34, hash: 0f45cab862
Worked: Never that I'm aware - I've tried back to 2.79

Short description of error
When using array along a curve (even with a simple two point line), the size/spacing appears to be affected by the curve resolution.
I increased the curve resolution to 128, and the array element spacing was identical except for a distortion anomaly near the start of the array.
Increasing the curve resolution to 1024 appears to eliminate the problem.

Exact steps for others to reproduce the error
I will attach a file. However all I've done is create a curve with two (vector) points (0,0,0) and (0,100,0).
Then create a simple object rectangular plane. Add array modifier (I used the Fit Curve option but this is not important).
Then add a curve modifier.
You can alter the value of the curve resolution to observe the difference in spacing.
Also moving the array object along the X axis will demonstrate the distortion.

Here's my example file ArrayAlongCurveUnevenSpacing.blend

There are 5 arrays, the numbers indicate the curve resolution. The reference is a standard array without using a curve modifier. (Distance between array elements is 0.2m in all cases.)

As you can see 1024 matches the reference.
512 matches the reference after the first two array items. Notice the size distortion of those first two array items.
128 matches the reference after the first four array items. Likewise there is size/spacing distortion.
12 only matches the reference if you go to Y=9m.

Look this may just be a feature where you need to use sufficient resolution to get the expected behaviour.
In particular I would note that with my line length of 100m, if you divide by the resolution of 12, it gives you 8.33m - which appears to correlate with when the spacing corrected itself.
That said, why is the spacing correct after that point - even though the next resolution segment would also be 8.33m.
Hence why this could be some simple rounding error.

Thanks for your help.
Mark

**System Information** Operating system: Windows-10-10.0.19041-SP0 64 Bits Graphics card: GeForce GTX 970/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 460.79 **Blender Version** Broken: version: 2.91.0, branch: master, commit date: 2020-11-25 08:34, hash: `0f45cab862` Worked: Never that I'm aware - I've tried back to 2.79 **Short description of error** When using array along a curve (even with a simple two point line), the size/spacing appears to be affected by the curve resolution. I increased the curve resolution to 128, and the array element spacing was identical except for a distortion anomaly near the start of the array. Increasing the curve resolution to 1024 appears to eliminate the problem. **Exact steps for others to reproduce the error** I will attach a file. However all I've done is create a curve with two (vector) points (0,0,0) and (0,100,0). Then create a simple object rectangular plane. Add array modifier (I used the Fit Curve option but this is not important). Then add a curve modifier. You can alter the value of the curve resolution to observe the difference in spacing. Also moving the array object along the X axis will demonstrate the distortion. Here's my example file [ArrayAlongCurveUnevenSpacing.blend](https://archive.blender.org/developer/F9526562/ArrayAlongCurveUnevenSpacing.blend) There are 5 arrays, the numbers indicate the curve resolution. The reference is a standard array without using a curve modifier. (Distance between array elements is 0.2m in all cases.) ![image.png](https://archive.blender.org/developer/F9526564/image.png) As you can see 1024 matches the reference. 512 matches the reference after the first two array items. Notice the size distortion of those first two array items. 128 matches the reference after the first four array items. Likewise there is size/spacing distortion. 12 only matches the reference if you go to Y=9m. Look this may just be a feature where you need to use sufficient resolution to get the expected behaviour. In particular I would note that with my line length of 100m, if you divide by the resolution of 12, it gives you 8.33m - which appears to correlate with when the spacing corrected itself. That said, why is the spacing correct after that point - even though the next resolution segment would also be 8.33m. Hence why this could be some simple rounding error. Thanks for your help. Mark

Mark Stead commented

2020-12-23 09:47:10 +01:00

Added subscriber: @MarkStead-2

Mark Stead commented

2020-12-24 02:27:48 +01:00

I guess for clarity I should have applied the Array modifier.
The problem is within the Curve modifier.

I guess for clarity I should have applied the Array modifier. The problem is within the Curve modifier.

Mark Stead commented

2020-12-24 09:51:48 +01:00

Not sure if this really helps. This is another test case which demonstrates how Path resolution being low can affect movement when using a Curve modifier animate along a path.
#84073 Uneven movement with Curve modifier to follow path.blend
In this case FollowPath uses a Curve modifier to follow along the Track curve. (Y location of FollowPath is animated.)
Linked to FollowPath is a wheel which should rotate to match the distance travelled.
When you load the file Track will have a curve segment resolution of 1024.
As you move forward in the animation, the wheel spokes will align with the blocks on the ground, and the movement will look correct. For example by frame 21.

However if you modify Track to have a curve segment resolution of 12, then the rotation is not in alignment until about frame 50+.

Not sure if this really helps. This is another test case which demonstrates how Path resolution being low can affect movement when using a Curve modifier animate along a path. [#84073 Uneven movement with Curve modifier to follow path.blend](https://archive.blender.org/developer/F9527795/T84073_Uneven_movement_with_Curve_modifier_to_follow_path.blend) In this case FollowPath uses a Curve modifier to follow along the Track curve. (Y location of FollowPath is animated.) Linked to FollowPath is a wheel which should rotate to match the distance travelled. When you load the file Track will have a curve segment resolution of 1024. As you move forward in the animation, the wheel spokes will align with the blocks on the ground, and the movement will look correct. For example by frame 21. ![image.png](https://archive.blender.org/developer/F9527813/image.png) However if you modify Track to have a curve segment resolution of 12, then the rotation is not in alignment until about frame 50+.

Mark Stead commented

2020-12-25 10:28:03 +01:00

I think the problem is in where_on_path() in anim_path.c

The points that have incorrect translation by the Curve modifier are those where ctime *= (path->len - 1) is less than 1. Specifically these are points within that first segment of curve resolution.
In this case the four points selected for weighting will be:
s0=0
s1=0
s2=1
s3=2

So, key_curve_tangent_weights() will give twice the weighting to point pp- [x] because it is specified twice.
Note that interp_v3_v3v3v3v3() expects 4 vectors, and a weighting across 4 points. An alternative function is available interp_v3_v3v3v3() that will do weighting across 3 vectors, however you would need a separate function to generate the 3 point weights (w[3]).

As an alternative, I modified the behaviour to unconditionally set s1 to a minimum of 1 (hence s0=0, s1=1, s2=2 and s3=3). This did in fact give sensible output in the UI.
However I recognise this may not be appropriate because now you are applying a weighting to pp- [x] when perhaps you shouldn't be.
Note that the same problem is observable in the last resolution segment of the curve - where I guess s0=length-3, s1=length-2, s2=length-1 and s3=length-1.
Also there could be related quirks if the curve resolution is 2 or 3.

I think the problem is in where_on_path() in anim_path.c The points that have incorrect translation by the Curve modifier are those where ctime *= (path->len - 1) is less than 1. Specifically these are points within that first segment of curve resolution. In this case the four points selected for weighting will be: s0=0 s1=0 s2=1 s3=2 So, key_curve_tangent_weights() will give twice the weighting to point pp- [x] because it is specified twice. Note that interp_v3_v3v3v3v3() expects 4 vectors, and a weighting across 4 points. An alternative function is available interp_v3_v3v3v3() that will do weighting across 3 vectors, however you would need a separate function to generate the 3 point weights (w[3]). As an alternative, I modified the behaviour to unconditionally set s1 to a minimum of 1 (hence s0=0, s1=1, s2=2 and s3=3). This did in fact give sensible output in the UI. However I recognise this may not be appropriate because now you are applying a weighting to pp- [x] when perhaps you shouldn't be. Note that the same problem is observable in the last resolution segment of the curve - where I guess s0=length-3, s1=length-2, s2=length-1 and s3=length-1. Also there could be related quirks if the curve resolution is 2 or 3.

Robert Guetzkow commented

2020-12-25 11:33:42 +01:00

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

Mark Stead commented

2020-12-26 06:35:58 +01:00

As I understand Blender curves are either Bézier or NURBS. Based on the curve resolution, these are then broken down into a series of straight line segments (according to the preview/render resolution).

Conceptually the Curve modifier could just be doing a linear interpolation between pairs of segment points. Obviously if you have a low resolution, then that's what you get.
However the implementation instead uses BSPLINE weightings for the points - and this may be related to supporting curve extrapolation/continuity beyond the first/last control point. As such the BSPLINE weighting will not closely approximate the original Bézier or NURBS curve, because the weighting is done against the segmented resolution points mapped along the curve.

Perhaps in a future version the algorithm could instead be based on the original Bézier or NURBS control points.

This is how the Curve modifier operates on a 2D NURBS curve of resolution 1 (control points hightlighted). The jagged transition is due to the double weighting of point 0 for points within the first two control points.

Whereas a Curve modifier on a 2D Bézier curve of resolution 1 (control points hightlighted) closely follows the linear segments - except the ctime is somehow not in alignment.

As I understand Blender curves are either Bézier or NURBS. Based on the curve resolution, these are then broken down into a series of straight line segments (according to the preview/render resolution). Conceptually the Curve modifier could just be doing a linear interpolation between pairs of segment points. Obviously if you have a low resolution, then that's what you get. However the implementation instead uses BSPLINE weightings for the points - and this may be related to supporting curve extrapolation/continuity beyond the first/last control point. As such the BSPLINE weighting will not closely approximate the original Bézier or NURBS curve, because the weighting is done against the segmented resolution points mapped along the curve. Perhaps in a future version the algorithm could instead be based on the original Bézier or NURBS control points. This is how the Curve modifier operates on a 2D NURBS curve of resolution 1 (control points hightlighted). The jagged transition is due to the double weighting of point 0 for points within the first two control points. ![image.png](https://archive.blender.org/developer/F9530570/image.png) Whereas a Curve modifier on a 2D Bézier curve of resolution 1 (control points hightlighted) closely follows the linear segments - except the ctime is somehow not in alignment. ![image.png](https://archive.blender.org/developer/F9530573/image.png)

Mark Stead commented

2021-04-10 04:47:02 +02:00

I believe this has been fixed by #81707.

Loading the file demonstrating the problem, there is no longer an issue. The array spacing is the same regardless of the curve resolution.

Also, that jagged transition with a (low resolution) NURBS curve is no longer present.
It now strictly follows the actual curve (straight line) segments, rather than doing a separate curve fitting.

Plus the array modifier also follows the (low resolution) Bézier curve too without any quirks.

Anyway, I don't know if there should be a difference between how NURBS and Bézier are handled. One targets the control points, while the other targets the midpoints.
But regardless, the array along curve now follows the actual "curve" path exactly in both cases.

I believe this has been fixed by #81707. Loading the file demonstrating the problem, there is no longer an issue. The array spacing is the same regardless of the curve resolution. ![image.png](https://archive.blender.org/developer/F9927823/image.png) Also, that jagged transition with a (low resolution) NURBS curve is no longer present. It now strictly follows the actual curve (straight line) segments, rather than doing a separate curve fitting. ![image.png](https://archive.blender.org/developer/F9927828/image.png) Plus the array modifier also follows the (low resolution) Bézier curve too without any quirks. ![image.png](https://archive.blender.org/developer/F9927836/image.png) Anyway, I don't know if there should be a difference between how NURBS and Bézier are handled. One targets the control points, while the other targets the midpoints. But regardless, the array along curve now follows the actual "curve" path exactly in both cases.

Hans Goudey commented

2021-04-19 16:27:24 +02:00

Added subscriber: @HooglyBoogly

Hans Goudey commented

2021-04-19 16:27:24 +02:00

Changed status from 'Confirmed' to: 'Resolved'

Hans Goudey closed this issue

2021-04-19 16:27:24 +02:00

Hans Goudey self-assigned this 2021-04-19 16:27:24 +02:00

Hans Goudey commented

2021-04-19 16:27:24 +02:00

In that case I think I'll close this report. Thanks for the analysis @Scumbag.

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

Array Along Curve has uneven spacing #84073