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

filter by type after the first block deconstruct.

Yep, some of my blocks don’t have sub-blocks indeed.
Good luck with your issues, and thanks for your suggestions !

1 Like

The approach shown is the one I would take (with the Filter by Type as suggested, in between the first Deconstruct and the second). Does that do what you need? Or is there an issue with that strategy?

Hello Keyan,

Here’s why this approach, although logical, doesn’t seem ideal to me.
Blocks, are a way to structure geometry in an effort to limit the amount of data that has to be moved around.
Nested Blocks push the concept even further.
By performing the “Deconstruct Block” command once on All the blocks, I have, in theory, a compact description of all my block structure :
-“Baseline” blocks (those which contain no block), along with the list of geometry they contain.
-“Higher order” blocks, along with the geometry and other blocks they contain.

This is optimal, because the actual geometry is listed only once, and I can infer from this everything I need except the Base Planes of the sub-blocks.

By performing “Deconstruct block” twice (or more depending on the nesting level), you are referencing multiple times the same geometry.
It is an easy way to get the Base Plane info for sub-blocks, but at the cost of losing the very benefit of a block structure.

Maybe by just adding “Sub-Block Base Plane” output to the “Deconstruct Block” component, this would solve the issue.

I see what you’re getting at. One nuance I would highlight is that - at least in my understanding - when you deconstruct the “higher order” blocks to a single level, the geometry of the sub blocks is not processed - only the block instance, which is still very lightweight**. Only when you deconstruct the second/last time is that geometry “processed”. So I don’t think it’s the double-deconstruct that’s costing much - it’s the fact that at the end of the chain you’re paying for extracting geometry that you don’t actually care about if all you want is the plane. So I am thinking a good upgrade would be to make the Geometry output of Deconstruct Block an optional one.

On that note, at the moment the Name and Plane outputs are only One Level no matter whether you have the Recursive setting or not. Perhaps we apply the One Level or Recursive option to the Names and Planes as well, so it would output the whole list.

Will add it to the list for future releases! No promises for when though…

**The geometry within the block is not processed or loaded into memory in GH until it’s deconstructed, so it would stay light and fast. However if you preview that geometry, of course the visualization pipeline is what slows down as it parses all the nested geo.

That would make a lot of sense.
Thanks Keyan !

By the way, the Human “ExplodeBlock” component has that option :


Sadly, the component itself can’t deal with nested blocks.
Elefront and Human both almost get it right, in their own way, but it never goes all the way, and combining them is just not possible…

It’s like the issue with Elefront’s “Modify Block” : it requires to bake the block, whereas Human’s “Define Block” just changes the definition which is much better when dealing with nested blocks or blocks which don’t have a “Bakename”.

Or the GH interface lockdown when baking blocks with Elefront…

I wish you guys would team up and made a proper set of block tools.

Blocks are really a minefield of coding :rofl:

Well, frankly, if you take the good ideas in Elefront and Human, you end up with something quite acceptable.

Elefront has a great way of exploding nested blocks.
Human has the option to explode only the block info.
Elefront can reference Blocks by name, including nested instances*
Human can modify a Block definition without having to bake it

Combine all that, and you’re good, except you can’t because the classes are not compatible.

*and blocks without instances !

as I’m testing my own implementation, hopefully it would be better…

image

It’s useful to be able to look up sub-blocks. Although from my perspective, it’s not a reasonable behavior to mix instance and definitions.

1 Like

Hello Keyu,

Good to see you have a go at it.

The parsing is rather easy, and this is the first thing I do in my definition :

In my case, as I want to do a custom “Block manager” that displays attributes, and a 3D view of any block defined in the model, HUMAN would not allow me to display info on blocks without instances.

Here’s the prototype of the tool I am working on :

I store the attributes of low-level blocks in the geometry defined in the block. That way, I can change the attributes and have them propagate in the blocks where they are nested.
For top-level blocks, attributes are stored in the block instances, which allows to have varying attributes per instance.

This works because it is consistent with our constructive logic : low-level parts are like clones at the fabrication level, whereas welded parts can belong to different phases, so we need the possibility to have a “per instance” value for cetain keys :

2 Likes

Do you store attributes in User Dicitonary in the geometry inside block, or in the dictionary of sub-block definition? So I suppose you need the geometry (those inside blocks) to stay as referenced ones in Grasshopper? Honestly I think neither of Human & Elefront can do that.

Yes ! I have a cluster in my definition which looks at the attributes of all the geometry in my low-level blocks. Whatever geometry has most keys is considered the “Reference geometry” and any value changes or extra keys will be given to that geometry.


If I used the attributes of the instances for low-level blocks, it would be a nightmare to change them in all nested instances !
This is a huge weakness in the Rhino Block system, and assigning attributes to the geometry within the blocks is the only solution I found.

For Top-Level blocks, it’s another story : first, it’s much easyer to manage since they are not nested (by definition), and it makes sense in our construction process because we can have the same parts used in different construction phases, so the “PHASE” attribute can have different values for different instances of those Top-Level blocks.

The geometry coming out of Elefront’s “Deconstruct Block” component retains it’s attributes, even if transformed, EXCEPT points ; as discussed here with you and Martin.
So this is not really an issue.

I’m struggling right now to re-structure the attributes that I need to change and re-define blocks with those new attributes, but that’s another story.

Yes. But you cannot change it and put it back. The issue of modifying existing blocks are what you’re struggling on and what I am referring to.

Wait. I think you can do it by Human.

Block definitions → Inner objects → Object Guid → Modify Object Attributes

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)