I came across a bug? related to the Filter Content component, Rules, Tags, and Grafting.
-Use the Content Information component to assign Tags to referenced model objects
-Assign multiple tags to a model object (example: furniture, chair, leather)
-Connect an “Equality Rule” to the Filter Content component with Key “Tags” and Value “furniture”
-This will return a null filter result despite furniture being present in the list of possible tag values of said model objects
-If you assign only one tag per model object, the Equality Filter will return the expected result
-Instead of the Equality Filter, utilizing the “Contains Text” Rule does in fact return the expected result.
If the intent is to use the Contains Text rule when there are multiple Values being checked against, that’s fine I suppose.
However, since the Tags/Values are single line items I would expect the Equality Rule to return the expected result as well since a True match value would be returned on at least one of the Value line items which is why I am reporting this as a bug.
Thank you all!
Match Text Filter affords a lot of options.
Good question on the equality, currently it’s testing for a strict match on one value.
We haven’t yet really looked into adding support for “Tags” in the Filtering component. To be fair, I’m a little surprised it works at all :). I’ll create a YT for this and begin exploring how to support this. Thanks for reporting it.
Oh interesting! It works quite well in what I have tested so far!
In programs like Revit, users often will bloat/exploit Family, Type/Instance parameters with their own text information/data tags/etc. to aid in later filtering operations or specific plugin interactions.
From a UI and UX perspective this can result in some truly horrendously long and convoluted looking parameter/properties dialogues where users are left unsure what is actually controlling their model and what is just a random “data tag”.
People add things like “Rot3d” or “Rotate” or “RotZ_Axis_PowerDoor_Plugin_Interop” and as a user you are going wth, which variable just rotates my door swing?
The beauty of tags is that they can cross pollinate across layer structures/object types/etc and exist in a sort of backend liminal space where they can be queried and searched for but without the need to bloat the front-end UI/UX
I like how many modern application UIs have a simple +, type field, or X button to be able to tag or remove tags in a single click.
If you all (McNeel) were to not implement that ease of use in a UI within R8 or R9 at this point I guess, it’s something I’ll likely try and develop. A simple right click->tag or shortcut like Ctrl+Shift+T for command _Tag to spawn a small UI window with simple add tag or click to delete tag functionality and of course a search box is always important.
Here’s a quick mockup of what I think that could look like (I’m not a UI designer or a programmer…)
Thanks for your time @AndyPayne and @Japhy !
@michaelvollrath So… I misspoke earlier. I hadn’t specifically tested for “Tags” and so I had forgotten that it was already a feature of the “Common Properties” of all objects. So, the way you had set everything up with the “Tags” key was correct.
I think the issue is that you’re using the “Equality Filter” and only checking for a single value (like Door) but then you’re checking objects some of which contain a list of values… So an object which contains list of tags equal to “Chair, Table, Door” will return false if you’re checking for “Door” because they don’t match exactly. If you want to check for equality for the object above, you’d need to specify the value like “Chair;Table;Door” and then this would return true… This is a bug though that we’ve now fixed (and will be available in the next release). After the next release, if you simply pass a list of those three values, then it should return true in the Equality Filter.
I think probably what you’re looking for in this instance is the Contains Filter. This will simply look to see if any object contains a Tag called “Door” and if it does it will return true. Does that make sense? Sorry if I misunderstood the problem earlier… but you should be able to filter via Tags just fine.
Thanks @AndyPayne that does make sense and I appreciate the break down! I’m really quite excited about the filter components. Particularly with complex AEC projects this is going to simplify A LOT of script logic.
I look forward to the next release, thank you!
I agree I think the filtering/grouping components are really powerful if you set things up properly.
Do you anticipate any functionality to add tags from within Rhino in the future? This isn’t currently available is it?
I don’t know for sure… but I imagine that we probably should add ways to add tags to different types :). The only data type that I know of that lets you add/edit tags is Materials.
Oh interesting I thought I had seen it somewhere before thanks for sharing!
Starting out this is good as Materials are an object type that probably has the least assignable “meta data” so tags could certainly help with some of that
Next release you will be able to group by tag as well.
Awesome @kike thank you! Looking forward to it!