How to auto-bake elefront elements?

Hi,

I’m trying to follow the example of Ramon van der Heijden on how to split a massive project into more bite-size bits of grasshopper and Rhino models into “a distributed data model”.
But is there a way to automatically bake the result of a grasshopper script into a rhino model so that changes propagate throughout the data tree without having to open each grasshopper file? It seems silly to open each grasshopper file, let it recompute its result with the new changes, bake that result and then open the next step to repeat the whole process?

I believe the idea is that multiple teams of people are working in those files. That said, i think i saw a thread recently where they described a similar process, granted i think it was hypothetical.

I’ve observed the same issue using Data Output/Input, though I’m waiting to bake until the last step in the process:

Quirk #1: If I change a parameter in Step 1 and then switch directly to Step 3, the results are a mix of Step 1 and Step 2 params, which is obviously wrong. So making a change in Step 1 requires a visit to the GH file for Step 2, which reads the data from Step 1 and outputs for Step 3, before moving to Step 3. This is a minor inconvenience given the benefits but ultimately would be nice to avoid.

I have all three files open in a single instance of Rhino/GH but the only one being executed is the one I choose to view. It would be AMAZING if all three were active at the same time! I could use Data Output in Step 3 to modify parameters used by Step 1, which in turn would update its output for Step 2, which in turn would update its output for Step 3. At one point I simulated this by opening multiple copies of Rhino/GH, each running one of the three steps and it worked! It was cumbersome and far too slow for realtime interactive changes though.

It is a tantalizing prospect to imagine a day when Rhino/GH could handle models that are compartmentalized into logical pieces and communicate with each other, as traditional programming languages have done since the very earliest days.

1 Like

Incidentally, I am considering approaching McNeel on the idea of using RhinoInside to launch Rhino inside Rhino… This would hypothetically allow multiple instances of Grasshopper in the same session and support the kind of workflow you are talking about here – however, I have no idea whether this causes unintended consequences or is even possible. But it would be great to give it a try.

Marc

Hi @marcsyp

Myself and Mr @will were working on this recently.

We found that (if you are running Rhino7 WIP) you can adapt the example code from here for RhinoInside:

and borrow some ideas from the team who did RESTHOPPER:

Then you can run a GH file from inside a different GH file using data component nicknames to populate some inputs, trigger an update and then grab some outputs.

Find two gh files attached to demonstrate. Apologies for hacky and probably non-optimised code. You need Rhino WIP for them to work.

We also didn’t find out yet if this causes unintended consequences but we didn’t find any in the files we’ve been playing with. In summary it seems possible.

Hope this is useful/interesting. We were debating wrapping some of this into little plugin component with some proper data checking etc. but didn’t get around to that yet… to be continued.

externalScript.gh (4.6 KB) internalScript.gh (2.5 KB)

Cool!

Funny thing – I was on the original RESThopper hack team… but I did most of the front end code in Ionic, haven’t really dived in to the back end code at all. :slight_smile: Funny to see it resurface here in this context. Will take a look at your code when we’ve got a minute to test this out!

Cheers,
Marc

1 Like

Wow, thanks guys for this overwhelming response! I’ll sift through this and see if i can make something work, but it seems some of you are already on a good track to make this functionality work!