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

Grasshopper
#1

Using the Elefront “Deconstruct Block” component, I get multiple trees giving me valuable info on the block instances contained in my model.
Let’s call “level 1” blocks those who contain only geometry, and “level 2” blocks those who contain “Level” 1 " blocks.
Voluntarily, our block structures are never more complex than this (and it’s already tough to manage).

I hit a problem when I want to remap info from “Level 1” blocks to the “Level 2” bloc that contain s them.
For example, I’d like to have a list of the Base points of all the “Level 1” blocks contained in a certain “Level 2” block.
I know I could get this by using “Deconstruct Block” a second time on the content of my “Level 2 blocks”, but I plan to feed truckloads of blocks in my definition, and this operation is quite intense.
So since the info is already there, I’d like to re-use it… but how ?

Matching sub-block info to main block
Matching sub-block info to main block2269×1116 256 KB

Matching sub-block info to main block.gh (21.5 KB)

#2

So if you have block A which contains B,C,D blocks you want branches of the A origin point for B,C,D?

If i understand correctly you would trim tree then use a longest list to match, then get your tree back in line.

#3

Nope.
In fact, the problem is upstream of the “Deconstruct Block” component :
Out of the “Reference Block by Name” component, one gets either “Referenced blocks” which are instances in the model, or “Blocks” which are in fact nested in some of those instances.
The problem is that there is no way to associate those nested blocks to their containing block instance.

Nested blocks instances Belong to which block
Nested blocks instances Belong to which block1698×942 272 KB

There seems to be a huge loss of information here…

#4

You would always want to access those nested blocks through the top level though right?

You could filter after the Reference by Name component on the All list, by Rhino Attribute or UserText.

image

#5

Hi Rickson,

By “Rhino Attribute”, do you mean the ID ?
Sub-blocks don’t have Rhino IDs…

Or do you mean I should purposefully add attributes to sub-blocks just to be able to sort them up in Grasshopper ? That sounds like a lot of hassle.

I guess I’ll just use the two steps approach and see if performs faster than the workaround I came up with :

Two steps
Two steps1618×1043 248 KB

#6

Having a rough morning, maybe in a few hrs.

Lost work, missing files (server/one drive issues), someone ordered the wrong size material for stuff that needs to be on the truck this afternoon. Seems to be one of those days.

1 Like
#7

filter by type after the first block deconstruct.

#8

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

#9

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?

#10

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.

#11

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.

#12

That would make a lot of sense.
Thanks Keyan !

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

ExplodeBlock
ExplodeBlock1302×575 84 KB

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.

#13

Blocks are really a minefield of coding :rofl:

#14

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 !

#16

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.

#17

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 :

Parsin with-without instances
Parsin with-without instances2308×899 186 KB

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 :

Model-O-matic WIP
Model-O-matic WIP2840×1394 917 KB

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 :

Attributes storage
Attributes storage2807×1394 683 KB

2 Likes
#18

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.

#19

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.

Geometry with most Key-Values
Geometry with most Key-Values2467×787 194 KB

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.

#20

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.

#21

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