[WISH] Depth map mode in canvas

Replies to This Discussion

Permalink Reply by David Rutten on November 4, 2015 at 2:21am

Wouldn't measured runtime/area be a more useful metric?

Permalink Reply by Ángel Linares on November 4, 2015 at 3:05am

Yeap, as I mentioned both modes could be interesting. Runtime could display how heavy is a definition part and where you need to focus in order to optimize it, but components/area ratio could help to spot areas in with some python/VB.NET/C# code could help making the code more readeable, or just spot clusters in big definitions that in other way (and using the text visualization mode in components) are complicated to find and analyse. 

This could be helpful in an environment where lot of people creates and modify definitions (with different resources, background and techniques) and you need to have a general view of what "kind" of definition you are dealing with. 

In this way this visualization system could be improved to show desired kind of components (code components, visualization components, third-party plugins...), everything in a very visual way.

Permalink Reply by Armin Seltz on November 4, 2015 at 6:45am

I think thats a good idea. I like your last point - a way to instantly visualize what sort of components are in use, what plugins, etc. A bit like a summary of all the dependencies there are or like an easy way to show compatibility. For example if there is a component from Kangaroo than it would show that. It could even be embedded in some sort of metadata in the file. Just something that shows what that particular file requires.

Look at this example. I have a lot of plugins installed in GH. Sometimes I just use of the components from one plugin and one from another. Now I am working on a huge patch and in the end save the file and need to give it to someone else. How can I know what plugins they will need and what versions. Would be nice to have that information.

Also a way to visualize Clusters and custom Code would be great so they are more obvious. I make a lot of clusters and give them nice icons and everything. So sometimes I come across a part of my patch and dont remember what component it was until I realize its a cluster I made myself, so a visual cue like a slightly different colour or shape would be good.

I think GH is incredible and from a UI point of view is great for small patches. For large ones its not so great yet and there a lot of improvements I can think of for grouping, clustering and getting some order in large patches. I think a few of them were mentioned in the Pain Points discussion.

Permalink Reply by Ángel Linares on November 5, 2015 at 2:29pm

Mmm...more ideas: lines_of_code/area could be useful to identify heavy scripted components...or non-built-in imported modules/libraries. Lists or trees data amount/area could help to identify data flow through the definition, looking at it with naked eyes you cannot predict how-many data is flowing through the "pipes"...

We could think for sure in other useful data to represent in that heat-map...

Permalink Reply by David Rutten on November 5, 2015 at 2:59pm

So on the understanding that none of this will ever make it into GH1 (and will only make it into GH2 if I suddenly find a lot of spare time), I can imagine the following metrics are interesting to see as a heat-map or contour map or something:

• Performance runtime (i.e. how long did the component take to solve the last time?)
• Memory footprint (i.e. how much memory is this component using. This will necessarily be a very vague metric as it is nearly impossible to get an accurate measure on that, and not just because memory is often shared between different components.)
• Data size (i.e. how many items and how many branches does each component have? A single large mesh may require more memory, but is conceptually a lot simpler than a boolean tree with 523 branches, 209 of which are empty.)
• Display performance (i.e. how long did it take to draw the preview geometry for this component? This will probably need to be a running average because each viewport might result in a wildly different display metric.)
• Complexity (this is difficult to define, but complexity should be a measure of potential problems with the file. Expressions, scripts, certain components such as Path Mapper, and clusters could all be indicators of complexity, as could connector valence.)

Properties that would benefit from a listed display rather than a map would include:

• List of components used, and how many of each (this just screams for a histogram display)
• List of plug-ins used, and how many components of each.
• Types and amounts of data (i.e. how many unique breps does this file actually contain? Ideally formatted as a Buzzfeed listicle)
• List of expressions.
• List of scripts.

Permalink Reply by Ángel Linares on November 6, 2015 at 5:36am

It was clear to me from the beginning knowing the development state of GH2; don't worry I'm totally aware of that.

I think that as a graphic coding environment grasshopper have some pretty nice opportunities offering new tools and ways to understand dataflow, performance analysis, logic constructions, etc. Over that statement, I've always observed that a definition is full of information at component level or small groups, but that informed-user-feeling disappears exponentially while you zoom out an get a more general picture of a big definition (small definitions are not a problem due to the good level of information supplied at that zoom factor).

So I though, why not to use this graphic potential to lead to a more complete data representation at low zoom factors in big/very big definitions? Have you ever noticed how annoying is to review big definitions captures printed in A1 project panels? These captures lack any kind of useful information (even if you are an expert in GH)...you can only conclude looking at them how organized or well planed was the definition coding process...but nothing else (not really, you can conclude other stuff, but not at the level that you could expect from a graphic-centric coding tool). Some users has invented ways to give more data to third-person users/tutors...: using panels with text scaled up, using scribble components, importing drawings from rhino...is even more frustrating if you want to explain how the definition works using one of those captures...there are not landmarks, etc to support your speech.

All this lead us to include certain components search (by name, plugin, tab...) into our mapping tool. Could be nice to be able to stack several layers of information visually, and it could lead to a better understanding on GH definitions as a whole and not as small pieces linked together. 

Sorry for the big "tocho"...like we say in Spanish.

By the way, the histogram thing sounds great :D

Permalink Reply by Armin Seltz on November 6, 2015 at 8:32am

This sounds great and I agree with the points Angel makes below. 

I too feel that annotating and documenting the patches could be better. First I was using the Properties field in empty cluster to get a sort of on-hover tooltip, which works pretty well and now have gone back to panels. Scribbles are nice visually, but dont really support multiple lines, while the Panels work really well, but dont look nice visually (for a lack of inside margins).

I hope one day the things you mention make it into GH 2 or 3.

Till then we will make do with the amazing tool at hand and live with the workarounds. But as long as we are making small lists or wishes, here are some that I would love to see for working with large patches specifically:

• Persistent floating Navigation Map
• Floating Panel with saved views
• Floating inspector showing information about selected component (like in vvvv)
• Better clustering (not duplicating inputs/outputs)
• Breadcrumb showing cluster depth (like drilling into groups in Illustrator, PS, etc.)
• Floating clusters, so you can edit cluster and parent simultaneously
• Unclustering!
• Better grouping

Can't wait to see whats coming up and of course most importantly the day we get GH for Mac.. but I digress.

Permalink Reply by David Rutten on November 7, 2015 at 4:44am

(for a lack of inside margins)

If you zoom in on the panels you can drag the margins inwards.

Permalink Reply by Armin Seltz on November 7, 2015 at 7:04am

Oh brilliant, thats so good to know! I will try out. You just thought of everything.. :)

Permalink Reply by David Rutten on November 7, 2015 at 4:47am

I agree with most of these. The ability to document and navigate files is a major feature for GH2. I don't know how much of the above will be available until it's written of course, some of the stuff is trivial to code, some of it is diabolical.

Can I ask what 'Better grouping' means to you? 

Permalink Reply by Armin Seltz on November 7, 2015 at 7:27am

Sure. The way Grasshopper components are laid out on the canvas they are basically flat. You dont really have components overlapping, because there is plenty of space. But then you start grouping things together so you can separate blocks of components into groups. I also sometimes group single components to give them a color outline and the name tag, so its like a little comment. 

But once you start grouping groups together things can get a little tricky, because all of a sudden you need to worry about Arranging. So you group some groups together, but the smaller groups inside are behind the larger group and you cant get to it anymore. So a lot of times I am grouping things together, then ungroup again, change arrangement and so on.

So basically I think it would be good if groups didnt have or didnt need the arrangement. Surely in most cases you want the smaller group inside the larger one to be at the highest Z value, ie. on top.

Another small thing, not really limited to groups, but most prominent there, is the way selecting color and the color picker works. So many times I have to manually try to match a color of other groups manually (I use the colors also to distinguish groups with similar functions). Sometimes I use the "make default color" to make a new group with the same color. It would be nice to be able to save colors as presets or the colorpicker to not pick the visual color, but actually the settings. Groups are slightly transparent, so using the color picker the actual color the group becomes is a different shade because of the grey background it sits on. So the color picker should be more like it works in Indesign, where you actually copy the style of something, ie. color, transparency, etc.

I think its the same as the points about clustering. It works and its great that its there, but its just not 100% ideal yet, whereas most other things are in my opinion.

I have to say, being an interaction designer who uses Grasshopper, I fully appreciate that it has one of the best user interfaces I have the pleasure of using daily and even more so on Windows where the general standard of user interface is extremely low. May I ask who is responsible for the UI and UX of Grasshopper? Do you do it all yourself or is there a team?

Permalink Reply by Armin Seltz on November 9, 2015 at 6:40am

Can't believe I never noticed the "Data Viewer" That thing is awesome!! *massive facepalm*