algorithmic modeling for Rhino
What I'm after:
- user plugs in random geometry into a designated component input (looking at speckle here).
- i want to know, when getting the respective geometry in my component, from which component it originated (some sort of getSourceId())
I'm basically asking how do I replicate the GetDataList(0, ref myObj) functionality, but with the added feature of GetDataList(0, ref myObj, ref whereMyObjsCameFrom)
where myObj and whereMyObjsCameFrom are two equal sized lists, one containing the acutual geometry/objects and the other one the component uid (not the guid, but the specific one to that instance).
Right now i'm looking at iterating through all the source params
foreach (IGH_Param param in Component.Params.Input[1].Sources)
{...}
Casting the IGH_Param to an IGH_Component, looking through the IGH_Component.Params.Output[0,...].Recipients... ok, I might be getting somewhere.
Any help with the process is appreciated!
Tags:
Okays, making progress. :facepalm: In a c# component it's as simple as this:
Component.Message = "Hello \ncool didn't know about this";
foreach (IGH_Param param in Component.Params.Input[0].Sources)
{
Print(param.InstanceGuid + " / Gives us the following objects: ");
foreach(Object myObj in param.VolatileData.AllData(false))
{
Print(myObj.ToString());
}
}
Why is it always so painful to get stuff right? I'm constantly getting lost in IGH_ vs GH_ and such elegant solutions as foreach(Object myObj in param.VolatileData.AllData(false)) are always buried in long lost conversations :)
It's a bit too late to find out where stuff came from at SolveInstance. All input trees have already been merged into a single new tree so figuring out where something specific came from ---although not impossible--- is certainly difficult. You have to:
And you better hope that the input parameter doesn't have Flatten or Graft or Reverse enabled or it gets a lot more complicated.
As for "Why is it always so painful to get stuff right?"... that's simple. The GH1 SDK sucks donkey balls to channel Eric Cartman. The very few bits of it that are expected to be used by component developers is kinda sorta polished a wee bit, but everything underneath is just a mess.
Ahaha, David - you echo my sentiments fully. I'm keeping a little tear-stained diary of whenever of my love-hate relationship with the SDK. It's full of powerful sentiments expressed in not so nice language.
I've made it work - for now:
List<System.Object> geoms = new List<System.Object>();
List<string> guids = new List<string>();
foreach (IGH_Param param in Component.Params.Input[2].Sources)
{
foreach (Object myObj in param.VolatileData.AllData(false))
{
geoms.Add(myObj); // these are the object geometries
guids.Add(param.InstanceGuid.ToString()); // these are the guids of the parent componenets
}
}
since we're on the donkey ball issues, pasting code in this ning thing is worse than an alpaca pirouette. here's some readable code for the future reader:
Yeah we'll switch to discourse for all GH2 related stuff when that arrives, and slowly retire Ning. It seems we have ways of transferring all discussions automatically so we hopefully won't lose too much.
Discourse is about as friendly as Usenet and hasn't got a gallery even.
In good places you would get troll-voted if alternatives aren't proposed and argued for :)
I like discourse for what it's worth, and i think it's a huge improvement over ning... I'm sure a democratic feature voting process can be/will be enacted by mcneel.
it's a pity http://discourse.mcneel.com/c/grasshopper-developer gets as much action as aforementioned donkeys
Just a random question - problem is solved so far - but what's the difference between
foreach (IGH_Param param in Component.Params.Input[2].Sources)
{
param.InstanceGuid
and
param.Attributes.InstanceGuid
}
they seem to be giving out the same identifier; or maybe i'm missing something. this question can also die a slow inactivity death and we shall await the exulted GH 2.0 SDK!
I think they both read their values from the same field. I wrote that when I was in my 'it's best to have all properties immediately within reach' phase.
One important thing to keep in mind is that an object does not necessarily have attributes. It is possible to construct an object, poke it programmatically and perhaps even invoke the SolveInstance method without anyone ever placing a call to CreateAttributes().
Welcome to
Grasshopper
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
© 2024 Created by Scott Davidson. Powered by