Recompute GH definition when Rhino file changes?

Hi !

To me, it would make sense that GH definitions were recomputed as soon as a new Rhino file is opened in a given Rhino session.
In particular, some definitions create layers when they are launched, but if the Rhino file is changed, this process is not repeated and the layers are not available for bakes.
Other issues appear due to not re-initializing the definition, and for the user, it’s quite confusing, specially since they only see the interface made from Human UI .

It would be annoying though if your script didn’t rely in any way on the Rhino file but does take a long time to recompute.

There already is a mechanism that invalidates specific components when changes in Rhino occur, and it sounds like that mechanism should either be used already, or extended. At the moment Grasshopper assumes that components only care about referenced Rhino objects (not layers, or documents, or settings, or …). So if a component has registered a specific ID with itself then it will be expired whenever a new Rhino document is loaded.

It sounds like the problem you’re seeing could be fixed without changes to GH core if the components that care about documents register some bogus ID via the RegisterRemoteIDs() method. Which components are these?

Well, the particular example of layer creation is related to the Human “Create/Modify Layers”.

@andheum would it make sense to you to register a nonsense Guid so that the layer create component runs again whenever a new Rhino document is loaded?

Yes, that makes sense as a solution. @osuire - not making any promises I’ll get to this any time soon… I don’t have much bandwidth for GH development these days

Never mind, initial test show it’s not working as expected. Still digging.

Hi Andrew,
Maybe you could add a “Recompute” component in Metahopper.
Then I could add a button in my interface so that the user can recompute the definition when the Rhino file is changed.
It would be better If this was automatic, but as it is, the poor fellows get confused.

Great, now I can’t repeat it not working. The following code seems to do the trick:

using System;
using System.Collections.Generic;
using System.Drawing;
using Grasshopper.Kernel;
using Rhino;

namespace LayerTestComponent
  public sealed class LayerAddTestComponent : GH_Component
    public LayerAddTestComponent()
      : base("Layer Add Test", "LayAdd", "Layer addition testing", "Test", "Test")
    { }

    public override Guid ComponentGuid => new Guid("{459E38B5-C9FA-4EE5-BE8E-398B3A405985}");
    protected override void RegisterInputParams(GH_InputParamManager pManager)
      pManager.AddTextParameter("Names", "N", "Layer names to ensure", GH_ParamAccess.list);
    protected override void RegisterOutputParams(GH_OutputParamManager pManager) { }

    protected override void SolveInstance(IGH_DataAccess access)
      List<string> names = new List<string>();
      if (!access.GetDataList(0, names)) return;

      RhinoDoc doc = RhinoDoc.ActiveDoc;
      if (doc == null) return;

      for (int i = 0; i < names.Count; i++)
        var layer = doc.Layers.FindName(names[i]);
        if (layer == null)
          doc.Layers.Add(names[i], Color.DeepPink);
    // This here is key. It's just a made-up Guid that will never match to anything,
    // but it makes this component expire when a new Rhino file is loaded.
    public override void RegisterRemoteIDs(GH_GuidTable table)
      table.Add(new Guid("{EA4D5DE0-B79A-4E5B-B16F-2F4BDC1395C2}"), this);
1 Like

Err… I barely know how to lace my shoes and scratch my nose while I walk, so I am sure I will do nothing of this, but Andrew…

Woa. But have you tried chewing gum and riding a bus at the same time? I’m still struggling with it. :slight_smile:

// Rolf

Don’t worry, that code was meant for @andheum in case he decides to try it.

1 Like