Graph mapper as input to cluster?

Replies to This Discussion

Permalink Reply by Andrew Heumann on October 28, 2010 at 10:29am

Just a note - I realize that a solution to this problem would also solve another one, which is how to reuse the same graph mapper for different lists of data.

Permalink Reply by David Rutten on October 28, 2010 at 12:52pm

Hi Andrew,

not every Mapping can be represented as a simple f(x) function notation.

I don't fully understand all the ins and outs of this problem, can you post a file or screenshot of what it is you have and maybe a drawing of what it is you'd like to have?

--
David Rutten
david@mcneel.com
Seattle, WA

Permalink Reply by Andrew Heumann on October 28, 2010 at 6:51pm

Here's an image illustrating the problem with a simplified cluster. Let me know if it's still unclear. I see now that certain kinds of graphs couldn't be represented as f(x), but unfortunately I have no other specific ideas for a more elegant way to solve the problem. Any ideas?

Attachments:

• graph_mapper_as_input.png, 51 KB

Permalink Reply by David Rutten on October 28, 2010 at 8:41pm

Ok, so you want to provide access to a GraphMapper that is inside a Cluster, and I suppose opening up the cluster temporarily isn't a good enough option.

Where is this GraphMapper interface supposed to go? Should it be 'attached' to the cluster? Inside the cluster menu?

--
David Rutten
david@mcneel.com
Seattle, WA

Permalink Reply by Andrew Heumann on October 29, 2010 at 12:22am

I'm not sure what an elegant solution would be. I think making it attached to the cluster or some special feature of clusters is probably the wrong approach - but that's just a gut feeling. The only alternative that occurs to me is the possibility of letting "graph" itself be a data type, and allowing graph mappers to output them or accept them as input. Perhaps to avoid confusion these additional inputs/outputs could only appear if an option was checked when right-clicking? I know that hiding functionality this way is against the GH way... but I can think of a couple instances where it might be helpful to have an "advanced" mode with additional inputs.

I think in general it would be helpful to have more dynamic inputs for the real-time input widgets. I know many people have requested a slider that accepts variable inputs to define its range and type (integer, odd, even, etc), and I have often wished that the image sampler would accept a filepath as input to dynamically change the image being referenced. I can equally imagine variable color inputs for a gradient, dynamically setting number of bars on a bar graph, and so on.


I don't know what's clunkier: adding some kind of special functionality to clusters to allow for the external access to the various mapping widgets, or letting the mapping widgets themselves pass their configurations on to others of the same type. The advantage of the latter is that, as I mentioned above, it also solves the problem of how to process multiple sets of data through the same mapping (i.e. several graph mappers driven by the same master graph, or several gradients driven by the same set and pattern of colors.), without complicated list combining and separating.

Attachments:

• advanced_mode_inputs.jpg, 115 KB

Permalink Reply by David Rutten on October 29, 2010 at 6:53am

There's some pretty good ideas here. A lot of this stuff I'd like to solve through the use of 'leach' objects. Leaches are attachable parameters that get and set properties of the object they are linked to. These properties could be anything, for example Domain overrides, or preview colours, or even enabled states.

None of this has been written yet, but it's something I'd like to do before 1.0. Here's a general impression:

--
David Rutten
david@mcneel.com
Seattle, WA

Permalink Reply by Luis Fraguada on October 29, 2010 at 7:08am

Great stuff!

Permalink Reply by Andrew Heumann on October 29, 2010 at 8:17am

I like this. If a graph could pass its graph to a leach on another graph, it would solve my initial problem perfectly. It seems more in line with the way other things work in GH than my suggestion of the hidden "advanced" inputs.

While I have your ear, there's another feature I've been thinking about on my wishlist: the possibility of defining custom complex data types (similar to structs). The user could generate compose/decompose objects for this type, and then operate on lists of these complex objects like any other data type.

In terms of use, I am specifically thinking of pseudo-BIM applications: imagine being able to set up a type called "door" that contains geometry information as well as various numerical parameters - and designing a cluster that takes a list of "doors" as input and say, outputs a door schedule. Or a cluster that takes a "window" as input and, based on orientation and opening shape, calculates an optimized shade for specific times of year. If I were designing my own "doors" and "windows" as types I'd include geometry for the frames, the openings, mullions, as well as an overall solid to define the necessary opening in a wall, so I could write an "attach" cluster that would accept "walls" and a set of openings and do the appropriate booleaning and positioning....

No idea what would be entailed in implementing such a thing... just something that's been floating around in my brain for a while.

Permalink Reply by David Rutten on October 29, 2010 at 8:49am

Hi Andy,

when Grasshopper is confronted with a data type it does not know how to handle, it will wrap it up without attempting to convert or modify or fix it. For example, paste the following code in a default VB script component:

Dim images As New List(Of Bitmap)

For i As Int32 = 0 To 9
Dim img As New Bitmap(50, 50, Imaging.PixelFormat.Format32bppArgb)
Dim G As Graphics = Graphics.FromImage(img)

G.Clear(Color.Transparent)
G.FillEllipse(Brushes.DarkRed, i * 2, i * 2, 16, 16)

images.Add(img)
Next

A = images

You'll get a list of 10 bitmaps that can be processed by any component that uses Generic data. So that bit of the request is already possible.

The hard part is how this data interacts with the rest of Grasshopper. Data Types in GH are very complicated classes, because they have to play nice with the rest of the system. They must be able to format themselves correctly, serialize and deserialize to and from GHX files, they must be able to convert themselves to other types (if this makes sense) and instantiate themselves from other types (again, if this makes sense), they must sometimes be able to draw themselves in the Rhino viewports, and bake themselves into the Rhino document.

Somehow you'd have to define these behaviours without writing any code, that sounds very difficult to me indeed. It's also very tricky to add custom types without putting additional responsibility on component developers.

I can see why this would be useful, but I honestly don't see a solution, or even a glimmer of an approach on how to tackle this. Sorry to rain on your parade.

--
David Rutten
david@mcneel.com
Seattle, WA

Permalink Reply by Joseph Oster on January 11, 2017 at 4:52pm

Bump.  Any solution to this yet?  Painfully frustrating!!  Must duplicate and then maintain two copies of a large block of GH code to work around this (modifying foil sections at each end of a "wing" - root flare and tip taper).  Expecting a "user" to open a cluster just to access the Graph Mapper is unreasonable, especially if it's password protected.

Off hand, I see only three "Input" (interactive) controls where this feature would be very useful, since their output is based on one or more inputs:

1. Graph Mapper
2. Gradient
3. Color Wheel

Being able to reveal these controls outside of a cluster is not recursion, it's essential to basic code organization and usability.

Permalink Reply by Andrew Heumann on January 11, 2017 at 5:37pm

you can now do this with metahopper. it works with Graph Mappers (only in "bezier" mode for now) and gradients. Color wheel is not supported. The idea is to pass a reference to the graph mapper/gradient in question and then synchronize it with a matching object inside the cluster.

Outside:

Inside Cluster:

Attachments:

• GraphMapperAsInput.gh, 9 KB
• MetaHopper.gha, 371 KB

Permalink Reply by Joseph Oster on January 12, 2017 at 9:16am

Grasshopper needs its own built-in solution to this problem.  Such as being able to designate any "Input" (interactive) controls internal to a cluster as "External".  That would cause them to appear on the external face of the cluster, without showing any connecting wires, where they could be dragged around and re-arranged, similar to the way you can organize components in a group.