Simple List Management Query - Offsetting Multiple Curves Radially

Replies to This Discussion

Permalink Reply by johnnyUtah05 on July 8, 2015 at 10:28pm

Hey Leis, 

Here is a solution using a loop with the Anemone component. 

Attachments:

• Growth 2.PNG, 68 KB
• CrvOffsetQuery2.gh, 9 KB

Permalink Reply by Leis Ho on July 9, 2015 at 12:07am

Thanks Erik.

But does a solution not exist within the basic constructs of GH? I always assumed that I've simply misthought or forgot a simple aspect of managing my objects and lists.

Permalink Reply by FRiou on July 9, 2015 at 12:35am

Hello Leis,

I think your problem is indeed in your lists management.

Here is how I would solve your problem using only GH components.

Permalink Reply by Leis Ho on July 9, 2015 at 1:18am

Thanks! That's what I'm looking for.

Still seems slightly complicated for what it's trying to achieve, but perhaps I'm just optimistic; any other alternatives would be highly appreciated

Permalink Reply by Nik Willmore on July 9, 2015 at 5:00am

This is a great textbook example of how to think in lists within Grasshopper tree structures, which still deeply confuses me since I've been skirting around them using Python. The few tutorials haven't hit home yet. How do I think about this better, I wonder? What is going on here? Is there a diagram or flow chart I can sketch on paper to clarify why I need to simplify or graft in specific wire inputs/outputs?

Most of the circle vectors are in fact on the star, I note, even though they are acting on the circle points.

I replaced Friou's separate Graft component with an input wire graft on Move.

Just an English language thinking out loud description of why you are adding each wire modifier as you go, would be of great help. Yet even then, the day must be saved with the notoriously involved Path Mapper so even such a simple program requires advanced skills.

"You have two curves, so you graft those immediately, to create two separate calculation outputs. Then you do an series of offset operations on curve division points, for each curve, so...." - That's where I'm confused, is how to connect the English description to the wire modifiers and Path Mapper. Trial and error usually works but this has too many possibilities for that.

Permalink Reply by Nik Willmore on July 9, 2015 at 5:51am

Somewhat simplified:

If the Path Mapper is a Swiss Army knife, why must we both simplify and graft its input instead of have it do the work?

"Data trees have been a problem, even for me. It's often hard to work with them." - David Rutten ("Overview Of Data Trees" video)

Attachments:

• Manual Offset Curves HELL B SIMPLIFIED.gh, 19 KB

Permalink Reply by FRiou on July 9, 2015 at 6:24am

Hello Nik,

Here is something I learned about data trees management.

If you want your component to work properly with complex data trees, you must have coherent inputs.

Usually for me it means being in one of the three following situations :

- case one : your trees have the exact same data structure (number of branches, number of items in each branch) : your component will know exactly how to match each data and get the right result.

- case two : your first tree has n branches and a random number of items per branch, while your second has the same number of branches but only one item per branch : your component will work 'by branch' by matchng the one item from the second tree to each item of the first.

- case three : your first tree has n branches with one item each and your second tree is just a list : your component will then match the item in each branch with every item in the list (and thus multiply your data if your list has more than one item).

In the current situtation you have two curves : it seems logical as you say to split them and put them in separate branches.

Then you have a hundred points on each curve that you want to offset each five times with five identical values : you are in case 3 : you need to separate your points in different branches, then move each point five times.

You get a tree structure that is :

{Curve ; # of original Point on curve ; # of Offsetted point} or {C;P;O}

Since you want to create a curve between points that have the same C and O, you need to get rid of the P info, and you can only do that with the path mapper, hence my definition.

I hope I have been clear in explaining and that it can help you understand better how to make complex trees work.

Permalink Reply by Nik Willmore on July 9, 2015 at 7:23am

Case three {C;P;O} "input coherence" eh?

Yes, this is a nice puzzle piece to ponder, your translation of Rutten2David2.

My question remains: "If the (single input) Path Mapper is a Swiss Army knife, why must we both simplify and graft its input instead of have it do the work?"

Permalink Reply by Nik Willmore on July 9, 2015 at 8:25am

Here is my angry confusion: indeed, three levels of new manipulation and thus in my simplified version, three, exactly three grafts for inputs, for (1) multiple centers, (2) multiple curve points for each curve, (3) multiple offsets for each vector.

Fine, but then why this crap instead of something elegant?

Worst of all, there is no way to see if it's working "so far" as you make the program, since the end product just wigs out without your truly bizarre double simplify/graft input to a Path Mapper that has little to do with your case (one, two, three) matching of dual inputs!

I eventually think I may use Python for everything but I want to do so from a position of power instead of weakness.

Will Grasshopper 2 change this extreme learning curve, do you think?

Is maths just too hard for mortals?

Permalink Reply by Nik Willmore on July 9, 2015 at 2:23am

Are real offsets not the result you want?

Permalink Reply by Leis Ho on July 9, 2015 at 7:50pm

Thanks for the lengthy response.

I would easily opt for a bit of python scripting in any formal situation, but I was specifically interested in a simple elegant solution within GH without any "Tree Branch" components or "Dispatch"-like resolutions.

and no, real offsets weren't what I was looking for. I was actually running through Generative Algorithms by Khabazi and was profoundly confused by a seemingly simple task.

Permalink Reply by Pieter Segeren on July 10, 2015 at 5:44am

Hi Leis - guys,
here's a little variation that separates the circle(s) from the polygon(s). Minus one graft action. I figured you wouldn't want the blobby/bending star offsets, so I did this:

Attachments:

• CrvOffsetQuery___PSG.gh, 25 KB