Grasshopper

algorithmic modeling for Rhino

Hi,

I needed to construct a tree of curves from separate input curve lists. I sort of expected the "merge" would do it for me, but I had to change the paths first as in the image.

Is there an easier way to do this?

Views: 1132

Replies to This Discussion

[Entwine]?

--

David Rutten

david@mcneel.com

Yup! Would it be possible to make the "Curve" do it at some point?

It's possible, do you think it's a common enough operation to put an extra menu item on every single parameter? 

--

David Rutten

david@mcneel.com

Not sure if it is worth your trouble, but it sure feels more intuitive to behave this way now that GH supports trees. If implemented, we can always get the flat list with flatten.

I think it would be better not to implement on the components inputs. Maybe the answer is to slightly change the way [Entwine] works.

Rather than flatten the whole branch down to {0;0} and {0;1} but to have several options available like to have it maintain the current input path structure but append an altering path integer to the front.

e.g.

{?;?;?} ---> {0;?;?;?}

{?;?;?} ---> {1;?;?;?}

or to have the Primary set to an input to follow that mask

{0;0} ---> {0;0;0}

{?;?} ---> {1;0;0}

It the Flatten input option is set

{?;?;?;?;?} --> {0;0}

{?;?}          --> {0;1}

I'd think it would be better not to implement that. This is a personal opinion and might be biased by my workflow.

I hardly ever use entwine but make use of multiple connections (Merge) a lot.

This would totally change the current behavior. Right now, multiple connections behave like Merge and combine several lists into one for matched trees. Keeping every input on a separate branch like Entwine is not what I would need as a default behavior. Flattening as it is implemented now would destroy the original trees. You'd need an option to keep the tree for each connection and another one to flatten each connection as current Entwine behaves.

For my typical project, that's a lot of overhead (option checking and entwining) for a behavior, I'd typically not use and that can be implemented where necessary with an existing component.

Another point is readability and flexibility. I tend to use Merge just to break out all connections to separate inputs. You can easily see the order of connection and change that without diving into menus and submenus.

Finally I do support the notion of Entwine keeping the tree of each input intact.

Thank you for participating in the conversation.

The more I am using GH, the more I am finding that I sometimes have to "guess" the outcome of one component or the other when it come to constructing and processing trees.

I am not sure what the right answer is in each case, but I do think that there should be a consistent behavior that is predictable and is applied to all components.

This is doable at the moment by going to Manage Curve Collection on the context menu

EDIT: of course this does not detract from the fact that you have to manually type this path number.

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