Excited about the “Rhino” tab in Rhino V8’s version of GH1.
By the way, there SHOULD be a forum category just for this version of GH since V8 is shipping now…
Of course, as you know, I’ve been a huge proponent of native GH block management, and what I see looks kind of good.
I suppose that the geometry pipeline of old is made obsolete by the new “Query model objects” component plus the “Filter content” and “Contains” thing which make it possible to reference block instances… at last !!!
The problem here is that I can filter objects there seems to be no way to filter by object type !
Also, I fail to find a clean way to reference only block instances, moreover from a certain block definition.
For example, If I have a block definition named “Bracket 72”, I’d like to reference all it’s instances in the model.
AHA !
I Found how to filter by object type, but then it took me a while to guess that “Model Block Instance” which is the object type as labeled by the new components is NOT the text value to use, but rather just “Instance”.
I find it kind of silly that I can filter stuff that has this or that print width (Who needs that ???), but I can’t filter by block definition name !!!
Is there some kind of online reference for these new components, or is it just as usual ?
Oh trust me, you’ll get into workflows (particularly in automated documentation creation) where you’ll be glad you can filter against print widths and other “odd/nuanced” metadata haha.
You can also simply use the Contains method of search query on the Query Model Objects component to get the block instances, no need for a filter operation.
Also check out this new video with Andy Payne covering the new components. It’s long but worth the watch if you have time or can 2x speed it or whatever.
Thanks for chiming in.
You are right, ANY filtering can be useful , but as I manage large models with nested blocks, filtering the instances is really at the top of my concerns.
In your example, it seems that it works only because you have given a Rhino Name to your block instances that contains the word “Toilet”.
My blocks don’t have Rhino names, therefore it doesn’t work :
I think I understand the issue, the blocks I am querying were already added to the document and therefore they can be queried as Model Objects, if you have a loaded block definition but have not added instances into the Rhino model, you cannot query them in the method I showed.
I did make a cluster that uses text filtering you might give it a try?
Below you can see I’m specifically filtering for Blocks and then the Block name itself not the Rhino name.
I’m using it to return all Electrical Symbols (as an example)
No, you don’t understand what I mean…
My block definitions definitely have instances, they just don’t have Rhino names.
Of course it is possible to sneak-filter the block names (check my previous message), but at this point, I find it’s a glaring ommission on McNeel’s part that it isn’t straightforward, by that I mean cleanly and evidently integrated in the filtering process.
Is the goal simply to filter out only the Block Instances from all of the other geometry types in a model? If so, you can you use the Query Model Objects component. Right-click on this component and select “Show All Params”. Then, all of the objects will be sorted by type and output via their own output parameter. Or are you trying to do something else?
Thanks for the “Show all params” tip ; this component makes more sense as a replacement to the old “Geometry pipeline” that way.
Although your 3 hours video is great, I think someone at McNeel should really spend the time to document each of these new components…
As per my request, its is quite obvious from my previous posts :
I want to filter instances BY BLOCK NAME, not Rhino names.
So of course I can use standard text parsing and filtering to achieve this result, but it’s kind of lame considering the efforts you have put in the new filtering system.
Also, I noticed a troubling issue as I wanted to “BlockEdit” a block which was referenced with these new components :
@AndyPayne
Silence… I see two possibilities here ; either :
-I missed something and there IS a way to filter block instances by Block Names with the new uber-filter thingy.
…or…
-You guys spent countless hours catching up with block and property management and forgot THE most important filtering criteria for blocks and are scrambling to figure a way to cram it in there.
As these new Grasshopper data types continue to be developed a lot of these key features will be in the release candidate builds, getting the best fit on features required relies on your inputs, so please stay up to date.
Note that these are new workflows; if that is not palatable, please stay in the workflows and data streams you are used to as we work through making them better.
I fail to see how this is relevant.
The “contains” component isn’t even in your snippet.
Please read the thread before throwing out silly idioms.
The real issue here is the complete absence of documentation, customary with all things Grasshopper.
And since the GrasshopperDocs community documentation isn’t up to date, then it’s just the old guessin’, askin’, wishin’…
You guys have the chance to have David who singlehandedly saved Rhino from irrelevance with Grasshopper, and you can’t spare a few bucks for an intern to write documentation / Online help for GH components.
What a pity…
Hi @osuire This is the latest guide that I have put together which explains the basic concepts behind filtering and grouping content by attributes. It likely doesn’t cover every edge case nor does it cover filtering specifically for block names, but I hope it gives a broader understanding of how the tools work.
As for your specific problem… I have looked into this and discussed things with @kike and currently we have not exposed a way to filter Block Instances using the Instance Definition name. We are aware of this limitation and are working towards fixing this issue. I have created a YouTrack issue item to track the status of this issue. We appreciate your patience as we continue to improve these tools.
No sweat : “Patient” is my second name.
At least my laments were finally heard, but sadly, by people who actually never used blocks in a real workflow with GH, having to juggle between Human and Elefront, plus nasty C# components to get some BIM action rolling.
The hell with all the other properties if you don’t know what block definition you’re talking about…
I can see some trouble coming with nested blocks, as I don’t see any way to recursively explode them, but that will be for another thread…
Well that’s really a great concept.
But how on earth could you forget about sorting block instances by name ?
I mean, the biggie, the talk of the town, the revolution in V8 isn’t about the shrinkwrap gimmick, it’s the acknowledgement that blocks are an essential concept in a modern CAD, in the era of BIM, and that it’s about time to give true control over them through Grasshopper.
It really baffles me… It’s just like coming up with a new bike concept, but with a pedal on only one side…OOPS…
I’m putting Rhino 8 aside until this is sorted out, because there’s really no need for me to try and update all our block-related Gh tools with such a fundamental flaw.
