Component request... CurveToPolyline

...as in Rhino's Convert command. Tolerance, max angle, min and max segment length inputs. I'm sure this has been requested before... Currently I am using a Python component I wrote, but would be nice to have as a standard feature.

Thx, --Mitch

Replies to This Discussion

Permalink Reply by Martin Dembski on May 4, 2013 at 4:18am

Hello Mitch,

there is also a Component for this in the DeCodingSpaces plug-in for Grasshopper developed at my university.

Best,

Martin.

Permalink Reply by David Rutten on May 4, 2013 at 7:03am

Done.

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Mitch Heynick on May 4, 2013 at 11:09am

Wow! Looking forward to it... Screenshot of mine...

Attachments:

Py-ConvertToPolyline.gh, 3 KB

Permalink Reply by Danny Boyes on May 4, 2013 at 12:54pm

What's the S? .... segments?

Permalink Reply by David Rutten on May 4, 2013 at 2:10pm

Yes, segment count. There's clearly room for 3 more outputs before the component needs to grow, any ideas? Shortening (absolute and/or relative)?

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Vicente Soler on May 4, 2013 at 2:56pm

The most obvious I think would be maximum deviation but I would be against adding outputs that increase the time it takes to solve.

I think I mentioned this in the past, but maybe in the future you could make a sort of ZUI that allows you to remove or add outputs and inputs. This way you can remove outputs that take time to calculate if you aren't going to use them and also can help reduce the total number of components by merging components together.

For example the could be a single divide curve component, once placed in the canvas you can choose with a zui what inputs to use (divide by curve, by length, etc.) and what output to use (points, frames, perp frames).

edit: I guess max deviation is tolerance, so ignore the first half of the first sentence :D

Permalink Reply by David Rutten on May 4, 2013 at 3:00pm

Length is very quick, that won't impact performance noticeably. Deviation would be slower.

It will be reasonably easy to hide certain outputs. But individual components will have to take this into account as it's not something I can impose top-down.

The kind of ultra-merging you describe would be a lot of coding, but maybe at some point the best choice we have for reducing the sheer number of components on the toolbars.

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Vicente Soler on May 4, 2013 at 4:02pm

That kind of ultra-merging will even raise antitrust red flags.

Permalink Reply by Martin Dembski on May 5, 2013 at 2:43am

Hello,

I've also some thoughts about that.

I agree the ZUI function like you expected for future developement would be very useful also in the regard of performance of large definitions.

But I think it would be also generate some problems, especially when you start to use or you teach Grasshopper because this would mean the same component can look very different.

From my experience the most people who start to use Grasshopper search for similar Components (starting to search for the name, etc.) when they follow-up a live or online tutorial or want to recreate a definition from an image.

Therefore there is already the problem that some components have the same name in the current version. (I always suggest to take the Icon view, because the Icons are unique but the most people I know prefer to use the Written Mode of the Components.)

Maybe this problem would be limited if the help becomes more detailed.

But it would still complicate the process of learning Grasshopper.

Maybe another solution could do the same like you expected and would be more user-friendly, for example if you could enable or disable individual inputs and outputs of a Component like you can do now with the whole Component and the text / variable of the disabled in- or output would be still visible but with changed or faded colors.

Best,

Martin.

Permalink Reply by Jesus Galvez on May 5, 2013 at 5:18pm

Hello David,

how about the domain of the (initial) curve where the vertices of the polyline lay at? I think that would be useful and it would save from having to use the [Curve CP] component which is sloooww when dealing with many curves/points.

What is the icon next to the Tolerance angle input in the component? And why isn't anyone asking? I guess I'm the last one to find out.

Permalink Reply by Vicente Soler on May 5, 2013 at 6:59pm

I think that component just implements the curve.ToPolyline() method, so unless he writes it from scratch I think it's also going to have to use curve.ClosestPoint to find the parameters.

Don't worry I'm also one of the last people to find out about the new stuff. I think no one asked because you can figure it out. The input is asking for an angle and those sliders have pretty large values. It's converting degrees to radians.

Permalink Reply by David Rutten on May 6, 2013 at 4:32am

Right on all counts.

Every input parameter that works with Angles now has an option to use degrees instead of radians.

David Rutten

david@mcneel.com

Poprad, Slovakia