I was just wondering, but is there a reason why referenced geometry will occasionally disappear and become null items? I have one file that I’m working with right now where I referenced seven points, and every single time I open the file again, two of them will have turned into null items. I’ve tried internalising them, but grasshopper just hangs when I do. I created all seven points in the same way in Rhino, so I’m not really sure what’s going on. It’s not really an issue because I can just re-reference the points when I open the file, but it’s mildly annoying. Has anyone experienced something similar?
Given the opportunity in general I would strongly recommend (a) NOT internalize anything (b) therefor always use a R file for the referenced geo.
Other than that from time to time I encounter situations like these … but not a “typical” case is kept for further investigation.
I haven’t seen it before. Could there be some process involved which modifies these points and replaces them with different points in the same location? Is there an error when the points fail to be imported?
I’d like to see the 3dm and gh files, especially if they fail on your machine when you open them in their current state.
Possible solutions to this problem would be to reference the points by name. Give each point an object name in Rhino:
That’s interesting. Forgive me if this is an ignorant question, but why shouldn’t one internalise anything? Most of the time I work from Rhino files anyway so it isn’t really an issue, but I’m curious as to why it’s actively bad. Thanks for replying!
That’s odd, because it’s happened to me more than once… in fact I would say it’s almost common. It happens with a variety of geometry, but off the top of my head I would say it happens most to points. You can see my internalised points vs points 0 and 1 here, which were ALSO internalised but still disappeared. 
I could email you the files if you like?
Well … as I said from time to time and if internalized data in parameters are around and under unpredictable (at least to me) conditions when loading a gh def … R crashes immediately whitout any log file: that’s good enough reason to me for never internalizing anything (most notably Breps).
That’s a BIG issue if you want to change things in collections interactively and on the fly: meaning that a modified collection is stored in a parameter (volatile data > parameter, that is) and then is loaded from that parameter BEFORE any slider change occurs (stuff done via code).
That said when this happens the only solution is to load the gh file with the solver disabled and remove any parameter with internalized data (that’s not a big issue - if we forget the above case - since I always work via some sort of C# meaning that all parameters are rather “consolidated” in one place).
I see, thank you for explaining that. Like I said, I generally work with referenced geometry anyway, but it’s good to know why it is preferable.
It isn’t in my opinion. If the inputs are unlikely to change then internalise all you want.
The one major drawback to internalising data (especially lots of data, especially complex shapes like breps or meshes) is that it bloats the gh file size. And that will slow down autosaving, which is something that happens a lot.
I concur, it still happens in Rhino 6. Thats why I also avoid internalizing anything unless it absolutely necessary.