Visual cues for data trees

I am proposing an idea to help stay afloat when manipulating data trees.

The idea would be to use font colors on indices and paths to keep track of what they represent.

In the following example, the red color represents the original surfaces (parent objects) , the green color are the curves created from the surfaces, and the blue color represents the points created from the curves.

In the last panel on the left, even though we have gone through a somewhat disturbing "Shift path" component, it is easy to see that we are looking at lists of points created from each original surface.

Let's see how long it takes for someone to pop my bubble... :|

Cheers,

Replies to This Discussion

Permalink Reply by Olivier Suire on December 23, 2015 at 3:25am

Not interesting enough to trigger enthusiasm ?

Not stupid enough to be ridiculed ?

It's tough to be in the "disdain" zone...

Permalink Reply by ng5 Alex on December 23, 2015 at 7:02am

been there :-(

Permalink Reply by Olivier Suire on December 23, 2015 at 9:23am

Wow...

You would think that any proposal to helps with the herding of data within GH would attract a minimum of attention...

By the way, thanks for making me discover the "Data Viewer" !

I will spare me littering my definitions with panels, and it would be a great place to implement a color coding of paths and indices.

There should be at least a way to tell whether the data which is listed is inherited or not.

If there are text or numeric values that are not inherited, it would indeed be convenient to have the ability to edit them from the data viewer.

Cheers !

Permalink Reply by ng5 Alex on December 23, 2015 at 9:33am

yes, our suggestions are somehow relevant, so non inherited color codes could be changed on the fly with data viewer etc. I am trying to locate a thread suggesting something similar about trees, with you color coding, but alas, haven't found it yet.

about the data viewer, trees and the handling of data inputs in general, from many threads about gh2, i believe we are going to see some nice changes.

lets wait and see.

best

alex

Permalink Reply by Daniel González Abalde on December 23, 2015 at 3:58am

The indices of the last panel they not should be green?
I do not think it's a good idea to group branch depth in colors, because you're joining something that is separate. That is, the branches {0, 1}, {0, 2}, {0, 3}, {0, 4} ... are within a road, and this road has 4 lanes. And the branches {1; 1}, {1, 2}, {1, 3}, {1, 4} ... are in a different road, and it has four lanes. But all lanes of the two roads are in different spaces, are different roads, thus unify with the same color can lead to confusion.

Also, if the branches are not simplified, it would be a rainbow! Too much information for something that actually is quite simple. The topic of the branches only is complicated when is required operate with separate trees, ie marry two roads having different lanes.

But would be nice another method of visualizing branches, but from my point of view would be better, for example, coloring the entire contents of the branch {0, ?}, and maybe with less saturation the lanes, and another color for the content of the branch {1, ?} .

Permalink Reply by Olivier Suire on December 23, 2015 at 5:18am

Hi Daniel,

The colors trace the parent-child structure.

The indices in the last panels represent points, not curves, therefor it makes sense that they are blue.

The idea is to keep track of what the branch numbers and indexes in a tree represent, not their hierarchy within that tree, which is fairly obvious.

In a complex definition, I often lose track of that and I need to "rewind" sometimes very far back to understand what I am looking at in a particular component.

Permalink Reply by Daniel González Abalde on December 23, 2015 at 5:54am

Ahh, I had misunderstood sorry. Then someone who had this need can comment better than me, not would be best coloring panel-data instead of the panel-tree topology? I feel like I'm missing something, but its ok x).

Permalink Reply by David Rutten on December 27, 2015 at 1:02pm

The colours trace the parent-child structure.

Unfortunately there is no record of the structure over time. Each data tree just exists on its own, and it is often not at all clear where exactly data comes from. If a datatree contains points that were merged from red and blue trees, should it appear purple?

As human beings we (on a good day) understand what a component does and how the outputs relate to the inputs. Grasshopper itself however sports no such understanding. Components are just black boxes whose inner lives are beyond comprehension.

There are definitely cues that could be highlighted with colour accents, for example the path elements could be drawn with a faint grey to indicate that all paths in the tree share the same number at that location. Or perhaps the alternating background light/dark fills could switch from one base colour to another when the path changes drastically. I.e. {0;0} and {0;1} would be two slightly different shades of green, but {1:0} then jumps to blue instead, and {1:1} would be a slightly different shade of blue. {2:0} would become brown, {3:0} purple etc. etc. This might make the overall structure of the tree much more visible.

But I don't see a way of colouring the paths elements as a function of their logical histories.

Permalink Reply by Olivier Suire on January 7, 2016 at 8:09am

Mmm...kay, got it.

How about "pop-up" data viewers for each output : it would save having to paste a panel and connect it.

Also, it could be hidden, moved around, and closed at will.

There could be some kind of user annotation features to help people keep track of how the data is organized / what the branches represent, at least at a point in time.

It's not perfect because it's not dynamic, but it's something...

Happy new year David, by the way :)

RSS