I can add block in grasshopper using the plug-in named “elefront” and ID component. But I wonder if I can edit the Block in grasshopper or in ghpy.
Grasshopper, as you probably were sensing when installing Elefront, has no “Rhino Block” support. There are groups, but they are meant for a different usage in Grasshopper. RhinoCommon and rhinoscriptsyntax (http://developer.rhino3d.com/api/RhinoScriptSyntax/win/#block) have methods to change blocks. But if your goal is editing, why not create the right block definition in the first place? Instantiation, on the other hand, is easier with InsertBlock (http://developer.rhino3d.com/api/RhinoScriptSyntax/win/#block-InsertBlock). If you attempt this from GhPython, rather than Rhino (_EditPythonScriptEditor), you will have to let GhPython know that you mean to target the Rhino document. See "ghdoc" information for more.
Please let me know if you need more hints,
Giulio
–
Giulio Piacentino
for Robert McNeel & Associates
giulio@mcneel.com
Hi Giulio,
Elefront and Human allow to reference block instances in Grasshopper.
They make it possible to get lots of data from blocks :
That data can be used to do almost anything…except update the block definition and/or block instances.
Namely :
-Modify the geometry contained in the blocks
-Modify the properties of geometry contained in the blocks
-Modify the properties of the blocks instances themselves
-Add User text to the block definition or the geometry within
This is a huge bummer for people working with blocks and looking for ways to automate actions on blocks.
@osuire Technically there isn’t any reason why plug-ins would not be able to edit the InstanceDefinition table. They can. Probably though, this type of operation is not well-suited for a visual programming language. Again, you can do that in scripting… targeting the Rhino document.
You can ask @DavidRutten for plans on block inclusion in Grasshopper 2.
It is a problem because the actual block definition resides inside the Rhino 3dm file and as such cannot easily be extracted and used as a thing an-sich in Grasshopper. It’s all very complicated and I haven’t given it a lot of thought. If the only purpose of blocks in GH is to preview and bake them as instances, then addressing them by Rhino name may work. If you also want to measure boundingboxes, closest points, intersections etc. then I have no idea what sort of approach would work any more.
Hi David, I’m not sure that you fully understand my issue.
Human and Elefront allow me to know whatever I want to know about blocks, and extract their innnards, and do whatever I want with that data… except changing the block definition.
There’s two lights at the end of the tunnel, but I haven’t explored them yet :
Elefront’s “Block Bake” (although I don’t know whether it will be able to overwrite an existing block or create a nested block :
Fabtool’s “Creat or Modify Block” (this one has a promissing name) :
Hi,
i’m trying to do the same thing, has fabtool’s component work for you ?
Thank you in advance 
Hi !
Fabtools is dead. I’d recommend either using Human or Elefront.
You’ll need to choose your camp though, as their components are not compatible.
Thanks !
I went for elefront a few days ago and it’s working fine for the moment.
It’s just a bit complicated to modify or add new block geometry because when ever you bake a block, it overrides and deletes all other blocks with the same name. So i guess we’ll have to wait…
Good day =)
Well, you can get the list of existing names and compare to the name of the block you want to create.
If you plan to generate blocks, and perhaps modify and update them multiple times, you should use the “Bakename” input when you bake your blocks. This will add a special Key/Value to your block instance attributes, allowing Elefront to delete the old blocks and avoid name conflicts when baking anew.
It took me a long time to figure this out because it is poorly documented.
