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.
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.
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.
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.
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…
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.
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.
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.
