Campbell recently did this in 9ae98f305a4c2ef226ad7, might as well do that now I guess.

This is very inefficient of course. I guess the next step is to add a utility to BLI_length_parameterize.hh to find indices and factors along lengths.

Something like this I suppose:

void create_arbitrary_samples(Span<float> lengths,
                              Span<float> sample_lengths,
                              bool cyclic,
                              MutableSpan<int> indices,
                              MutableSpan<float> factors);

That would also be used in the sample curves node.
I have a few ideas there, something like sorting the sample length arguments we discussed a while ago.

could be clarified with "rather than the end point"

I'd suggest extracting a utility that finds the total length from Span<float3>.

I'd also suggest slicing a span of positions for the curve into a variable and then using that instead of using curve_points over and over.
That makes it more like move_last_point_and_resample in structure.

If you disagree that's fine, I'd general expect "for" instead of "by" here though.

Could add something like /* Execute effect. */ on the second parallel block, to mirror the "Compute influences" comment.

I'm a bit curious about the organization here. For example, why not do something like this?

threading::parallel_for(curves_->curves_range(), 256, [&](IndexRange curves_range) {
  Influences &influences = influences_by_thread.local();
  influences.clear();
  if (falloff_shape_ == PAINT_FALLOFF_SHAPE_TUBE) {
    this->gather_influences_projected(influences);
  }
  else if (falloff_shape_ == PAINT_FALLOFF_SHAPE_SPHERE) {
    this->gather_influences_spherical(influences);
  }
  self_->effect_->execute(*curves_, influences.curve_indices, influences.move_distances_cu);
});

I'd imagine that fusing the two passes would keep more data in cache for each thread, unless the goal is to keep the data from the first influence gathering pass more local?
Or maybe you're thinking about something besides locality?

I guess this influence gathering logic is quite similar to existing code in other brushes, just improved and generalized a bit?

I'd suggest a few changes here, even if it makes it less consistent with the other functions in this area.

• Change r_close_a to r_closest_a
• Document what "lambda" means in this situation.
• I think return arguments are supposed to be last, in general? This area is quite inconsistent then.. I'm okay if you don't change that one :P

Also, I wonder about having something like BLI_math_geometry.hh using float2 instead. Maybe?

Suggestion for simplification of the tooltip:
"When shrinking curves, they shouldn't become shorter than this length" -> Avoid shrinking curves shorter than this length