This subject is driving me half crazy.
As I was already half-crazy before, this is getting really bad…
I need to modify the attributes of geometry inside blocks, and I know it can be done.
There seems to be no valid path to do this with Elefront, except by re-defining the block with “Define Blocks” which I don’t want to do for all sorts of reasons.
I think this can be done in two steps. To avoid having a mess with block definitions, I gave the block a bake name. Not sure how this works with multiple blocks and the format of the bake name
Then same as yesterday. The block needs to be defined and baked a second time but because of the bake name that doesn’t really matter I guess?
Had to try a few more times to get the color right.
In the exact same order ?
Then all it would take is either :
-An “ID” Output on the Elefront “ExplodeBlock”
-A “Geometry” and “Base Plane” output on your component
Although modifying something which aren’t expected to change by most plugins during a solution may cause issues, you’d better be careful with testing the ID approach and save GH file frequently.
I’m not too worried about that because the “Reference Block By Name” Elefront component which is at the root of my definition will not update automatically :
You might want to include such options in your plugin too.
I’m not affiliated with Front but I’m using their plugin to work on data sets with a few hundred parts and thousands of holes drilled in various angles. It’s definitely complicated but it solves my problems especially with versions and repetitive baking…
Yes, I read this paper, and I think they did a fantastic job.
The problem is that Elefront seems be focused on that concept of generating EVERYTHING.
That may be the case in specialized applications like yours, or for high-end façades, but we are very far from generating all our parts with GH, thus the “BakeName” concept does not work for us.
I’m in search of flexibility.
Up to now, we had a very rigid approach to layers and block naming which was used downstream for fabrication data.
As soon as the naming convention changed, or something wasn’t right with the Layer names, the whole card castle fell apart.
My tool simply displays the properties it finds and allows (hopefully when I figure it out) to apply new properties to a subset of the blocks (those which the user has filtered and are displayed in the table).
It is then easy to add new buttons or properties and adapt models to new situations.
Rhino’s block management tools are particularily inept, and sadly, neither Elefront or Human allow to do this elegantly.
It looks like hapiness is just a component output away ; Keyu’s plugin seems promising.
This would only work for blocks which have top-level instances…
I have truckloads of blocks which only exist as nested instances, and THESE are the ones I want to edit the geometry properties for.
Thanks for sharing. Can’t you edit the sub-block and apply properties outside the nested block? not the instance, the geometry contained in the sub-block.
i rarely bake without bakename.
My dream plugin/interface would be the ability to move Blocks in a tree like fashion. Top Level (A) has nested B & C, which have various nodes. The ability to propagate to the C nodes then move up a level, or even out of the block would be awesome. Now its propagate, copy to new file, explode, remove from original, add to other blocks as needed.
I too am getting heavy into nested blocks, which then are pumped into Revit Assemblies via RiR for quick documentation, really fun stuff.
Well that’s the big question !
If you can find an easy way to do it, don’t forget to tell me !
Do you guys realize that there are still a few folks out there who model their geometry WITHOUT Grasshopper ?
We have a 100% block workflow, but 50% of them are not “Generated”, they are modeled by hand, and I can assure you that I’ll never be able to force all the draftsmen to add a “BakeName” property to every block they create.
Moreover, I think that “BakeName”, although smart, is not much more than a hack.
Elefront had to create a Rhino plugin which mimics the “User attributes” panel already does, just to hide the strings and duct tape.
With ID you are operating on RAW rhino objects, a.k.a., minefield. Elefront’s author probably doesn’t want GH to crash randomly (although I know Elefront will crash GH with large blocks)
For instance, editing a block actually changes all GUIDs inside that block. So the captured GUID will be useless if you altered it during the midway and cause weird errors in downstream components.
my plugin will be, sort of, like Elefront, but with better handling.
I don’t mean to reboot a whole conversation, but I came across this and against my better judgement, couldn’t help myself:
BakeName is an implementation of the GeometryCache, which is an existing part of Grasshopper and Rhino. It’s available through the GeometryCache and GeometryPipeline components, and can be used to implement similar workflows. If that’s what you mean by ‘hack’, I suppose you could put it that way.
At the time the Rhino plugin was developed, the User Attributes panel did not exist in Rhino. It was created out of necessity, not covering strings and duct tape. If there was something special going on, the native User Attribute panel would fail to show the same attributes. In fact, when something is baked, the attributes go through as native Rhino attributes. There is nothing 'Elefront’y about them once they’re in the document. This is why you can create attributes directly in Rhino and they will show up in both the User Attributes panel and the Elefront panel: they are both simply reading the Rhino attributes from the objects.
