Is there a better way to test curves for slope?

Grasshopper
#1

Hi everyone,

I have a collection of curves from which I would like to find the point at which the curves have “x” slope.

To do this I first divide the curve by many points and test the nearest to “x”.

It works fine for this little amount of curves, but I have much more, and if I want more precision I need to divide by 1000 instead of 100. That means a lot of data, and all the components after the first division take quite some time to calculate.

So I wonder, isn’t there a better way? Thank in advance.
Shynn

Slope%20on%20Curve
Slope%20on%20Curve1916×824 142 KB
Slope on Curve.gh (17.0 KB)

EDIT: For anyone interested, the original definition is calculating slope in degrees. The slider says Slope(%), but it is actually (°).

To measure the slope in percent you need to calcualte the TAN of the angle in radians and multiply times 100.

Slope on Curve_percentage.gh (14.1 KB)

#2

I don’t see a heavy performance penalty here at all, even dividing each curve by 1000 instead of 100?

On an old laptop (R5) using 1000 curves instead of the 27 provided, dividing each curve by 1000 (testing one million points!!), the “weight” is more apparent. But it’s all in the setup phase before the ‘Slope%’ slider, which remains quite responsive, since the code after that is quick.

Divide Curve = 11 secs.
XProd = 4.2 secs.
Construct Plane = 5.7 secs.
DePlane = 9.2 secs.
Abs = 14.5 secs.

I don’t know of a faster method.

Slope_on_Curve_2019Nov16a
Slope_on_Curve_2019Nov16a.png959×248 20.7 KB

#3

Hi Joseph, thanks.

Indeed, but those seconds that each component takes matter to me because the definition is calculated multiple times for 1000 curves 1100 curves 1200 curves, etc, or even the same amount of curves but with different curvature, height, etc. Quite a pain if you ask me. :sweat:

#4

A million is a big number! One simplification I tried took more than four times longer.

#5

Still not walking the walk eh?

  1. Get the grevilleParams and do the slope Intervals List (0 to 360 by measuing tangents VS, say, Plane.WorldXY.XAxis and with respect the Plane.WorldXY).
  2. Search the Intervals for containment the search slope.
  3. The first to comply (or any other if you want to find all the slope points) is a candidate.
  4. From that point and on is a matter of variable (i.e. strinking) resolution recursive search.

PS: Do you have cores aplenty?

#6

Not yet :sweat:. But Soon™.

Is seems you got a plan huh?

Just the standard 4 core btw.

#7

Indeed: Imagine getting the greville parameters (that define crv segments), the tangents at ends … thus the slopes (counter clock wise by measuring against a V (1,0,0) and Plane.WordXY) and then doing a test if the given slope is included. Then you sample the right pieces and you feed the next recursive loop with these: you get the greville paramemeters on pieces blah, blah. So finally and depending on the accuracy (i.e. the recursion Loops) you get mini crv pieces. Then you do an array sort on the greville parameters per mini piece (actually 3 array sorts, but who’s counting? ) and you get the best approximation. In plain English: given a slope, find the points.

Screen%20Shot%20059
Screen Shot 059.JPG1828×732 425 KB

In order to get the gist … here’s the state of things for Loop 0 (the first):

Screen%20Shot%20061
Screen Shot 061.JPG1831×777 495 KB

Bad news: (mode: find all points - as opposed to find the first) 0.5 milliseconds … an eternity if you have 1M curves … so … we need // stuff. But most // C#'s are classified as strictly internals meaning a Catch22 situation.

But maybe a can figure out a compromise. On the other hand I’m not in the right mood given the incredible things that Mercedes did (Brazil F1) to hero Lewis (these fellas are certified idiots: pitted the great man for fresh soft tires with 4 laps to go + a safety car + 2 brocken Ferraris on track … ). Plus when Bottas retired (safety car etc etc) … they left Lewis out while everybody else got fresh tires. BRAVO Mercedes.