ELEFRONT : how to map back sub-block info to the main block?

Modifying geometry is not the purpose of my tool.
It is a kind of “Block Manager” which displays attributes and allows to modify them easily accross a bunch of blocks.
And even if I wanted to modify the geometry, I could always re-assign initial properties by keeping the same branching, as Martin suggested.

My real issue here is that Elefront forces me to bake blocks to modify their definition, which is kind of silly.
Modifying a definition and creating instances are two different things, and that’s why Human’s approach is better in that respect.

By “you cannot change it” I’m referring to changing the attributes (user dicitonary, maybe).

Oh I understand. I guess you are totally fine with Human as long as it supports nested blocks.

You can change the attributes of geometry in the block definition by re-defining the block of course !

Once the block is re-defined, the geometry in all of its instances will have the new attributes.

Yes I know. But you don’t want new block definitions.

The thing is that if you give your definition the name of an existing blocks, it will re-define it !

Human even has an option to allow or not overwriting of the definition :

you probably need to modify attributes of geometry inside block. (and that’s what I achieved below in this gif)

This is what I’ve been saying all along :slight_smile:

Your components look yummy !
No need to re-define the block … It could save me lots of headaches.

It’s very easy to replicate. Here’s a C# version, together with Human.

20201201 blk.3dm (27.7 KB) 20201201 blk.gh (10.2 KB)

Thank-you so much Keyu !

Recently, your “Multi-sort” component solved one of our long-standing tasks.
I need to spend some time with your example files to better understand what can be achieved with your “Assoc” class.

  1. Originally, Assoc is designed to interact with structured data like JSON, XML and CSV. You can operate on/read/write data from/into the aforementioned format.
  2. Later I found many of Pancake’s users use Assoc to organize data into rows. (One Assoc can contain multiple columns of data)

Like some kind of “Pack” / Unpack" or “Wrap” / “Unwrap” from Metahopper, but with extra tools to manipulate the packed data ?
I guess I’d need a concrete example to understand.

Yes. The major difference is the elements in Wrap/Unwrap are anonymous. Assoc can contain named values. So it’s easier to look up and manipulate.

Anyway it may not be useful to everyone as I put it into the plugin cuz I need it :rofl:

I’m interested to know in what context you use it then :slight_smile:

Keyu, may I ask you to add a “Geometry” and a “Base Plane” output to your component ?
Without the “Geometry” output, I can’t retrieve the original attributes of the objects…

Oddly enough, I am able to get the layer using Elefront’s “Get Rhino Attributes” component, but not with Human’s.

Once you have the GUIDs from the geometry in the block, if you would like to stick within the Elefront family of components, you can use Define Attributes and Modify Rhino Object Attributes component (obviously use whatever workflows you like).

One important consideration is that this only works for Embedded Blocks. For linked blocks, you cannot change the attributes of the geometry within the block because that geometry lives in a different Rhino file. Rhino will let you change certain aspects of the DocObject Attributes - like its color - for the referenced geometry within the active document, but you can’t change the User Values / Keys of a Linked Block from within the active document.

For our purposes, Linked Blocks are almost always what we work with, which is probably why features like this haven’t moved up in the list. It also means that if you have a mix of embedded blocks and linked blocks, it would be a challenge to keep track of which blocks you can actually modify, and which ones you can’t.

Regarding the Define Block component, in both cases, Human and Elefront are creating GUIDs for the geometry that will go into the block, Human (I believe) is just hiding that process. We can look at adding that option in the future, though, again for Define Linked Blocks, I believe they will need to be exposed so that they can be selected, as a prerequisite for the creation of the block. Worth looking into for sure.

1 Like

Well the big question is : “Why does Elefront obfuscate the GUIDs of the block geometry ?”
This is useful stuff !

Yep, I figured that out, and it works fine.

If I may place a little comment here : users like me are stuck between the inept block management available in Rhino, and a plugin like Elefront which is taylored to high-flying offices who use 100% generated geometry and reference files from servers all around the world.

Our workflow, (and I suspect that of most block users) is based on at least 50% “hand-made” blocks, and we wouldn’t touch linked blocks with a stick !

Please don’t see this remark as disparaging ; I admit that Elefront fixes a glaring hole in GH 1, but I really hope that there will be down-to earth and reliable GH-native block tools in GH 2.

1 Like

Although I cannot say there’s a connection between hand-made blocks & linked blocks. In my company we use linked hand-made blocks to reduce the size of the central file.

You can modify the definiton with GeometryBase. There’s no need to bake objects.

We use Worksessions to split out projects into phases, or to split the modeling workload between modelers.
This has proven to work quite well on this project where each file was over 1.3 GB ; therefore, I don’t see the need to fragment the data beyond this.
Me might end-up using linked blocks for library parts like screws and such which have “fixed” attributes though.
Managing the block attributes has become a tedious issue, and is often a source of errors.
This is why I am working on this “In-house blocks manager” tool which can give a synthetic view of the metadata, and rectify/modify it easily on multiple blocks at once.

We have, like ~100 small houses of ~15 different types, forming a big residential unit. Besides we have surroundings and terrain in other 3dm files. The central file links everything and is rather small (~2M) so that we can quickly adjust the masterplan and store multiple options without consuming much disk space.

Yes, in your case, Linked files make a lot of sense.
For the typology of our projects, it does not.

1 Like