I have some old code that uses Hops. One of the Hops components often fails when I open the BIG GH file. I have been coping with this failure by reconnecting the Hops input but I want others to use the code without that hassle. Right-clicking the Hops component, as one would do to specify ‘Path’, I noticed a link to “Internalize Definition”, which appears to solve my problem?
Update Hops: Ensure you are using Hops version 0.15.0 or higher via the Rhino Package Manager.
Right-Click: Locate your Hops component pointing to an external .gh file.
Select Option: Choose Internalize Definition from the context menu.
Result: The external file reference is removed, and the sub-definition is serialized right into the component for easier sharing.
Internalizing Referenced Geometry for Hops
The Problem: Hops and rhino.compute run as headless tasks and cannot read live geometry directly from a local Rhino document file.
Add Parameter: Place a standard Grasshopper parameter container (like a Curve or Point parameter) before your Hops/Get Geometry inputs.
Reference & Internalize: Assign your Rhino geometry to that parameter, then right-click it and select Internalize Data.
Connect: Feed that internalized parameter into your Hops component inputs so the geometry travels with the data stream during computation.
I haven’t played with it much yet, particularly the problem noted with “Internalizing Referenced Geometry for Hops” (which doesn’t seem like it will be a problem for me as I pass geometry explicitly), but does anyone see problems with this?
P.S. Digging deeper, I realized that one of the Hops GH files uses geometry from Data Input so more digging is required! To internalize Hops, I might to pass that geometry explicitly?
Hi @Joseph_Oster . To give a little more context… we added the Internalize Definition feature to the Hops component because we found that sometimes people would forget to attach the referenced definition that the Hops component was trying to solve when they were sharing their definitions with colleagues. When you interalize a definition, it basically writes the entire Grasshopper definition that you’re referencing as a base64 string and saves it as part of the Hops component, which then gets serialized with the main definition. So, when you click “Internalize Definition”, it basically removes the reference to the external definition and everything gets saved into that one single file (does that make sense)?
Now, Internalizing Geometry works kind of similarly. As I’m sure you’re aware, internalizing geometry removes the reference to the geometry in the document and saves it as persistent data in the parameter. With Hops, you can use most of the parameters that are available in Grasshopper, but people sometimes get in trouble if they have a parameter that is referencing something in the Rhino document. Remember, when Hops sends a definition over to Rhino.Compute to get solved in a headless environment, there’s no Rhino document so that reference to the geometry will fail and cause problems. So, for Hops you have two options. You can either internalize the geometry on the parameter so that it removes the reference to the Rhino document and stores everything in the Grasshopper definition… OR, you can leave the parameter blank and pass the geometry in explicitly (which seems like your preference). Either way should be fine. The only time people get in trouble is if they leave the reference in the parameter and Hops will throw an error. Does this clear anything up?
Not really, though your explanation is fine. The reason I found internalizing useful was, in some cases, the Hops code was returning nothing until I reconnected one of its inputs. Internalizing avoided that problem. But my code is very complex, using Data Output / Input.
Ok. Well, if you have a definition that you could share, that might help me troubleshoot. Are you able replicate the issue of having to reconnect an input with a more simple definition?