I’m working with a very long definition and finding the need to recover metadata from much earlier. It’s not my literal example, but imagine a file that first generate a six-sided die, complete with pips, and then much much later wanted to know which side of the die was closest to another object.
My mental model is to attach some kind of tag to each face of the die when it is created, then find the closest face later on and recover that metadata to know what side it is, regardless of whether it’s been rotated or whatnot in the interim.
Sorry if this is unclear and for the lack of an example… I’m hoping someone can help me with the best conceptual approach before I go too far down the road of doing it the wrong way (which is when I’d have an example to post).
Unclear (a bit) it is … but in general the orthodox way to deal with “similar” situations is to define a custom Class with suitable for the scope properties (of any type and/or any type of collection [ i.e. Lists, Arrays, Tuples, cats. dogs etc etc], populate accordingly a List (i.e. create a List of items of the type defined via the Class) and then query (LINQ) the List with any way imaginable:
For instance: given a List of Breps find Faces, Where they are planar (or not), Where their edges blah blah, Where their area is within some range, Where their orientation is within some other range, Where some property is this or that, then OrderBy this or that way, then GroupBy … blah, blah…
All the above are very easy with code (C# for me) … and rather impossible without (most notably if the queries are nested and/or are “custom” [as happens in real-life] for a given Project). Unless there’s some plug in around that does that (but i don’t work with plug-ins and thus I have no idea on that matter).
Thank you for deciphering my unclarity! That sounds exactly like what I need. C# and LINQ are fine, though I have not worked with them in the Grasshopper context. Sounds like a fun project.
BTW: All that if you have (or have plans) to do some real-life nested queries (within a BIM or PLM scope) searching things or evaluating options or working in a real-life environment where RDBMS maintened metadata is the 99.9999999% of the whole.
You have an easier and faster way if you have the order of your entities under control. Each entity has a position in the list/tree that contains it, you could have another list/tree with the metadata and each index/path+index accesses the entity-metadata pair. Just keep both collections in sync and use an index to access entities and metadata. If your metadata in each entity is a collection, you can probably convert to a single text line or a geometric group or in the worst case, have several lists of metadata instead of just one. The idea here is to have synchronised collections with one-to-one linking.
And now the bad news: if (spotted that you mentioned a die) you are in the real-life MCAD/PLM or AEC/BIM market sector … er … you date the wrong girls (R/GH). Find a friend fluent in CATIA or AECOSim and ask for a deep dive on metadata matters (the essence of PLM/BIM after all).
BTW: Get this abstract entry level thingy purely as an indication for queries (simple ones are used) via a custom Class:
Thanks for the links! I am happy to report that I am not i the AEC / BIM / OMG / WTF space… I am in the CNC ceramics space. The die was just the best analogy I could come up with for needing to retrieve the property of a face.
Now the 1M Q: given an object that undergoes numerous changes during the design stages … by what means can we use the initial (or some) Face/Face connectivity? (if this is possible and if not … up to what point?) This is a question for other type of CAD/MCAD apps (and Feature Driven/History modelling) : Rhino is not written having things like these in mind (but it can deal with entry level history matters).
Interesting. For my purposes, I care about the original (or some specific intermediate) state of the brep… my whole scenario revolves around “no matter where it is and what it looks like now, where did this face come from and what was its original shape”.
But I imagine there are some interesting opportunities for writing geometric transforms that also operate on metadata to keep it up to date.
Well … that’s the so called history based modelling (usually geared to feature driven modelling). CATIA works solely based on that, NX, AECOSim and CREO are hybrids and so on. Have in mind that the top dog CAD/MCAD apps and their metadata policy are written for designing very complex AEC things and/or some Boeing 777 (the first “product” ever done without paper work) meaning that most things that they do are not understandable by anyone not extensively involved on that kind of game. History also is heavily related with metadata (that’s the BIM/PLM part) because in real-life decisions for some change are also based on metadata and/or some other source (for instance input from some expert mold advisor add/or a CNC best routing thingy etc etc).
Things are way more complicated because any contemporary Project is in fact based (a) on a bottom-to-top (i.e. first design the piston, then the engine) approach and - obviously - (b) on some assemply/component schema (i.e. crank owns void collections of pistons, rings, rods, bearings etc). Smart objects in AEC and their interactions (say: what a door does to a wall or a bolt to a mounting plate) add to the pleasure.
All that without taking Specs into account (any Project without Specs is a nothing thing) and or Articles (any Project … blah, blah).
All that brings us to real-life ways (mostly visual via a kind of “hierarcy actions tree” - transparent in any CATIA view) in order to inspect and control history: Is difficult to explain here this but if you want a hint - just for the record - ask from a friend some sort of demo.
