Viewports in grasshopper?

Hi,

when working with large definitions, it frequently happens that you have to connect components that are very distant from each other. Usually one would just drag things closer momentarily, do the connections and put things back in place. This works well when you know exactly what connections are necessary. However when you are in the process of finding out how to make things work, in my experience this ends up with everything completely cluttered up, with several experiments or test in the same place.

One solution could be to have grasshopper support multiple viewports, though I know it would have it's drawbacks. For example, I think that for it to work well, you would have to change the drag and drop connection style for a click once (or double click...) and click again style, which has the disadvantage that it's slower and, well I think everyone likes the drag and drop :)

Another drawback would be that for those who work on one monitor, it would be like having gameboy sized viewports, so it would be next to useless.

On the other side another benefit would be added if you could have the viewports span more than one definition, for example having a viewport in your "toolbox" and another one in the definition your creating.

Replies to This Discussion

Permalink Reply by phillip on May 1, 2013 at 5:06am

Even though I wouldn´t jump in for your idea of viewports (because of the issues described above) I think this refers to a common problem:

If you need to connect components which are far away from each other it gets a little difficult.

It has been discussed several times in differenet ways here:

e.g.:

http://www.grasshopper3d.com/forum/topics/tabs-and-tabs?page=2&...

another idea was to be able to [jump] with a wire, but I can´t find the discussion anymore.

I´d just like to add another different proposal.

How about something like a dock?

You could drag a component into it and you are able to move somewhere both hands free via zoom or jump as before and drop it from the dock again.

Permalink Reply by Jesus Galvez on May 1, 2013 at 7:24am

Hi Phillip,

I wasn't aware of that thread. From his first comment it seems Fred are I are talking about the same thing. But from this comment it sounds like he is talking about something like the collapsible modules (is that the word?) of a script.

Your dock proposal would be something like a basket? I didn't really understand it. It sounds like something to store components, but how would it enable connectivity.

Permalink Reply by Vicente Soler on May 1, 2013 at 8:20am

What I usually do is just connect parameters to the outputs I'm interested in and drag them close to the work area so I don't have to be panning all the time if I'm trying different things.

Permalink Reply by David Rutten on May 1, 2013 at 11:36am

I rarely make huge files anyway, but when I do either the auto-scroll or mouse-wheel-zooming-while-making-new-wire works for me.

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Jesus Galvez on May 2, 2013 at 3:09am

Yeah that's what I do. The problem is that when I'm trying to make things work, I have to make several tries first and things get easily disordered. It was just a suggestion.

Permalink Reply by David Rutten on May 2, 2013 at 4:23am

I know that dealing with huge files is a drag. But doing something about this will probably require a redesign on some pretty basic level. Probably the first few months of GH 2.0 will be spend re-evaluating all the interface paradigms in GH 1.0 and seeing which ones work, which ones don't and which ones need work.

Layers, multiple viewports, wires as individual objects, ... these are all interesting hypothesis. Please keep suggesting them, but don't expect massive changes like these to make it into GH 1.0

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by phillip on May 2, 2013 at 4:10am

This is a screenshot of a rather larger definition.

The first group on the upper left would be the key design.

So the other different coloured groups are different parts of the project depending from the main part and sometimes from each other. Right hand analysis and baking.

As you see, graphically I mainly work with clusters (all bigger components with text display) and params to keep it organised.

Some of these key-values (marked green) are distributed to several places over the canvas.

So, yes it does work with auto-scroll and mousewheel zoom, within constraints.

Not sure about a mouse, but since I work with a tablet, but I can´t do two things at a time. Speak, I can´t select an item and zoom in or out with still draging it somewhere else.

When zooming out, the component I want to move far away may be really small and difficult to grab, so you have to zoom half way to drag it with several steps.

I barely use [jump], not because I think its a bad idea, but they won´t let you transport anything.

To the idea of a dock:

Imagine it a little like a displayed multi level clipboard. So items could be dragged or copied (ctrl+c) into it and stay there until used again somewhere else. You could also use it as a permanent storage for key-values.

Components in the dock would stay connected to their inputs. They could be dropped multiple times or just once. It would be illegal to have a component with a connected output inside the dock and you can´t connect anything inside the dock either.

I believe it could help you to stay organised, be more focused on what are your main key-values, and simplefy movement across the canvas.

Permalink Reply by phillip on May 2, 2013 at 4:12am

Sorry Jesus to hijack this discussion about viewports.

Permalink Reply by Jesus Galvez on May 2, 2013 at 4:49am

Yes I've also started doing large clusters. It helps a lot to keep things tidy. A problem I'm having though is that I'm using the same cluster for three workflows, each of which needs tweaking to work properly. But it's just a problem of figuring how to make the definition work.

I like it how you have it organized. I better start using groups more often...

Now I can see the functionality of a dock, specially for those who work on a tablet ;) Likewise viewports would only make sense if you work on a multi-monitor setup. So I guess we're both defending our camp :)

No problem at all about hijacking this; I've already learnt two or three things!

Permalink Reply by Danny Boyes on May 2, 2013 at 4:23am

Nothing to do with Viewport/Split Screens/Tabs/Layers on the canvas but....

Handy tip for the time being.

Connect wire locally to a param.

"Cut" the param using Ctrl+X

Move to the area of the canvas you would like the new component.

Paste using the Ctrl+Shift+V option to paste in middle of screen

Hook up new component Locally.

Another handy tip.

If you have a component that you have multiple inputs for and want the same inputs on another similar component Then:

Copy and Paste established component.

Create new similar component

Using the Ctrl+Shift drag wires option move the inputs from Copy/Paste to New Similar

And then delete the unwanted component

Permalink Reply by Jesus Galvez on May 2, 2013 at 4:53am

Thanks David! I didn't know connecting remained when cutting/pasting. And though I was aware about moving connections, I guess old habits die hard. It's a nice tip I'll have to take up.

Yesterday I was having a data-matching problem until I and came upon your examples. So thanks again.

Permalink Reply by Danny Boyes on May 2, 2013 at 5:05am

I completely forgot I had done that.

I remember now that Ning fell over when I was making the FAQ post and didn't save the hours of work I put in with the explanation of each and pasting all the images that that definition produced.

I should give it another go when I find time.... thanks for reminding me

Danny