Grasshopper

algorithmic modeling for Rhino

This might be a silly question but, is there any way of setting GH to always use faint wire connections by default?

Views: 2064

Replies to This Discussion

There is no setting for this. It is possible to modify wire display via a script though, see attached.

Far from ideal, but the best I can do at the moment.

--

David Rutten

david@mcneel.com

Poprad, Slovakia

Attachments:

Very interesting David, huge piece of coding knowledge there!

And btw, the file is on GH 0.9.0001... so intriguing! ;)

New release is coming :D

Wow, this is coming in so handy right now ;)

Maybe it could be a little dropdown or option at some point, but this works right now. Then a great function would be to "hightlight downstream" - all the wires are faint and then when I select a node all the connected downstream wires turn to normal, so it becomes really easy to visually see the data flow.

But for now this is just what I need. I was seriously contemplating doing this by hand. I dont mind large patches and wires going everywhere, but switching between wire display types was always so tedious. Now if only those bloody group labels would be OVER the wires and not under :/

Wow, that is insane... ;) You may want to consider starting to cluster stuff...

Well I guess things can get pretty elaborate.. ;)

Yeah of course I know about clustering, and in fact what you are seeing is part of a cluster already. Here is the whole thing:

(those red nodes are there because I dont have one of the plugins on the laptop).

Here is the outside with all those inputs:

I know its a lot, but its all quite logical if you build it from scratch. I have been working on it for quite a while (3 months) at work now tweaking and adding functionality. Most parts started in smaller patches and from a lot of work in vvvv (another node based programming tool) over the last 3 years. I cant really show or tell what it does, but I might make a video showing what it can do. 

There are actually a few clusters inside that big one, for some minor functions. Unfortunately Grasshopper is not too great in dealing with programming in clusters. Things only update that are inside the cluster you are currently working on and you can only work on one cluster at a time, so its actually easier to have everything in one large patch. Also to quickly reuse outputs from things further up, its much easier that way. And now that I can turn all wires to Faint or Hidden at a click of a button, its even easier! :)

I am very curious now to see that video.

And btw, it totally looks like you are at the perfect moment to start learning how to code... ;)

I have been coding for quite a while now - nothing major - some PHP, Jquery, CSS, a bit of Python in Maya - you know, lets say the simpler ones.. ;) But I am a huge fan of node based programming, because to be honest if i was to even try to comprehend how to code that definition in written code my brain might explode. I have done a lot of work in vvvv, which is similar to Grasshoper, but its Grasshopper as if it was made by German computer nerds.. which it is. Its much more universal and powerful (its recalculate times are measured in milliseconds) and opens a lot of possibilities in terms of real-time stuff, but in terms of how it works and is structured is very similar to GH. I was using vvvv together with GH before which was a lot of fun. In fact the whole chain went like this: Midi Keyboard -> Native Instruments Kontakt (a virtual instrument software) -> Apple Logic Pro -> RFTPmidi (transmit midi via ethernet to windows computer) -> vvvv -> OSC over Ethernet to third computer -> GH -> calculate stuff -> send result back to vvvv -> create a native Maya file -> render Animation. I should dig out THAT video as well..

as a matter of principle, giant clusters like this can actually be a big problem - because when un-clustered, only those components of a definition whose inputs change calculate; when clustered, any time ANY input to the entire massive block changes, the ENTIRE cluster will recalculate. 

I actually agree with that, but in this case it is not really an issue. The whole cluster actually does one very specific thing and for the most part the whole definition needs to be recalculated anyways (lots of interconnections and dependencies). Depending on the size of the output it recalculates in around 1-5 seconds max. While working on it I often actually disable the solver completely and press F5 (recalculate) when ready to try it out. Most of the recalculate time is caused by a hand-full of nodes (offset or mesh outline). I will try and put those inside a small cluster to not have them recalculate if not necessary while working on it - thanks for the tip! :)

@David Rutten Thank U4U :)

RSS

About

Translate

Search

Photos

  • Add Photos
  • View All

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service