Pain Points in Grasshopper

Replies to This Discussion

Permalink Reply by Santiago Diaz on June 7, 2015 at 1:19am

An alternative could be that when you write "width", as long as it is not a protected name, it will change color (i.e. green font) and have a null value by default.

Then the assignment of value can be either from a slider, per your example, or from a widget per Mateusz' suggestion.

I feel that if this works initially for single values only (as opposed to a List of values per variable) it will be very useful and natural for the designer.

In the scenario of copy/paste of a network: here I think that Mateusz' idea solves the issue in that the document's global variables are included in the copy/paste. If there is 1 or more global variables of the same name(s) in the destination file, a single question can be asked, similar to when copy/pasting files in windows: there is something else with the same name, do you want to keep this or that or both?

The difference being that often I set up clusters containing sets of variables, each pertaining to a different design option. Using branches, I select one of the sets to assign which values are used.

If GH had a feature that addressed specifically this need for switching from one set of variables to another, this feature could be yet another option provided upon a copy/paste of global variables.

On the problem of document agnostic clusters:

I recall there was a version of GH in which when you opened a definition from the previous version, panels would dissappear. This was a few years back, I think. In one project I had more than a few numeric values defined with panels, it was a short-lived nightmare to solve this. So I can imagine the potential trouble of relying on a bunch of values which then dissappear when copying a cluster into another definition.

But this can be handled if global values are included in the copy, no?

Permalink Reply by David Rutten on June 7, 2015 at 8:25am

But this can be handled if global values are included in the copy, no?

Yes, provided they don't conflict with already existing globals in the target document. It would require adding a whole new layer of data sources to the document though.

Actually it would be fairly trivial to add such a feature at any time, since the new setup is flexible enough.

Permalink Reply by Ángel Linares on June 18, 2015 at 12:46pm

Today I got a flashback about this topic coding this component...

I know that those outputs could be grouped in DataTrees and accessed via DataTree operations later (for instance, pExt, pInt, pPed, pPark, etc., could be derived to [0;B;C], [1;B;C], etc., structure...because the [B;C] structure is already present in those outputs), but is so time saving to give then the proper structure directly to the output...

That component build the complete simplified model ready to export for FEA and report design values of a building to control the design process.

Probably global variables "a la" Dynamo could solve this letting you split the coding process easily.

Permalink Reply by Mateusz Zwierzycki on June 18, 2015 at 6:06pm

This could be solved easily if you could pass your own object between components (I think someone already asked for that in another discussion).

Permalink Reply by Anders Holden Deleuran on June 19, 2015 at 5:21am

This also looks like a case where wrapping the data in a dictionary/hashtable would be a good approach. This is fairly straight forward with GHPython and probably C# as well. It'll likely make the component computation faster as well (as per the bottlenecks thread). Perhaps it makes sense to add a generic GH dictionary class for wrapping/passing data around?

Permalink Reply by Ángel Linares on June 6, 2015 at 12:10pm

Yep, I totally agree, but sometimes some code blocks are very difficult to break in smaller functional pieces, and sometimes is more about a third user using your definition without tons of knowledge in GH...so this kind of things could help to visually separate concepts or just to say "touch only the variables in the first group to make this, the others in the second for whatever..."etc.

I know that clusters try to make this kind of stuff more user friendly and easier but, let's be honest, create clusters is sometimes a pain in the ass when you need to organize more than 5 inputs/outputs, because it requires to desconect and reconnect all inputs/outputs with those special components created with the mission of letting know to the cluster which inputs/outputs you need to show to the user; and the worst thing: in that process you destroy for some time your definition and the visual feedback that you have in the viewport...(at least as far as I know about cluster creation)...

And what about edding support for some data types to create special inputs (as radio buttons, toggles,...)? It could help to compact the definitions.

My main concern is being able to create as easy to use as possible GH definitions and custom components. Perhaps the remote control panel is the answer...I don't know...

Thanks for being there and listen the suggestions that we through in.this post, as children in front of a ice cream truck...I can imagine how much effort it requires.

Permalink Reply by Aristo Compasso on June 7, 2015 at 6:27pm

Hello team,

Please forgive me if I sound stupid, but this is my attempt of thinking outside the box (because I'm under influence...)

Would it be possible to record macros in GH? I mean do stuff in rhino that would be automatically translated to components in Gh, if you get my meaning? Not trying to be Alice in Wonderland but that would be amazing... outside the box!

Permalink Reply by David Rutten on June 8, 2015 at 1:42am

It is not possible without a rewrite of Rhino and all rhino plugins. Unfortunately commands are black boxes and the only way soneone could figure out what a command did is by looking at the history records. But not all commands have history records, and there's no standard for record layout.

I've discussed this possibility with the Rhino team, but it's too involved to make happen any time soon.

Permalink Reply by Ángel Linares on June 11, 2015 at 5:17am

I don't know if that was suggested before but:

• Add value snapping to sliders published on GH Control Panel. Now the values added to the GH slider doesn't have any effect in GH Control Panel slider.
• Improve performance using Control Panel. The model reacts way slower when changing values in GH Control Panel instead of the GH sliders.

Permalink Reply by David Rutten on June 11, 2015 at 6:54am

Agreed, snapping (and limiting) will have to be part of the core slider class (and it will be).

I'm somewhat surprised that it's slower if values are changed in the RCP... but since it will be rewritten we'll just have to wait and see if it still suffers from the same problems this time around. If not, yay. If so, I'll have to find a way to fix it.

Permalink Reply by Ángel Linares on June 11, 2015 at 1:16pm

Good to know :)

Thanks!

Permalink Reply by Ángel Linares on June 11, 2015 at 1:15pm

Another one (I don't now if this was mentioned yet):

• Geometry visibility toggle per output: could help in multi-output components.

• ‹ Previous
• 1
• …
• 18
• 19
• 20
• 21
• 22
• Next ›
• Page