Now for Baking CustomComponents

Grasshopper
1

Hi Grasshoppers,

Imagine a conceptual leap with Grasshopper (pun intended) and related plug ins.

I’ve started to toy with grasshopper, and based on quite some experience designing industrial strength software systems using Model Driven Design (MDL, MDD or Eric Evan’s twist on model driven domains, called DDD) I almost immediately started to feel that something essential was missing in Grasshopper - the power to simply select a configured Group of GH components and press um… let’s call it “Bake” or more precise, “Bake CustomComponent”.

You already got the idea.

All that has to be done to implement such a system is to save the “wiring diagram” of the components of the selected Group (let’s call this the “Orchestration” of components) and dump its definitions (connections) into a text file (not proprietary format for this). The name of the “baked” Group would serve as the name of the new CustomComponent (or a new name input by user in a dialog on Bake)

And from this “Baked” definition Grasshopper could then reconstruct the dumped diagram definition (but not showing the diagram details!) displaying only a GH CustomComponent (created on the fly) with the same name that the Group had when the original GH diagram first was “baked”.

The CustomComponent would also be automagically adorned with inPorts and outPorts representing the connections which the Group had extending outside itself when Baked.

The InPorts and OutPorts would be given default names, for example like this (priority wise):

  1. The user defined component name, if any, of the nearest connected component outside the group, and the GH compatible Type name.
  2. The GH Type name of the connected GH component (Example: Point)

If only a value was attached of defined, the inPorts could be named according to the user-named Slider (see §1 above, if any) including the Type, or only the Type (R,I,E,O) if only a value was set or attached.

Any internalized values and formulas/scripts would be automagically injected/initialized into the dynamically created CustomComponent by GH on recreating it from the dumped definition.

The definition file should have a syntax supported by BNF, preferably an existing imperative or declarative language, so as to allow for EXISTING alternate ways & tools for generating (i.e. code generation) such diagram definitions / Orchestrations, which then be loaded into GH/Rhino an executed there.

The definition files to be saved as plain text, optionally EXTERNAL to the 3dm file, as to allow for Version Control (Git, Mercurial etc) and DIFF tools and…

You get the idea. The definitions to be subject to the common tools that are already in use all over by software developers.

Two way/roundtrip engineering would then also be simple using the well known principles from the world of UML & Class Diagram tools (like Enterprise Architect, Rational (IBM) and others: https://en.wikipedia.org/wiki/List_of_Unified_Modeling_Language_tools)

In this way Rhino/GH would potentially become one of the most powerful execution platforms for FBP-like programming, where a Grasshopper part-diagram, being built and tested and “Baked” could be added to a personal or shared library of powerful CustomComponents/concepts to be (re)used in other diagrams. Such a CustomComponent would actually represnet only one level of multiple, well, indefinitely nested CustomComponents / levels of components that at the lowest levels in most cases would be plain vanilla GH components.

In any case, it is in FBP[1]-like solutions of great importance to separate the “Orchestration” from the processing units themselves (GH Components) since it simplifies parallel computing and more, and it is the Orchestration of components that represents the uniqueness of a User’s Design, an therefore the part that he would want to save and administrate separately with VCS and DIFF tools in a non-proprietary format.

// Rolf

[1] http://www.jpaulmorrison.com/fbp/

2

Not sure all of what you want, but have you looked at Clusters in Grasshopper…?

–Mitch

3

Hm, no, but that sounds like a similar idea.

Didn’t find any (meaningful) help on Cluster’s though, only “Cluster Input” (and output) but nothing more on how to deal with clusters.

Edit: OK, I found the “Cluster” command in the menu, and I think I’ll manage to evaluate cluster with that.

Edit 2: Yup, Cluster is the same concept as I was asking for. Check.

TEXT FORMAT - PLEASE
But the file format (.ghcluster) is proprietary for no good reason. Clusters, or the name I would have preferred; ‘CustomComponent’, is the part that is not the IM of McNeel, and which need to be exposed to Version Control and DIFF tools etc.

But the text format can be fixed “over night”, right @bobmcneel?

(Apart from basic VersionControl, you will for example in research applications need to be able to compare the setups between runs to ensure that you’re actually performing the same processing ( = same wireing of components, and scripts, if any), aso).

// Rolf

4

I have no idea. I’m not a developer.

5

IIRC, clusters can be password-locked, the idea is you can package them as proprietary functions and distribute/sell them without wanting to reveal what’s inside… Perhaps this is also a reason why it’s not simple text.

–Mitch

6

Yes, but making that the only option is, well, it reduces the usefulness of the whole concept very very much.

Apart from VCL, DIFF etc, the Cluster files should be able to generated with other modeling tools (and thus, code generators) so Rhino could be integrated in the tool chains or “eco systems” of any other development environments.

Once that is achieved, and if there’s need for encrypting and/or scrambling the code, there are numerous tools out there for just that, no problem. With the current solution there’s no option for anything of the above mentioned. It’s just locked in, and that’s, well, it’s not very good given the potential if encryption & protection had been optional instead.

// Rolf

7

It’s not proprietary, it’s just a file written by GH_IO.dll. You are free to use this dll to parse any files, and I’m even happy to send the source for GH_IO.dll on request. You can use this library to convert the binary data into Xml (and xml back into binary data), which is readable by more conventional tools.

The reason for using this particular file writing library is because everything already works with it. There’s less chance of new bugs being introduced by switching to some other file writing mechanism. On top of that I can’t think of a single good reason to switch, because what would the benefits be?

Like I said, you can use GH_IO.dll to create an xml dual of the *.ghcluster file, but that’s as close to text as you’re going to get.

8

Password protection for clusters is not very good. The data needs to be ‘decrypted’ and executed by Grasshopper without a password, so the data itself cannot be encrypted using some sort of user password. It is fairly easy to circumvent the protection mechanisms and harvest the cluster document at runtime, just because .NET is such an open platform.

The main two reasons I’m not using text to store all this data is because the data is not text (ie. potentially lossy conversions to and from strings are required when storing numbers as text), and it really bloats the file size.

9

This in general will be difficult, because Grasshopper does not impose a strong ruleset on how components/parameters/data (de)serialize themselves. Each object in a document is given a little root dictionary in which it stores its own data, and ultimately all those dictionaries are serialized to a byte-stream which gets compressed and then written to disk. There are no naming conventions, or mappings from entries to properties that must be obeyed.

It is true that most components do not do anything out of the ordinary and are therefore very predictable, but the last thing you want to do is duplicate the (de)serialization logic of all objects you may want to compose through code. A far better approach in my opinion would be to generate/inspect clusters using the Grasshopper runtime. It’s type-safe, doesn’t involve IO, quite performant if you don’t run solutions, and it allows you to actually run solutions if you want to check outcomes.

Version control is something we hear a lot about from our more advanced users, so yes a lot will be happening on this front for GH2, but we will in all likelihood stick to binary files that can be turned into type-safe, hierarchical dictionaries using a standalone .NET assembly.

1 Like
10

Why can¨’t GUIDs identify the root nodes? And from the perspective of a potentially wider user base of the entire GH concept (it’s actually a FBP execution platform already) it would make GH useful from any other development environments as well.

But now there is this show stopper - the file format. :frowning:

.Net again is a completely different perspective, it’s got nothing to do with making the GH/Rhino package useful “to the rest of the world”, it would only be a constraint to most people. Even most developers don’t use .net.

// Rolf

11

[quote=“DavidRutten, post:7, topic:38519”]
GH_IO.dll … You can use this library to convert the binary data into Xml (and xml back into binary data) … The reason for using this particular file writing library is because everything already works with it.[/quote]
Hide it. It’s not mutually exclusive to use whatever file format already being safe while giving users the option to work with other formats. Just hide the conversions (who needs to even know about whats happening under the hood?).

A whole bunch of benefits (use cases) was already mentioned, for example making GH/Rhino into a execution platform, a tool in the tool chain for developers out there useful for every thinkable form of data crunching (more on that below)

Quoting myself, "Apart from VCL, DIFF etc, the Cluster files should be able to generated with other modeling tools (and thus, code generators) so Rhino could be integrated in the tool chains or “eco systems” of any other development environments. "

That means, in effect, unlimited potential.

Regarding GH/Rhino as a FBP execution platform, I actually assumed that the GH components are thread safe and can be run in parallel. This is why it’s so important to totally separate the wiring (Orchestration) from the components themself with inports and outports not dealing with strongly typed data to be processed, and using Information Packets (containers) instead and so end up with an execution platform which is “inherently concurrent”. Anything could be processed in parallel just by using two or more components in parallel (whenever that makes sense).

Anyway, the GH/Rhino concept can be made into a very very powerful generic tool for (any) developer out there.

Just to give an example, one of the things the GH/Rhino platform would be suitable for is heavy processing of DNA sequences, in parallel (given the assumption about concurrency mentioned above). And molecule matching, if using Daniel Piker’s “abstract materials” approach, and so on.

Not to mention the potential use of such an execution platform in Supply Chain management (which I have quite some experience from). Aso.

But then there’s that show stopper with the file format, and… ah, never mind.

// Rolf

12

If you want to see how a ghcluster file is structure, rename it to *.gh, drag it into Grasshopper and drop it on the Examine are behind the curl:

examine.png526×704 88.6 KB

It would be nice if the file viewer was able to load ghcluster directly, but the UI only allows for gh and ghx at the moment.

13

How do I make the canvas Curl?

// Rolf

14

By dragging a GH file over it.

15

Hm, I tried that (of course) but nothing happened.

Using Rh5/Win 10

Edit: OK, it takes WIP to examine. Doing so now.

// Rolf

16

Hi again @DavidRutten,

OK, it seems that you already have everything in place, since I could dump a Component (sorry, Cluster) and open it (“Examine”) and then save it as ghx. That means I can also open/import it as .ghx and off we go.

Now, I noticed that you seem to have saved two version of the info in the .ghx file, by including a byte array version. That’s a good idea, but, does that mean that if I generate a ghx-file with some other code generation tool, then Rhino would not be able to read that data if it doesn’t contain the byte array as well? (my guess is that, given one of your replies above, that Rhino would only care about the byte array version of the data, is that correct?)

// Rolf

17

Loving that you got version control in mind…for individual research/production tasks, you can more or less be confortable without version control, but in big projetcs with complex definitions and lot of people working on them, it’s a total nightmare sometimes.

Cheers.