I seem to loose precision when I divide a curve...

Replies to This Discussion

Permalink Reply by taz on June 7, 2010 at 7:57pm

The "t" outputs you're viewing are curve parameters...

Curve parameters are a function of NURBS geometry and though in many cases curve parameters may be similar to curve length, they aren't the same.

This was a brief response to a previous discussion by Damien (NURBS geometry afficionado/connoisseur)

http://www.grasshopper3d.com/forum/topics/reparametricizing-a-bezier

You can do a Google search to find out more about curve parameters and NURBS geometry.

To check the length of your curve segments you can measure the length of sub-curve from 2 adjacent curve parameters.

• ▶ Reply

Permalink Reply by Emil Klagenberg on June 8, 2010 at 9:40am

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?

Attachments:

• Untitled-1.jpg, 139 KB

• ▶ Reply

Permalink Reply by David Rutten on June 8, 2010 at 12:35pm

Hi Emil,

Running some tests here on curves, but I can't quite replicate that kind of inaccuracy. Can you send me the 3dm file with the curve?

--
David Rutten
david@mcneel.com
Poprad, Slovakia

• ▶ Reply

Permalink Reply by Emil Klagenberg on June 8, 2010 at 1:30pm

I have a few curves on a hidden layer in this file, I send you my ghx defenition too, so you can see my problem.

Thanks a lot!

Attachments:

• 2010_06_04 facade pattern.3dm, 66 KB
• Divide crv.ghx, 140 KB

• ▶ Reply

Permalink Reply by taz on June 8, 2010 at 3:49pm

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...

• ▶ Reply

Permalink Reply by Emil Klagenberg on June 8, 2010 at 3:58pm

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.

• ▶ Reply

Permalink Reply by David Rutten on June 9, 2010 at 10:47am

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.

--
David Rutten
david@mcneel.com
Poprad, Slovakia

• ▶ Reply

Permalink Reply by Emil Klagenberg on June 9, 2010 at 11:05am

Does that mean that I can't really fix this as it is now?

• ▶ Reply

Permalink Reply by David Rutten on June 9, 2010 at 11:19am

Not entirely certain yet. Maybe.

--
David Rutten
david@mcneel.com
Poprad, Slovakia

Permalink Reply by David Rutten on June 9, 2010 at 11:07am

I ran the definition in 0.7 with the following result:

The length of the segment seems to be accurate to within tolerance. Is this different from what you're getting?

--
David Rutten
david@mcneel.com
Poprad, Slovakia

• ▶ Reply

Permalink Reply by Emil Klagenberg on June 9, 2010 at 11:19am

yes, I get 1116.178, that's with v 0.6.0059

But is there way to get it really even more accurate? I would really prefer it to be exactly 1208mm...

http://www.grasshopper3d.com/forum/attachment/download?id=2985220%3...

• ▶ Reply

Permalink Reply by David Rutten on June 9, 2010 at 11:26am

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.

--
David Rutten
david@mcneel.com
Poprad, Slovakia

• ▶ Reply

• ‹ Previous
• 1
• 2
• Next ›
• Page