Hi, I'm new in this forum, I hope I'm posting in the right place :) I have a curve that's 78520mm long, I use the divide curve to divide it into 65 points. Now 78520/65=1208, but instead I get points that are 1207.99mm apart along the curve...
Thanks for your answer Taz!
I tried to follow your example, but it turns out that the length of the subcurve is even further from what it's supposed to be...
Am I doing something wrong here?
Your arc segment is generated as the dash of a dashed line... I think the error has something to do with the way this curve is generated as part of another curve, but we'll have to see what David says... There's definitely something going on.
For original arcs referenced from Rhino or generated by GH everything works fine. As a workaround you should figure out a different routine to create your various lengths of arcs...
Also my curves are arches imported from autocad... do you think that can have something to do with it too?
The reason I split it with a dashed line is because I couldn't get shatter to work properly on those curves, I just never thought it could be the curves them selves.
That shouldn't matter. Once a curve is inside Rhino it will be represented as a Rhino curve. Giulio has found division accuracy problems before with big arcs before. This is probably the same problem.
I also noticed that 0.7 fails to work on Dash patterns with zero-length segments. I'll at least get this fixed asap.
Ok so we can assume that this is fixed in 0.7 (at least on my internal build of 0.7). I'll hopefully release a new build sometime this week. If you can wait 2~3 days, I think it's probably not worth the effort to try and fix this on 0.6.X
It will never be totally accurate, that's simply not possible with finite digit numbers such as used in Computing. It should definitely be possible to get a lot closer than 1207.999309 though.
It seems the SDK function for dividing curves does not allow a tolerance override. It must be using some sort of hardcoded or adaptive tolerance. I need to talk to some developers in Seattle to see what -if anything- we can do about this short term.