Grasshopper

algorithmic modeling for Rhino

Hi guys, I'm currently working on a "V" structure for a project, and I want it to incrementally scale its size along a curve. Wat I did was copying it several times then scale all of them (see attached picture 1), but the thing is that the center of the scale must be at the end of every curve so it can be continous and not overlapping each other.

 I also tried to do the same thing but scaling them between two boundary curves (see attached picture 2 from rhino), but I guess I first need to know the logic of the proportional scaling process, so I hope somebody can help me out with this problem.

Any comment would be apreciated. Thanks!

Views: 9224

Attachments:

Replies to This Discussion

Thanks for the history of GH icons.  No offense to David intended!!  I don't have the entire list of GH components in my head so learning the icons is another level of effort with no obvious reward.

In general, screen shots of the GH canvas have little value unless they show only a dozen components or so, illustrating a particular relationship.  There are so many ways to miss important details trying to reproduce GH code from an image, like "hard coded" numbers, points, planes, expressions, etc.  One must go to a lot of extra trouble to reveal all those details in a screen shot.

I don't learn anything that way.  I need the code so I can go through it step by step and examine the outputs all along the way.

As to your incrementally scaled geometry, it appears that you have scaled three "construction points" that are used to make a "V" shape rather than scaling an arbitrary "geometry"...

The guts of your solution appear to happen at the 'Eval' component, after 'Range' and 'Graph Mapper' (see image); those points (blue) determine scale and location of the copies (very clever!).

What happens after that is just creating/orienting the "V" shape - it could be replaced by code that scales and orients an arbitrary shape using those same points.  Thanks for sharing!

Hello Joseph,

i agree that when uploading screenshots, one must be very analytic and display expressions, persistent data etc that are not visible with scribble or panels.  But assuming the screenshot is well done, recreating step by step the screenshot, i believe gives me more benefits when learning, instead of just having an uploaded definition to play with. It also gives the satisfaction of self achievement. Missing these details and finding them afterwards is part of the learning process. but that's a matter of personal taste anyway.

cheers

alex

Another important issue for me is to keep in mind what the OP has provided and reply accordingly (the "What You Give is What You Get" principle):

-A question like "How can I do this?" gets an answer like "You can use this component"

-A question with a screenshot of a definition gets an answer with a screenshot of a definition

......

and finally a question with a definition (with internalised data & everything) and a good explanation of the problem, deserves a proper reply, with a definition and a good explanation of the suggested solution.

That's a good guide.  When the problem isn't well defined (and GH code helps A LOT with that!), I skip it.  But when the subject interests me and might be something I'll use, I "worry it to the bone", getting every morsel of learning I can from classic problems like this one.  For my own satisfaction more than any sense of helping , but hey, a win-win is always best, eh.

I tapped your 'Couplets' and mid-point ('Avr') outputs as feeds for code that scales and distributes arbitrary geometry - in this case, a simple spiral - along the curve.  You made it easy!

I kept it very simple by just grabbing the center of the bounding box for the 'Geo' input and moving it to your mid-points.  Orienting to other points, tangents or 'Perp Frames' on the curve would be further refinements.

Thanks again Erik, very handy.

Attachments:

OK, I tapped your 'Crv CP' to the mid-point instead... :)

And I used 'DeBox' instead of 'BoxProp' to get a corner of the 'Geo'  instead of its center.

And instead of move, this version uses 'Orient' - with mixed results.  Not yet seamless.  Depends in part on Orient input vectors 'dA' and 'dB' - the only difference between the two viewport images below is using "-1" instead of "1" as the 'F' input for the Unit X 'dA' vector:

Attachments:

OK, third time is a charm?  Sorry for the drip, drip...  Basics.

Instead of 'Move' the 'Geo' to the start of curve, use 'Orient' with the tangent ('T') of the curve at the start as 'dB' - and use that again as 'dA' in the last group, 'Orient Scaled Copies to Curve Points'.

I don't need your mid-points, just your "Couplets" - the curve points organized as start/end pairs.

Attachments:

Lofting scaled, oriented curves - never would have guessed a spiral would loft so well (left surface in image).

Even two curves at once (blue spirals) that share end points, making a shell of two surfaces (open ends) on the right.

Attachments:

Hi Joseph, 

Thank you for developing the definition even further! The possibility of orienting the boxes along the curve without having them intersect one another is very useful. The loft is especially cool as well. I have not used 'orient direction' before so will dissect the your code and learn from it. I can definitely see some architectural applications with both of these. 

Thanks for sharing... very handy as well! 

Best, 

Erik

+1 @erik

Not that I could make much sense of the hieroglyphics (icons) anyway, but when I click on that first image, I get an enlarged version of the second image, not the first?

GH code would be very helpful in understanding how you did this?

right-click--->open image in new tab does the trick for me.

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