Modify attributes of geometry inside a block

Hi Martin,

This is to be integrated in a tool that will manage huge models.

It will have to modify properties on thouthands of blocks super-fast and without crashing.

1 Like

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 :
Disable auto-Update

You might want to include such options in your plugin too.

Nice. There’s this documentation on the Morpheus Hotel if you haven’t seen it it’s quite fascinating…

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.

As shown above, you could certainly add bake names to existing geometry and blocks so that would create a clean start for following baking.

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.

1 Like

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 ? :slight_smile:

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.

1 Like

IT WORKS !!!
I just passed the IDs along, filtering them exactly like the geometry, and the update of attributes worked just fine !

Thank you so much Keyu !!!

I just don’t get why Elefront trips the ID info from their geometry class…

1 Like

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.

figure.1 deconstructing 15k blocks

image

2 Likes

Ha ha ! That’s kind of funny. This is the plugin that has caused my most beautiful crashes.

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.
1 Like

Thanks for the clarification, Keyan.

Is Elefront going to be updated anytime soon?

We are indeed working on it, but we’re also very busy making buildings at the moment!

We’re hoping to get out an update out in the next 3-4 months, though it feels like we’ve been saying that since January…

The upside is we’ve had to develop some new features and improvements, which we hope to fold into the next version.

2 Likes

Cool! I’ve been using your plugin on most of my projects. Also for my Labyrinth

One thing I think would be a nice addition to Elefront is a component to create a large number of layouts

Glad to hear it! That’s the whole point, after all - making cool stuff :slight_smile:

I’ll give some thought to the layouts. We haven’t historically focused much effort on that, but I can see how it’s relevant, given the components for annotations, etc.

1 Like

I never realized Elefront added this “GeometryCache” container… why not put it in the “Elefront” tab which is where the other extra containers are ?
Regarding GeometryPipeline, could you check out my thread on the subject ?

Hack or not, I suppose that this workflow suits the kind of “balls to the walls” projects you work on, which is not how “Grasshopper Joe’s” like me work. I’m closer to the grass.

I didn’t know that. But now, you got to admit it is kind of redundant and likely to create confusion.

1 Like

Sorry, I explained this poorly. What I mean is that GeometryCache is a native GH / Rhino component, not an Elefront invention. The Elefront BakeName is just an implementation of existing features.

From what I’ve seen, your projects are plenty challenging and you’re no amateur!

Anyone who doesn’t want it is free to simply not install it, or remove it if they don’t like it.

Duh… I never realized that. Thanks !
I might even try to use it if I manage to figure it out.

Yeah, but they really max me out. :slight_smile:

Ok, so do you mean I can un-install the Elefront Rhino plugin without affecting the Elefront GH components ?

That’s right, they’re completely independent. You could have either one without the other.