Grasshopper

algorithmic modeling for Rhino

I'm trying to trace a curve that would be generated by a fixed length chord attached to a point on a rotating object. 

  1. I need the mid-point of the chord to always stay attached to a point of the rotating object.
  2. The chord must stay a constant length.
  3. The chord can "pivot" so that the angle of the chord to the rotating object can change.
  4. The end points of the chord must always be on the generated curve.

 

Here's a video that might help a little to explain what I'm looking for.  Any help would be greatly appreciated.

Views: 1301

Replies to This Discussion

Can you post the definition? 

Chris

Sure :)... here's the gh file.  It's kinda messy, but there are two views defined.  One is inputs where you will find a "Rotation" slider which goes from 0-360.  The other view is "Chord Curve" where I'm trying to build a constant length chord with the midpoint attached to a point on the tip of the polygon.  Then I want to generate a curve traced by the endpoints of the chord such that both endpoints will always be on the curve. 

 

That may ultimately not be possible to have the endpoints always on the curve while maintaining attachment to the polygon tip point.  If not possible, then the parameter that I would like to have "flexibility" in is the position of the midpoint such that the midpoint of the chord can move along the polygon center vector as the polygon rotates, but still maintaining midpoint placement on the chord. (ie. the chord midpoint can move closer/further from the polygon center as required to maintain endpoints of the chord on the curve.)

Attachments:

NormsWankel

Check out the screencast. 

Off Topic : How do you embed the screencast directly into the response as you've been doing?

Chris

Hi Chris... thanks so much for being willing to look at this problem.  I looked at your screencast above and while it did provide me with some creative ideas, it doesn't solve my problem.  The primary issue is that I don't know the curve (near ellipse) that is going to be generated.  It definitely isn't an ellipse.  I can only know the curve by finding out what curve would be resultant if the two endpoints of the chord were always on the curve.  It's possible that this has to be an iterative process?? Maybe record the path once (which likely would end up with two curves, one for the start point of the chord and one for the end point of the chord).  Then somehow use that first curve to "attract" the path of the chord the second / third / forth time through the rotation, eventually ending up with an interpreted curve that is pretty close?  I don't know, I'm just grasping.

 

As for the screencast... on jing there should be two different styles of links for sharing.  One is the direct link and the other is code for embedding.  Copy the embedding code and past into the comment video widget on the toolbar.

Hi Norm...I used the ellipse to illustrate the method of maintaining the fixed chord length and midpoint attachment.  I know it's not the curve you're seeking to generate.  My thinking is that if you can generate the curve that the tip of the triangle describes which is also the midpoint of the chord you can then use the tangent vector to that curve at the various points to give you the orientation of the fixed chord at each position.  This would then give you the points on the one curve or two curves that the endpoints of the chord describe.  Symmetry conditions suggest to me that it might be one curve that is generated but I'm guessing.  It's quite easy to generate the point set of the curve that the tip of the triangle describes by using a range component in place of the 360 degree slider but the way the definition is set up right now that also duplicates all of the intervening geometry which is processor intensive.  That's what stopped me last night.  I didn't want to crash my computer in pursuing that direction (not that I haven't done that before though).  I'll look at it some more today.

Ah, got it Chris.  I actually do have the tip path curve.  Go to the "Rotor" view and look for a "record" component.  Turn on the recording and then use the slider to rotate the assembly through the entire range.  That will generate the tip path.  I just need to internalize that recording so that the data isn't lost between gh startups.

 

I'm going to try using your suggestion for creating a constant length chord and see if that works.  My guess (and I'm pretty sure about this) is that two curves will be generated because the chord can't remain tangent to the tip path and also maintain endpoints on a second curve.  But I guess we'll see...

I'm curious as to why you need the chord path rather than just the tip path.  Is this a machining related need?

Also I've been making the assumption that you want the chord line to be tangent to the tip path.  This may be a mistake.  It occurs to me that you may actually want the single curve path whose chord midpoint will generate the tip path. 

Yes, the chord path is necessary for the project that I'm working on.  Think of it as a fixed length object who's midpoint follows as closely as possible to the tip path, but more importantly, because it is fixed length both endpoints must be on the same curve.

 

Your observation that the chord midpoint generates a tip path is pretty close.  I think there will be a tip path, and a chord midpoint path.  The tip path is fixed.  The chord length is fixed.  The chord midpoint is fixed.  Only thing I can vary is the path of the chord endpoints.  Hence my comment that it may be an iterative process of adjusting the chord path until the midpoint path and the tip path match as close as possible.

Here's the concept on the ellipse.  Tip path is fixed; chord length is fixed; chord midpoint is fixed; chord endpoints follow tip path in the limit as the chord offset distance approaches zero.

Attachments:

I disabled almost all of the Previews to reduce the computer redraw load and replaced the degree slider with a range component.  Now you have the endpoints of the chord available at various positions.  It does look like there will be two curves rather than one.  So much for my intuition. :)  The next step I guess is to simultaneously show the the mechanism.

Attachments:

Awesome Chris! (I'm having to start a new reply thread) Your last update with the 9_CurveThroughCord... gh file is a real novel way to attack the problem which I don't think I ever would have conceived.  I'm going to take some time to digest it.

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