Grasshopper

algorithmic modeling for Rhino

Last one for the night...

I am getting a certain number of curve perp frames along a curve and rotating them over a range to get a twist.  The funny thing is, if it's an open curve (like a simple line) it works fine but with a closed curve (like a circle) although the perp frames are correct, the last rotated frame is not concurrent with the first one, it's superimposed on the next to last one...

There is obviously something I'm missing here...  Simple example attached.

Thanks, --Mitch

Views: 897

Attachments:

Replies to This Discussion

The workaround is to make the closed curve an open one by an infinitesimal amount.  It seems like the PerpFrames component should give us the option to generate the start and end point of the closed curve rather than just the default start point only.  This may be a limitation of the SDK.

Attachments:

Hi Chris,

Thanks.  I don't know how many times I looked at this, but I looked at again this morning and FINALLY realized that PerpFrames is returning a short list with a closed curve - it doesn't return the last frame which should be the same as the first frame.  So the list length is one less and I'm getting data mismatching...

I would rather not go the route of opening up the curves - for me that's a can o'worms - but rather just grab the first frame in PerpFrames and add it back at the end of the list to make the list length match again.  Then things work logically.

In most cases I don't have to do that, as if I'm creating something like a closed loft through the curves on the frames, I don't want the last frame anyway.

I guess this is consistent with the way DivideCurve works - I just have to remember that this is different than, say, control points where the list returns both the first and last points.

--Mitch

Attachments:

'Thanks.  I don't know how many times I looked at this, but I looked at again this morning and FINALLY realized that PerpFrames is returning a short list with a closed curve - it doesn't return the last frame which should be the same as the first frame.  So the list length is one less and I'm getting data mismatching...'

I'm hoping that David will notice this and explain why we can't have the option to add the end point to the closed curve rather than just the start point when doing DivideCurve.  Then the lists would automatically match.  This also seems to cause issues with Sweep2 on a closed curve.  

Chris

Hi Mitch, hi Chris,

I think this behaviour has 'always' been like this. But I might be missing the point.
I made a definition that takes both open and closed curves. But I might be missing the point...~:)

Attachments:

Where is parameter '1' for the closed curve?

It's not there, and I think it never was.
I guess we should ask for a closed/open input for the Sweep components.

If there are multiple, equally valid solutions for a closest point problem the resulting parameter is always unpredictable. For closed curves the startpoint equals the endpoint and Rhino really can't tell whether {3.65,2.455,0} is supposed to mean a point at t=0 or t=1. This information is simply not stored inside the point data.

--

David Rutten

david@mcneel.com

Poprad, Slovakia

RSS

About

Translate

Search

Photos

  • Add Photos
  • View All

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service