• cleanup memory allocation and fix read of freed memory

Now there is probably only minor stuff left to change before landing, no more critical stuff afaict.

Do we need "angle increment" support? (Increase/decrease rotation for each segment)

If so I can code it but the matrix generation has to be inside the loop.

@Henrik Dick (weasel) Hello... This code crashes when gps->totpoints == 2, I suggest always create new points when curvature is turned on, otherwise the second call will have incorrect vert count. However when I removed the vert count check it still crashes with curvature off. You are most familiar with the new code path, so maybe you could give a hand. Thanks!

Great! it doesn't crash now, but after some testing I found two weird problems:

• The stretched part should probably be closing to a straight line if the overshoot value is closing to zero, but it's not the case with this test file. Maybe we still need to interpolate actual sampling position instead of using closest points? (Disable that sample modifier to get a clearer idea)
• Stretched parts sometimes disappear, adjust sample value in the modifier above it to see the effect.

very nice modifier :)!
tested with my room scene, now it is stable.

Because with it, we could apply the effect to only part of the scene, this example is from vertex weight + offset randomize. With this, the fallof would look great, we could make part of the scene look like something is organically growing out if it :)

@YimingWu (NicksBest) I debugged your problems and here is what I gathered:

1. The extention does not go flat in case that overshoot_fac is close to zero.. This is because of how the math works now. It looks at angles at the points and then interpolates. At the first point interpolation does not change the measured curvature. I would need to hack it in to make the extensions go flat with the factor close to zero, but I doubt that would be good since the factor is relative to the point number of the curve, so this interpolation to zero would kick in at different values for every stroke.
2. The lines disappearing comes from duplicate vertices. I don't know why the sample modifier creates perfect duplicate verts, but they cause problems here. I could handle them, but the simpler workaround it to use an adaptive simplify modifier before the length modifier.

btw what do you think about the Overshoot Factor beeing relative to the number of points instead of relative to the line length? Can you (or someone) present an example file where there is a reallife benefit from either one (point relative vs. length relative)?

@Aleš Jelovčan (frogstomp) great to hear! I can add vertex groups support in the future. Next up is a patch to add "Curvature Gradient" or "Spiral Factor" or something along those lines, which will make your organic spirals.

Hi @Henrik Dick (weasel)

About overshoot length: In my implementation the overshoot value is a ratio of stroke total length, this has a benefit of scaling the stroke doesn't change the appearance. Otherwise the curve will move around.

For flat extension: Manly because (especially) in line art there will be a lot of straight lines that doesn't have many points on each stroke, so the extension in such condition should stay flat so it's consistent with the rest of the scene. Using overshoot value related to stroke total length should also solve this problem (as long as you actually interpolate and find out the exact position of that 2 other sample points on the stroke), and adjusting overshoot will then produce continuous result as well.

Apparently these are obviously not right... no matter how big or small the overshoot value is, this method does not handle "hard lines" very well.

Even after I add a simplify->sample modifier before, it's still acting weird (and because of the sample operation, the modifier stack runs very slow as a side effect):

I only had a GIF to represent the old behaviour at the moment:

IMO the 3 point sample & interpolating internally is still more robust, while the code is looking a bit convoluted, but it is there to handle edge cases like long straight segments and strokes with very few points. And also after @Henrik Dick (weasel) 's algorithm fix the original code performs pretty well now.

Here's the file if you want to take a look:

What do you think @Sebastian Parborg (zeddb) ?

The sampled method is more robust especially when stroke quality is unknown for situations like line art. It uses the last segment's tangent as twist starting point, so existing usages with twisting needs tweaking, but for applying on line art, it's easier to get a nice effect. Maybe we could have two algorithms for the user to choose from?

@Henrik Dick (weasel) , @YimingWu (NicksBest), tested again, wooow! What an improvement!

I could not reproduce issues with twitching on the files where I was getting it before. Seems stable, animating parameters is smooth and additional parameters allow for much greater control.

I think ultimately we go with @Henrik Dick (weasel) 's patch. Works quite nicely with my models as well.

Let's see if there's more stuff @Hans Goudey (HooglyBoogly) has to say.

I accepted based on the UI and naming changes. For the records, I haven't tested the patch at all.

I just fixed a small thing here:

if ((gps->flag & GP_STROKE_CYCLIC) != 0) {
  /* Don't affect cyclic strokes as they have no start/end. */
  continue; /* should be return */
}

Function wise it all looks good now. :D Thanks for the improvements

Besides my comments, I want to rename "overshoot" as well.
Basically because I think overshoot is not describing what it happening.

Note that the overshoot description also now implies it is only used for curvature, but this is not the case.

Overshoot implies that you have a calculated direction/angle but then "overshoot" this goal with a certain amount.

What is actually happening is that we:

a) In the non curvature case we change the point of the curve we calculate the direction from.
(Higher values makes us go further along the curve from the start/end positions when we calculate a vector that points at our start/end point for the extension direction)

b) In the curvature case we take more points into account when calculating the final curvature value.

Neither of these I think is some kind of overshoot. Instead this is a normalized length value.
IE 1.0f means we should traverse the whole curve. 0.0f means that we should only look at data in the very near vicinity of our start/end points.

To me this is some kind of normalized range or "window" where we estimate the mean curvature/derivative.

I have the same issue with "smoothness".
It seems to me that it doesn't really smooth it but weights the angles depending on the length of the edge it was calculated from?
So a value of 1.0f means that smaller edges of the curve will have much less influence than the longer edges.
And a value of 0.0f means that all calculated angles have the same influence regardless of the edge length.

Of course I know naming is extremely hard, but I hope we can come up with something better with some more discussion.