I’m trying to use the “Match text filter” to filter objects found inside a block to get only the polylines.
Try as I might…
Maybe I’m not using the right key, but hey… where can I find clear explanation about the exact meaning of all those keys, and what they expect as values ?
For example, I see the “Name” key in various key sets, but what it relates to exactly is unclear.
To find out if a curve is a polyline in Rhinocommon you use a method rather than test a property and afaik methods are not accessible to the match component.
However, you can identify the polylines using the Object component and a hack:
The Object component allows you to extract the geometry and if you feed that through a text box you get GH’s geometry label as text, which can be used in a simple comparison. 2412_PROG_240221_Filter polylines_hack.gh (13.2 KB)
geometry_type (number): The type(s) of geometry objects (points, curves, surfaces,
meshes, etc.) that can be selected. Object types can be
added together as bit-coded flags to filter several different kinds of geometry.
Value Description
0 All objects
1 Point
2 Point cloud
4 Curve
8 Surface or single-face brep
16 Polysurface or multiple-face
32 Mesh
256 Light
512 Annotation
4096 Instance or block reference
8192 Text dot object
16384 Grip object
32768 Detail
65536 Hatch
131072 Morph control
262144 SubD
134217728 Cage
268435456 Phantom
536870912 Clipping plane
1073741824 Extrusion
More a tool that is undergoing continuous development but is not yet complete.
It’s generally accepted these days that there is value in releasing software incrementally at short, regular intervals because some functionality is better than none, and waiting till it is all done takes away our opportunity to do those things that the software is already capable of. It would also remove our opportunity to give early feedback about the direction being taken and increase the likelihood that we eventually got a turkey.
Use the system and put in feature requests for what you see as missing and we’ll get a better Rhino.
Seriously, there’s some things like filtering by block instance name that should be obvious to them, after years of persistent complaints regarding the ability to manage blocks in GH…
Sorting curves by types is also obviously more important than sorting by “Display mode notes”.
Some jerk will probably pop out of nowhere to tell how important Display mode notes are to him, but I won’t even answer.
The link is to a thread that’s too long for me to want to read, so apologies that I may not have grasped what you are after. I have a slight suspicion that you might be wanting to sort by Instance names but without typing those names into the properties Name field. I do hope not.
If however you want to filter, or sort, or both, Instances by Block name (which seems a much more reasonable interpretation) then you can already do that. Like this:
I know, but piling up various filtering tools defeats the purpose of having a “new and improved” wonderful boolean-capable sorting tool !
My point is : the “Match text filter” would make sense if it started by implementing useful keys like block instance names and curve types instead of obscure, silly, nit-picky properties.
We are looking into adding more functionality into the filtering components… we are aware of some of the current limitations. However, you can already filter by Object Type (to some degree) simply using the Query Model Objects component (with no additional filters needed). Simply right-click on the Query Model Objects component and select “Show All Parameters” or alternatively hold down SHIFT and double click on the component and it will show all of the output parameters. The additional parameters that get added will break out all of the objects found in your rhino document by type. Admittedly, this doesn’t break curves down by sub-type (ie. polyline, arc, line, etc). But, it does break down the objects by their main data type. I just wanted to mention that here in case that wasn’t known to users.
I sieze this occasion to bring up an issue I found with these tools that query model objects (this one plus the strictly block-related ones).
On a simple 3MB file, it put my blazing workstation to a painful grind.
You know, the kind of “walking in deep mud” kind of experience I remember from the late 90’ies.
This makes me wonder if those tools have been tried out in real-world applications where models can be multiple gigabytes large, or just on funny multicolored boxes like in your building example.
If you could send us one (or more) of these files for testing, that would help us try to optimize these components. You can upload large files at http://rhino3d.com/upload?to=andy.payne@mcneel.com and please mention this thread so we can keep track.
Done. Not sure about your Email though.
In my example (<2MB), unplugging and re-plugging the filter component takes seconds.
With this definition, GH is kind of drowsy, borderline crashing, sometimes it disappears and need to be brought back with the “Grasshopper” command in Rhino.
@osuire I just tested your file on my machine and disconnecting/reconnecting the wire to the Filter component seems to be near instantaneous. I’ve turned on the profiler and it says that the filtering operation typically is less than 12 milliseconds (usually closer to 6 ms). Is this different than what you are seeing? If so, can you copy/paste your system info (type “SystemInfo” into the Rhino command line and save as a text file) so we can see if there might be something in your configuration that is causing this speed discrepancy?