Why can't curve analysis components wrap

I know that various curve analysis components throw a warning when the curve parameter supplied is beyond the domain of the curve. But I'm wondering why. If I have a curve (0-1) as shown below, why can't I supply a parameter of 1.5 and have the component determine that point?

Another good example would be using the length component. If I wanted to know a point at 1.275 times around the curve and then to calculate the total curve length from start to 1.275 I would think the component should be able to handle this.

Yes, I can do this by putting in additional logic, but it would be so much nicer and easier just to have it in the standard component.

At the least I would think providing a "wrap" option on the curve analysis tools would be really helpful (I know it would for me.)

Attachments:

Reparameterized curve.gh, 8 KB

Replies to This Discussion

Permalink Reply by David Rutten on December 7, 2013 at 11:29am

It's the way curves are defined mathematically. A single piece of a curve is just a set of equations that map a parameter to a 3D point. You can evaluate these pieces at any parameter you want and you'll get some point in 3D space. For practical purposes most curves are artificially limited to a certain domain, meaning that outside that domain the curve 'doesn't exist', even though the mathematical equations describing the curve work just fine.

In the case of curves that consist of multiple pieces (multi-span nurbs curves, polylines and polycurves in Rhino), the curve knows which sub-piece is responsible for handling a specific parameter. However once you go beyond the domain of that top-level curve then it'll just start evaluating the last piece outside of it's valid domain.

But that is all low-level talk, Grasshopper (and indeed the Rhino SDK) could provide high-level wrapper functionality that pretends closed curves actually have a cyclical domain. It would result in some inconsistencies between open and closed curves, but perhaps that's a small price to pay for the added benefit.

The alternative to us making the curve evaluator 'smart' if for us to provide a domain mapping component which allows you to easily change a sampling parameter from 1.5 to 0.5, given a curve domain of 0.0 to 1.0. This second solution doesn't remove any functionality, nor does it change behaviour of existing files.

David Rutten

david@mcneel.com

Permalink Reply by Norm Sash on December 7, 2013 at 11:56am

Hi David, thanks for the reply. I believe I understand the reasoning behind not allowing an input parameter to go beyond the domain definition, but I also think that the benefit of allowing it would really justify dealing with the small anomalies.

One of the simple problems that I find myself dealing with is finding how far (length) a point is on the curve. This is done using the LenP or the Eval component. Using either of these two components, if I provide a parameter greater than the max domain I either get what I consider to be an invalid return (LenP) or an exception thrown (Eval). What I really want to know is what is the total length a point has traveled if it has gone x.xx times along the curve.

Think of it as a wheel of y radius. It goes xx.zz rotations... what is the total distance traveled.

My thought is that a user selectable "wrap" enable parameter (as is available on some other components) that would enable a smart functionality to continue the operation as a continuous curve wrapping from the end to the start. That way it would be so simple to Eval length at a parameter x.yy times greater than the max domain value and get the resultant total length.

My thought on the alternative "domain mapping component" is that it wouldn't work out as well. For example if a curve domain is 0-1, and I want to sample at a parameter of 1.5 to get the length, I think this "domain mapping component" would only return a length to .5; but what I really would want is a length to 1.5. Does that make sense?

Thanks.

RSS