Grasshopper

algorithmic modeling for Rhino

Flow control: that is doing....and this....is doi..n..g....IM LOST!

Venerable GH community,

Is it possible to 'step through' a GH definition one component at a time in sequence to either debug or simply digest a large definition (or any definition for that matter, as its useful to understand how someone has structured their GH spag bog for example)? To elaborate, as each component is activated, the outputs (if applicable) are displayed in the viewport?

If creating large and complex definitions, management, maintenance and plain old comprehension become crippling; I find more time is spent reviewing what each part of the definition is doing, to then be able to tackle problems or continue development, than actually doing any work to it in the first place.

While clustering is an option, I feel it just sweeps a clear issue under the carpet rather than offering a solution: I want to know what is in my cluster and what its components are doing. Packaging them up hides the components from my immediate view and labours my work flow when having to jumping in and out to do edits or remind myself what is going on.

Has anybody experienced management issues with large definitions and found effective ways of controlling them?

Views: 596

Replies to This Discussion

Hi new user,

this is indeed a rather finicky problem. It is often very hard to read a large file someone else made. It's something I'm thinking about a lot but I haven't reached any terribly convincing conclusions yet. The list below roughly outlines my thought process so far (apologies for the stream-of-consciousnessish style)

  1. The problem of debugging a Grasshopper file can be broken up into two parts. First we need better tools for people to document their own creations. Then we need tools that help us dissect existing files which may or may not be properly documented/commented/structured.
  2. There already exist some ways to add comments and structure to files; Text Panels, Scribbles, Sketches, Groups etc. Let's call these features secondary, as they are added on top of the file itself.
  3. Perhaps we also need primary documentation and structuring features. The only example of a primary feature which is currently available is the cluster, and it's not particularly good at making a file more readable. Layers would be an example of a primary structural feature, but the question is how to implement them.
  4. Debugging a file basically comes down to understanding the point of each and every component. At the moment it is possible to get a sense for this by using the Preview Selected option and selecting those components one is interested in. This is a very coarse solution and I'm the first to admit it's cumbersome to use.
  5. An incremental improvement to the 'preview one component' approach would be to always draw input geometry in blue and output geometry in yellow, regardless of connectivity. And maybe include the non-previewable data (numbers, booleans and text etc) in the viewport as an overlay. Maybe the spyglass would be a good metaphor for this feature, in that an area of focus can be dragged freely around the canvas and every individual component can be highlighted in this way.
  6. Another approach would be to have a solution barrier. An infinite vertical line that can be easily dragged left and right across the canvas. Everything to the left of the barrier is solved and previewed, everything to the right is disabled and hidden.
  7. Unfortunately there cannot be a step-by-step feature as the execution logic of a GH file can consist of streams that split and merge. It is therefore not always possible to say which step is the next step.

If you have any additional ideas, be they vague or specific, this would be an excellent place to put them.

--

David Rutten

david@mcneel.com

Tirol, Austria

Interesting, 6 wouldnt work unless the canvas had a grid with 'slots' where each component would need proceed the last. 7 potentially could work if say, the definition executes completely, it stores the dependencies and then you can step through from the beginning and it will auto-highlight the next set of dependent components, which will execute when stepping forward.

 

3 seems best, maybe user defined tabs/buttons at the top of the viewport name each layer. It would be perfect for managing a large definition; its implementation would offer structure, logic and organisation - the three things I would like to see an improvement in for GH v1.0.

 

Maybe on each canvas, there is a blackhole/timewarp icon which links through to the next dependent layer?

Number 6 sounds good.
Number 3 also.

RSS

About

Translate

Search

Photos

  • Add Photos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service