Area and offset distance ratio?

Turns out I already had a Brent-Dekker root finding function in GH2 via the MathNet project.

I added an Offset To Area component (no icon yet) and will also add an Offset To Length one to GH2:

It has a corner-style input, so it works for chamfered, sharp, rounded and blended corners.


And length:


Beyond having components for each specific individual use case, it would be great to have a more general way to use this type of root finding in GH2.

I’m imagining a root finding component that takes a cluster(or separate definition) as an input, similar to the Function delegate input to the root finding method in the code example I posted above.

So as long as that cluster had a number as input, a number as output and an interval for the input value over which the output crosses 0, it could contain any combination of components.

(and clusters/functions as inputs could enable all sorts of other fun stuff that is currently only possible through scripting)


I’m having to write a lot of code just figuring out the domain on which the root-finding ought to happen. All kinds of annoying cases depending on whether you want to shorten or lengthen the curve, whether the positive offset distance makes it longer or shorter, what the smallest offset distance is beyond the first actual root, and so on.

But yeah, sounds like this is something very akin to the problem of custom looping. One there’s a way for components to operate on other components all these things become possible. Tough nut to crack though…

@DavidRutten , the rectangle option is fine!

In case of a planar, closed, counterclockwise polyline and offset loose:

The increment of the polyline length have a fixed ratio with the offset distance.
That ratio is the sum of the tangents of all bisectors.
This lets us find a solution with the quadratic formula.

offset polyline to (17.4 KB)

The result is correct even if the polyline have self intersections before and/or after the offset, whatever this means.


Today’s Grasshopper 2 release has curve offset components for target lengths and areas. But they’re still pretty finicky, and also I think quite a lot slower than the solution Daniel posted.

There are always going to be issues with this because not all lengths can be approximated by a curve offset, and sometimes a very small change in offset distance causes a very large change in length.

My approach at the moment is:

  1. Offset the curve a tiny amount in both directions.
  2. If the negative offset gets us closer to the goal than the positive offset, then invert all distances from now on.
  3. Starting with a decent guess for the distance, measure if it exceeds the goal length or area.
  4. If it does, we have an upper limit. If it doesn’t, double the guess and measure again. Go through 16 doublings before giving up.
  5. If the upper limit was doubled at least once, the lower limit is the previous upper limit (i.e. prior to doubling). If the upper limit was okay right away, then measure 0.25 of the upper limit. If that offset falls short of the goal length or area, halve it up to 16 times until we find an offset distance which we can use as the lower limit.
  6. Use a root-finding algorithm to find an offset distance between ‘lower’ and ‘upper’ where the length or area matches the goal.
  7. The root-finder stops when it needs more than 32 bisections or when it gets a result correct to within 1% of the absolute tolerance.

As you can see, there’s quite a few offsets that might happen before we even start root-finding, there’s probably some optimisations to be had by removing or combining a few of those. But first it would be good to find cases where it fails to work even though an answer is possible.

This is becoming too geeky for me to comment further.

Instead, as a sell point for architects, i have to mention that most municipalities regulate the percentage of occupacy for a building footprint on the plot.