Two problems arise regarding the way the Blocks are baked :
-The geometry inside the block all gets moved over to the current layer and I can’t see how to define it’s attributes ; only the attributes of the block instance itself are set by the “attributes” input.
-It doesn’t seem possible to create blocks containing blocks
1 Like
Hi Andrew,
Thanks, I had forgotten the attributes thing.
Regarding nested blocks, well… I hope you can implement it at some point.
It forces me to resort to another plugin which does the job, but in a hack-like fashion which poses all sorts of problems.
This seems to work:
I made blocks for Wall_Pt1, Wall_Pt2, … , Corridor. Then I flatten them before making them to another block. Then bake that block. Attribute is assigned at the MakeBlock node and the last Bake node. And the layers are structured to match nested block structure.
and double nested block with matching layer structure
Hi David,
Elefront is what I was hinting at.
This plugin often provoques strange behaviors, which is why I like to avoid it when I can.
Namely, block baking results in either a crazy multiplication of duplicates, or breaks GH’s interface.
Kind of left between a rock and a hard place with blocks in GH…
1 Like
Hi Osuire
I have noticed with Elefront bake, using a GH Button will freeze the GH while clicking on the button in the Bake node will be fine.
Sorry if I have miss read your original post. I thought you were chasing blocks containing blocks. My bad.
I found Elefront to be very useful otherwise, but yes, it sometimes does create “error blocks” when I check in BlockManager after baking ( not that I bake blocks often).
1 Like
Hi David,
Nested blocks is indeed what I need to do.
I’ll try baking using the component itself, and not a GH boolean toggle.
I’ve also noticed the “button freeze” issue with Human, this seems to be a GH problem.
The more annoying issue I have with Elefront is the freeze of the canvas : only zooming keeps working, but pan is dead and no more components can be added or edited.
Only solution is to close / re-open Rhino since it is no longer possible to kill only GH.
1 Like
Hi Osuire
Sometimes when the GH canvas freezes after Elefront bake or Human bake, like you have experienced (pan is dead, zoom still work), I found that if I click the bake button on the node again, it will work again. Maybe give that a try.
1 Like
Hi David,
Thanks ! I’ll try that.
The sad part is that these “under the GH hood” manipulations interfere with the idea of making nice and clean interfaces with Human UI…
I can’t ask my “non-GH” team mates to rummage through definitions and fiddle with components to get the work done.
I hope that another David takes notice 
1 Like
Encountering this issue now. Baking with Elefront freezes left and right clicking in GH Canvas. Middle mouse button still works, zoom works, and accessing the component menus and main menus still works. Using Elefront Bake again works sometimes. The only other solution I’ve found is to close and reopen Rhino and GH to stop the issue. Closing GH alone will not stop the problem.
Elefront as a plugin is as close to a functional Block workflow that GH has right now. It’s really frustrating when trying to integrate a typical workflow between AutoCAD, Rhino and Grashhopper, something that every contemporary architecture office is now doing in 2020.
Hopefully, David Rutten and team can decide on some “imperfect” path and define a workflow, as discussed in this thread. We will work with it however convoluted, fragmented and illogical it may seem, if it works consistently.
Deciding on and defining a solution to this problem would help immensely. Consider this an upvote to this problem on the development list for GH2.
1 Like
@osuire there is a couple of longer threads regarding this behaviour already. The latest one here: Elefront Bake All issue
There is a workaround by using the Pancake plugins “True-only button”, but it seems more like an underlying GH issue, that no-one at McNeel seems to want to acknowledge - likely because there are fundamental changes in how GH interacts with Rhino that would have to be done.
Actually, the toggle you clicked on before the freeze is still operational, at least in my experience. You can click on it again and the canvas will unfreeze. Obviously this will rebake geometry, so just Ctrl + Z on Rhino canvas.
Not ideal, but better than having to close Rhino and GH altogether.
Is everyone doing that or trying to do that? The problem is Rhino nor GH are architectural software.
No they are not. Most Contemporary Architectural firms are failing miserably at Revit, perhaps that’s what they meant by “Autocad”.
The reason is the button is awaiting the MouseUp event while the event is passed onto Rhino since Rhino gets focused. As long as the MouseUp is not received, all operations towards GH canvas will be redirected to the button. The issue can be fixed solely on the Grasshopper side as I don’t know in which circumstances removing MouseUp event globally may break existing definitions.
In my plugin I removed the MouseUp requirement.
1 Like
More blocks baking misery with Elefront :
Tried all the above tricks to unlock the interface, but no luck.
It appears clear that Elefront is focused on an a “Linked Blocks” workflow, and does not handle the “All blocks defined in the file” workflow.
Dang ! I didn’t remember.
This contrasts with the “Define block” component who requires that the data be branched.
What a mess… no wonder I get confused.
Still get frozen interface though. Not systematically, but it’s clear that all this is kind of a hack.
Apologies. I was being hyperbolic out of frustration. The word “every” was a bit over the top. Many firms do indeed have a part of the project team/or aspects of the project that work in AutoCAD for 2D drawings , Rhino/GH for 3D sketching, and then Revit/DP/ArchiCAD/MicroStation…etc…for issuing a contract model or coordination model.
Streamlining block integration between AutoCAD and Rhino/GH would be super helpful in this process.
1 Like