The overlapping is the main readability issue for me so my2cent is to have wire that turns around component like in pcb design:
sorry for trolling. 
That’s more than 2 cents because this bring an interesting question, if harness are introduced in GH, where do connectors overlap ?
in GH, as in industry, connectors definitly need to overlap somewhere. First, let’s say “harness combine connectors that transmit data in the same direction”, then we can define “before”, “between” and “after” harness.
Then the question, where do connectors overlap ?
-
“before” harness ?
-
“between” harness ?
-
“after” the harness ?
my hint : just after harness for no overlap before an harness will help readability
CASE tools from the late 80’s onward were able to implement wire jumps without seeming to exhaust the limited processing power then available.
1 Like
Something like that would be nice to have in Grasshopper - and it would probably require some functionality to color-code wires…
Line/line intersections are a hell of a lot faster than bezier/bezier intersections. I’d rather spend the processor cycles getting a higher framerate on the canvas.
But is this really a problem? I have issues sometimes seeing where wires go when two wires overlap for a while. If they just intersect sharply it’s not that big a deal.
However if you start to trim out portions of overlapping wires you’ll get some serious cutting at inputs and outputs, with potentially huge portions of visible wires missing entirely.
Hi David,
I wasn’t advocating the idea, just questioning whether it really was too expensive in this day and age. I think it would be a nice touch but I suspect it would always be at the tail end of the backlog. Mind you, even there it would be way ahead of this weird kerning misapprehension!
Regards
Jeremy
One of the first UI-based compiled programs I ever wrote (VB6+GDI God help me) showed in realtime the intersections between several thousand different lines whose orientations depended on the mouse coordinate. I vividly remember being surprised it all ran in 60fps until I figured out the amount of arithmetic operations involved and divided that by the clockspeed.
It can probably be done for beziers too within a reasonable time. Might be nice challenge actually, but yeah, bottom of the stack for now.
It’s something I thought about adding to GH1, but never really got around to it. The Relay was a more obvious addition with more benefits to local graph clarity.
It’s not a bad idea, but adding features to GH2 which make large-graph-management easier is something I wish to postpone for as long as possible. I want to start by making it easier to split large graphs into smaller inter-communicating chunks without losing overview.
4 Likes
Thanks for the suggestion. The “relay” component is not something I related to harness but after your answer, it came to my mind that relay+group function could do the harness job. Incidentally, it could be helpful to untangle tangled layout.
The example below is an example of “relay” plus “group function” can work as harness
Once you have done the harnessing, you can untangle the layout by factoring relays that have a common source
In my opinion, it could be somehow automated.
while i liked the idea of grouping / harness, now seeing it - doesn’t it make things harder to read? You have to mentally trace a line across multiple relays that even branch of now and then…
I mean - its looks cleaner, but actually reduces legibility
Is there a method that allows the user to select the wire?
Not the start and end that appear when dragging an input/output but actually select and highlight the wire?
In GH2 yes. In GH1 no.
1 Like
Thank you @atair for the question. I apologize in advance for the long answer.
First, you are right, the above harnessing make things harder to read. “Relay+Grouping” is not enough, there is something missing, alas “Tagging Relays”.
With tagging, the harness is more readable (literally). Both images below are from a GH definition of a multi size egg cup I did for the fun some time ago and that I have redone with “Tagged Relay + Grouping”.
Notice that tagging is from the same breed than harnessing. It is also a best practice in aerospace.
Also, something interesting arises from the extra effort. A group of Tagged Relay is a structured group of related items. it is interesting because grouping things together is a cognitive psychology process called “chunking” (https://en.wikipedia.org/wiki/Chunking_(psychology)). Chunking is a critical process to manage complexity.
In software programming, there are some chunking solutions. Among them are “function” and “structure”. With a function, an abstraction is construed to group a set of operations. The equivalent in GH is the “Cluster” component. With a structure, an abstraction is construed to group a set of data. “Tagged Relay + Grouping” could be one solution in GH for structure.
egg cup v03 e.gh (57.2 KB)
1 Like
There’s one significant problem when using these relays, the wire visual type is not passed along through the relay, and you cannot right-click a relay to change the type.
You are right.
It could be submitted as a minor modifications to the Relay components “have the type appear near the relay”. Another one would be to have the name of the Relay Component always set with the name of the source component.
1 Like
Looking at the aerospace wiring loom image above got me wondering if being able to change the colour of the wires would help with organisation? Is that already possible with the sdk?
Cheers
Steven
3 Likes