But this will not catch the last point of the original curve.

You should be limited to the end points of the original curve, right ?

What would you do for this ?

# Divide curve by equal distance

I wonder if Divide Distance accepts negative distances?

Here’s I usually discretise curves into N same-length segments, based on a desired target segment length:

Hi check this out,

divdeCrvByLength_Comprimised.gh (13.0 KB)

There will be always similar “problem” if you divide crv by a random length. Either way you extand the last segment to match the “L” as you diagramed, or you calculate the last short segment / input length and if the ratio is quite small, let`s say < 0.2, my method is neglect the last segment, which is the uploaded sketch tryng to get the “Compromised divide curve by pre-set distance”.

If it is the lengths of the straight lines between the points on the curve you want equal, I think the only way is to solve it iteratively:

(I was actually surprised this works - my first intuition was that it was an overconstrained problem and there wouldn’t generally be a solution. It reminds me a bit of the 4-legged table problem: https://arxiv.org/pdf/math-ph/0510065v6.pdf)

That’s great,

I tried doing this with Galapagos iterations but couldn’t reach a perfect match, there is always a certain missing tolerance, but with kangaroo it is perfect. Check the screen shot.

thank you Kim for your solution,but I think the end point is not the curve end point, and this way is also not “grasshopper”:喜悦:

Hi Anders I mean I just want to get the segment curve distance(start point to end point) but not segment curve length

Hi Lei Yang

I had used your file ,but I found a problem that is if I Increase the inputDiviValue the average error of result will also increase.

Hi Daniel

Thank your for your solution infact your way is the last way I choice to deal with my problem , thank your for your help and also your Kangaroo——awesome plug-in

Yeah, Kangaroo is the best way

I kind of misunderstood the question :<

I use Galapagos to build the algorithm, and the key thing is to find proper EQUATION.

Here is the result which ran 35mins, time comsuming is a problem for GA method.

anyway, check if the result match your question.

Kangaroo should work I`ll check it out.

Thanks!

divideCrv.3dm (63.4 KB)

crvDivide_galapagos.gh (18.9 KB)

Great job ! thanks!

Does anybody have solution for equidistant division of curve such as:

- N … number of division points
- L … computed resulting length of segments(within given tolerance)
- but for any pair of indices { i , j }, i <> j, distance between Vertice[ i ] and Vertice[ j ] is >= L
- if there is no solution for N vertices, GH-defintion will try to find solutions for N1 vertices:

a) where N1 is highets num and N1<N (first lowest num)

b) where N1 is lowest num and N1>N (first highest num)

For example this is not valid solution because two points, 1 and 3, are closer then L. So GH-definition should try to find another solution to satisfy condition 3):

That’s equivalent to saying no angle between consecutive segments can be less than 60°

Probably the simplest way would be to just compute the equal segment solution for a few different N, check whether they meet this distance condition and take the one closest.

You are trying to minimize an “energy” function based on the distances of the points. I know that these can be solved using gradient descent methods, though I have no idea how you’d do it in GH.

It is not exactly constraint angle > 60°, because it can happen for any pair of indices { i,j } not only {i, i+2} where condition 3} will not be satisfied

Your suggestion can work in some cases:

but in general there are solution for N which will satisfy condition 3) and can not be found with simple way.

I tested this GH definition w/ Kangaroo component on some curves and in some cases resulting points are not placed on the curve:

equalseg_02.gh (15.5 KB)

Is this because of some setting of Kangaroo component (I am not familiar with the component) or something else?

Interesting - it looks like when the curvature is tight enough/the segments long enough, it can get trapped in a local energy minimum which is not the global minimum.

One way to nudge it out of this configuration would be to use the grab tool.

Connect the ‘Grab’ component to the {0;0} input of the Entwine, then

hold down the Alt key and use left mouse button to drag the point in Rhino.

Sorry for bumping up this old thread, but I had this problem and started to code a solution, then I found this thread but I’m not sure of if the problem was solved already?

For my own part I have need for a single simple component since I often need these straight segments, so I coded a single component for this, and no surprise, I also encountered all the tricky cases discussed in this thread. I have not tried all the solutions posted here but I post mine as well.

My single component finds the segments of a set length using circles (most common strategy I guess) and optionally it auto-extends the segment length (input Extend = true) to cover the full length of the curve (within document tolerance).

**Fig 1.** The component.

**Fig 2.** Dividing the curve segements using circles (from left to right). It avoids getting messed up at self intersections. Here the segments are not extended.

**Fig 3.** Here the curve segments are extended to cover the entire base curve. The numerous circles indicates that the component iterates extending the circle radius until it ends up within tolerance distance from the end of the curve. Red and green points indicate the different segments landing points after extending.

Sometimes it happens that the algorithm goes bananas when it extends too much (the radius inflates more than needed to consume the rest-distance to the curve end), then the `Refine` option fixes it by iterating with smaller increments when extending. This seems to work in most cases (haven’t seen it fail in my testcase):

**Fig 4.** Here the circles has “inflated/extended too much” (this problem was fixed above by activating the `Refine` option) because it missed the tolerance +/- interval at the curve-end, and therefore the iterator didn’t stop until it reached a max_iterations guard in the algorithm (I have yet to figure out how to detect a miss so I can revert it, but at least the Refine option can handle it after the fact.

**Fig 5.** Here the end segment which reached the end of the base curve.

**Fig 6.** One of the tricky things was to avoid “jumps” over selfintersections or “shortcuts” at tight loops. Here the segments attach to the curve without shortcutting, as long as the segment lengths fits into the loop:

The component:

DivideCurveByStraightSegments.gh (24.1 KB)

// Rolf