Grasshopper

algorithmic modeling for Rhino

(Edit. David sez: Please append your (well explained) ideas/suggestions/wishes. I don't care much for what you want, I care why you want it.)

Perhaps this topic has been covered recently, but I don't see any active threads.  We're looking for a plugin project and I'd like to get some feedback from the power users before choosing something.

So...

What is missing from grasshopper?  

What would you like to connect to that you can't already connect to?

What kind of bottlenecks do you run into?

What secret wish do you have for Grasshopper that doesn't even seem possible?

What project have you been meaning to undertake but haven't had/won't have the time?

Just trying to brainstorm a few ideas here.  There are so many great and useful plugins out there, it's hard to discover the gaps anymore.   

Looking forward to your thoughts!

Cheers,

Marc

Views: 26628

Replies to This Discussion

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?

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.

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.

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

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?

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.

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!

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.

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.

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.

Good to know :)

Thanks!

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

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

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