Wish: Control over which branches wrap in Relative Paths.

Replies to This Discussion

Permalink Reply by David Rutten on January 31, 2014 at 6:02am

I wonder if it makes sense to encode the wrapping behaviour directly in the offset text. Something like:

{+1 (wrap); +1 (nowrap)}[+2 (nowrap)]

If you don't specify a wrap/nowrap constant then the Wp, Wi values are used. This would preserve existing behaviour even more and it opens up the possibilities of adding more wrapping behaviour in the future. For example:

• (clip), which will still create an [A|B] pair but limited to the 0-N range.
• (bounce)/(mirror), which will create an [A|B] pair but when the index overflows it is reflected back the other way.

What do you think?

--

David Rutten

david@mcneel.com

Permalink Reply by David Rutten on January 31, 2014 at 6:04am

Another thing I like about this approach is that it is an extremely expert user feature which is totally hidden from beginners and intermediates. It is also reasonably self-documenting.

--

David Rutten

david@mcneel.com

Permalink Reply by Danny Boyes on January 31, 2014 at 6:31am

It would be a little tedious having to write (wrap)/(nowrap) on every relative path wouldn't it.

e.g.

{0(nowrap);0(wrap)}

{+1(nowrap);+1(wrap)}

{+2(nowrap);0(wrap)}

{+1(nowrap);-1(wrap)}

{0(nowrap);0(wrap)}

Unless you could specify it in the first line

{nowrap;wrap}

{0;0}

{+1;+1}

{+2;0}

{+1;-1}

{0;0}

Maybe it needs a Wa input for Advanced Wrapping.

I like the idea of (clip) maybe there could also be the ability to build in a skip functionality with the patterns 0,2,.... Thinking about this you would just do it with other components

Permalink Reply by David Rutten on January 31, 2014 at 6:46am

You'd only have to write (wrap) or (nowrap), as the default can be set through the Wp input, but I get your point.

Using special lines for setting wrapping behaviour is possible, but a bit of a break from the way Grasshopper usually deals with inputs. It's a decent idea though, as it allows you to very accurately specify (and later re-specify) what needs to happen without any redundant typing.

{nowrap;wrap}

{0;0}

{+1;+1}

{nowrap;clip}

{+2;0}

{+1;-1}

{wrap;clip}

{0;-2}

It's a bit fuzzy what should happen if you supply a datatree of offset masks rather than just a list. Do the behaviour settings carry over from one treebranch to the next?

Do we still need Wp and Wi inputs? (I assume yes; for non-expert users)

A compromise between these two approaches would be to have every instruction become the default. Then you'd have to write:

{0(nowrap);0(wrap)}

{+1;+1}

{+2;0(clip)}

{+1;-1}

{0(wrap);-2}

Which is even less typing, but the input now becomes thoroughly unreadable.

Another solution which also results in less typing but which has a corrollary in Rhino would be use shorter codes for wrap, clip and mirror. In Rhino you can prefix coordinates entered in the command line with 'w' indicating you're using World coordinates.

{0;w0}

{+1;w+1}

{+2;c0}

{+1;c-1}

{0;c-2}

But again less self-documenting and less readable. I think so far I like your suggestion best (special lines that look like {wrap;clip}), but I don't like it a lot :)

--

David Rutten

david@mcneel.com

Permalink Reply by David Rutten on February 2, 2014 at 5:42am

Bump. 

Is everyone who has an opinion on this ok with Danny's suggestion?

{nowrap;wrap}

{0;0}

{+1;+1}

{+2;0}

{+1;-1}

{0;0}

--

David Rutten

david@mcneel.com

Permalink Reply by Norm Sash on February 2, 2014 at 7:32am

What about creating another input adjacent to O to specify a mask... maybe wM?  The default behavior if left alone would be the existing component behavior.  But if you specify {nowrap;wrap;clip, etc...} in the Mask input then that mask would be applied to all lines of O resulting in:

{0(nowrap);0(wrap)}

{+1(nowrap);+1(wrap)}

{+2(nowrap);0(wrap)}

{+1(nowrap);-1(wrap)}

{0(nowrap);0(wrap)}

This way, behavior is left as current for the component, but with just a single input on the mask, wraping and cliping could be modified.

Permalink Reply by David Rutten on February 2, 2014 at 1:54pm

Well, there's a number of things that irk me a bit about the 'additional input' approach:

• It makes the component look more complex for everyone, beginners and experts alike.
• It separates two data streams that really sort of belong together (not a very big problem, that happens more often in GH).
• It makes it hard to specify different behaviour patterns for different offset patterns without doing a lot of duplicate typing. I.e., to achieve this:
  
  {nowrap;wrap}

  {0;0}

  {+1;+1}

  {nowrap;clip}

  {+2;0}

  {+1;-1}

  {wrap;clip}

  {0;-2}
  
  You'd have to type:
  
  {nowrap;wrap}
  {nowrap;wrap}
  {nowrap;clip}
  {nowrap;clip}
  {wrap;clip}
  
  which is what Danny was unhappy about.

 

--

David Rutten

david@mcneel.com

Permalink Reply by Danny Boyes on February 3, 2014 at 2:34am

I think you have seen potential for this which I never imagined with the introduction of additional control.

I think important issues are:

• To have the desired control
• Not to complicate the component
• Not to destroy current functionality
• Keep it simple enough to be self explanatory when posting screen shots.
• Keep typing to comprehensive minimum 

Permalink Reply by Norm Sash on February 8, 2014 at 5:12pm

Hi David;

I guess either way works.  I just don't like mixing the data typing together and prefer to see the tree structure e.g. {+2;1} from the action that should be applied to it e.g. {nowrap;wrap}.  As to the complexity, it's just an optional input that doesn't need to be set.

That's one of the reasons I like the separate input better.  I don't think there is any extra typing because in either scenario you still have to type in the pattern the way you want it.  It ends up being the same amount of typing give or take a character or so.