Rotate plane question...

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

Attachments:

RotatePlaneQ.gh, 20 KB
RotatePlaneQ.3dm, 37 KB

Replies to This Discussion

Permalink Reply by Chris Tietjen on May 23, 2013 at 7:13pm

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:

RotatePlaneQ_Rev1.gh, 8 KB

Permalink Reply by Mitch Heynick on May 24, 2013 at 2:04am

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:

RotatePlaneQ_Fixed.gh, 25 KB

Permalink Reply by Chris Tietjen on May 24, 2013 at 5:36am

'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

Permalink Reply by Pieter Segeren on May 24, 2013 at 4:16pm

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:

RotatePlaneA.gh, 17 KB

Permalink Reply by Chris Tietjen on May 24, 2013 at 4:52pm

Where is parameter '1' for the closed curve?

Permalink Reply by Pieter Segeren on May 25, 2013 at 5:29am

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

Permalink Reply by David Rutten on May 25, 2013 at 5:55am

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