Hello all,
I ran into some inconsistency issues in dividing a curve. I’ve been mainly using two methods to divide curves, “Divide Length” and “Divide Distance”. As you can see in this screenshot, shattering a curve after “Divide Length” generates very small inconsistent curve segments. Segmented curves with a polyline out of points from “Divide Distance” have consistent lengths, but their values are mixed with integers and doubles.
Is there a solution to generate absolute consistent length values in both methods?
Thank you in advance!
DivideCurve.gh (11.6 KB)
Dongyeop
Why do you need accuracy of more than 6 decimals?
The panel component rounds off the numbers and converts them to text.
If those components use Rhino’s document tolerance, you can try to make it smaller (in RH options) and recompute the definition. If your problem is the display of these numbers, round up the numbers so that they all come out with the same number of decimals.
On the other hand, these two components don’t work the same way, so you can’t expect the same result.
1 Like
In addition to @Dani_Abalde’s comments, Grasshopper formats numeric values in the following ways:
- If the value is really close to an integer, it will display it as an integer, i.e. no radix and no decimals.
- If the value is close to a multiple of \pi, it will display it as such (this is all editable in the Preferences btw).
- If the value is very large (both positive and negative) or very small, scientific notation is used.
- If none of the above rules are in effect, then the value is rounded to six decimal places, at least one of which is shown, even if it is zero.
So when you see values that look like 4 it means that it in the range 4 plus or minus the integer cuttoff threshold. If the value looks like 4.0 then it differs more from 4 than the integer cutoff, but less than six decimal places. Maybe it’s 4.000000002, or 3.99999993.
To see the real value, you must use a custom formatting component with an {0:R} format flag. The R flag will ensure that no information is lost when formatting a number.
The way in which Grasshopper displays numbers was designed to strike a balance between most informative and most readable, but plenty of people have gotten confused by it over the years and I hope that I can come up with a much better scheme in future versions.
Thank you for your response. I’m trying to develop a user object for panelization, and I was getting inconsistent panel sizes. I tried to get to the bottom of that cause, and I found that these two division methods seem to have inconsistency. Although this tiny inconsistency is negligible in this example, it might become notable if that small differences are multiplied and repeated.
I know the difference between two components. I’m using them as options to panelize surfaces in a different way, and I’m just curious if there’s a way to eliminate any inconsistency in those two methods.
Thank you for the detailed information. It’s great to understand the Grasshopper number system in depth. My question was more about finding a way to get the consistent divided curve segments, especially using the “Divide Length” component. I wasn’t quite sure why the component generated this small inconsistency for dividing a curve in computation and hoped there was an alternative.
I’m somewhat surprised there as well, I would have thought that Divide Length would yield more accurate results., especially for polylines. I’ll look into it.
Divide Distance is ultimately a Curve|Sphere intersection operation which is both slow and tied to the Rhino document tolerance settings.
Thank you David. Here’s another example with somewhat bigger inconsistency…
DivideCurve2.gh (15.0 KB)
1 Like
Yup, the intersection tolerance is hard-coded to 0.00001 in the code. It should clearly be way more accurate than that. I thought that the intersector would try and fine the best solution and only revert to tolerance in case there’s a near-solution, but it seems not.
Edit: never mind, that’s Divide Distance, not Divide Length. The component you were asking about doesn’t seem to allow for tolerance specifications.
