Construct a tree of curves

Replies to This Discussion

Permalink Reply by David Rutten on February 24, 2014 at 2:29pm

[Entwine]?

--

David Rutten

david@mcneel.com

Permalink Reply by Rajaa Issa on February 24, 2014 at 2:32pm

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

Permalink Reply by David Rutten on February 24, 2014 at 3:19pm

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

Permalink Reply by Rajaa Issa on February 24, 2014 at 4:01pm

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.

Permalink Reply by Danny Boyes on February 25, 2014 at 3:31am

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}

Permalink Reply by Hannes Löschke on February 25, 2014 at 5:58am

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.

Permalink Reply by Rajaa Issa on February 25, 2014 at 9:28am

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.

Permalink Reply by Danny Boyes on February 25, 2014 at 3:18am

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.