FOUND !!! It was in a private message to David, dating back to April 2019
In fact, it was originally a Rhino Object, contrary to what I remembered :
Wtih a 10-min investigation from an architect 
:
If you want the reference to be exported, Grasshopper’s Data Input has issues with referenced geometry because Data Input and forthcoming GH_Structure.Read don’t call LoadGeometry of referenced geometry therefore the BRep geometry isn’t loaded and every operations thereafter will fail. I’d recommend to export the Guid instead (or convert to Guid and convert it back, such as:)
This can be fixed by David, in the Read code of GH_Structure or the Value getter of GH_GeometricGoo<>.
If you want the geometry data to be exported, Grasshopper cannot remove references natively, and referenced geometry cannot be exported unreferenced. You will need 3rd-party tools.
1 Like
OK, now I get it.
Since I need to transfer Data between different Rhino instances, and the guy using the INPUT will not necessarily have the referenced objects opened, even going through the “ID” component will fail.
I managed to make it work by exploding and re-joining my Brep.
What’s that component that you use ? The one with the red broken chain ?
Folks, don’t you agree that this is a case where there should be some kind of warning that it’s not a good idea to plug referenced objects in an “OUTPUT” ?
I mean, it seems obvious to me now, but at the time, I was just plugging some data and expected it to go through.
Maybe I was expecting the OUTPUT component to internalize the geometry before saving it to Ghdata or something…
From my plugin, I coded that because one time I ran into a similar issue…
I agree with you that there should be a better notice on the behavior of Data components. References are often full of issues, related to different scenarios. That’s also the reason why my plugin provides very delicate control over different references.
1 Like
Downloading… Thanks a lot for your work.
Yet, despite all the good I think of the numerous plugins out there, I feel that GH should provide robust native tools for Block and Dataflow management.
Our Plugin list is getting really long, and it’s getting unwieldy.
We started developping our own components, and might at some point come up with yet another plugin, but frankly, our needs are nothing special. They are just not properly adressed by Rhino and GH at present.
Had you downloaded it earlier, you probably will spend much less time in exporting geometry with different layers into multiple files.
haha just boasting. 
Data components aren’t in Grasshopper from the beginning. I can expect many issues regarding different methodology will raise as more and more people use them for large projects, or team coop.
Just reviewed the features of your Plugin.
Seems to be quite useful for our prospective workflow.
At least, my fumbling with OUTPUT and INPUT had this positive outcome : finding about pancake ! Yummy !
I also hope it can help others not to fall in the “Referenced data” trap.
Maybe I should buy some crepe today 
