Background: I’m a beginner coder, whose trying to make a custom plugin for 3-d printers. I’m creating a 3-d printing plugin that specific to the design lab I’m a part of. I’ve created a custom class, called nodes, which holds all the info that the printer needs along the toolpath. For example tool speeds, print rate etc. I have the standard “construct node” and “deconstruct node” and a bunch of components that can adjust the speeds and orientations of the prints.
I have a bit of a strange occurrence that I can’t make sense of. It seems like when information stored in the nodes is adjusted down the chain, it references earlier. I’ve attached a few photos to show what I mean.
As you can see each time a component is turned on the output for earlier components in the chain are also updated. I’m unsure as to why this is happening but its not ideal. Anyone have any ideas what might be going on?
It looks like you may be storing data in static properties that are shared between instances of your nodes. Is it possible to share the code and/or the grasshopper definition?
You have to duplicate your data when it becomes an input, so the next component works with a copy instead of a reference. If I remember correctly GH does this in the constructors of the Goo types (GH_Goo< T>), for example: public Goo_Node(Node n) : base(n.Clone()){}. Also make sure your duplicate methods in the gh types are making duplicates.
The IP department at the lab would crucify me, even though I don’t think there’s anything novel in what we’re doing. I would say you’re correct that the data is being stored in static properties. I thought that might be possible. Is the common work around as Dani below says? You normally would duplicate your data at each component? Would this have a dramatic impact on memory?
Sounds right, thanks for replying. Question, is this going to have a dramatic impact on memory? We typically run lists a couple of million instances strong (our lab does 3-d print several meters high and wide, with large surface complexity).
This is how GH works, the reason why you can change the state of an object in one component and preserve its old state in the previous component.
In memory may have an impact, if GH runs slow when you change a wire or other things no running the solver, you have to disable the autosave via File>Properties>File. The impact should be in processing time, but that depends on your duplication algorithm. I have no idea what type of data you are a using, but in general GH is not good for million instances. If that happens, you could think in smarter ways of processing your script, like split your input data and combine the result, or make the definition more optimal or stuffs like that.
When you use static properties, their values are shared between all instances of the Grasshopper component on your canvas. So if you update one, all are updated and that is exactly what you see.
If you remove the static bit, they are not shared, and each instance will have its own property value.
If your lists are a couple of million entries long, and contain integer or number values, the memory impact is a few tens of megabytes (one integer: 4 bytes, one double 8 bytes. Multiply by a couple million: a few tens of megabytes). As your machine will probably have 16 or more gigabytes of RAM, you should be fine I expect.
That’s very interesting to know those unit amounts, thankyou very much. Most of the data is stored as float which I think is even smaller than double, correct? I’ll play around with the static bit, for the time being I’ve duplicated instances of the class. Everything is actually running much quicker, I’m assuming because the same instances of variables aren’t being accessed and changed through multiple components. And memory isn’t taking a hit. Thanks for your time guys, this has been a great learning experience.
