I was referring specifically to the initial creation of the block (not modification), and specifically LinkedBlocks. My understanding is that you need Rhino to create a new GUID for the new geometry. Perhaps there’s a way to obscure the creation of Rhino geometry before assigning it to an external Rhino file, in the case of creating a new LinkedBlock, much in the same way Human seems to obscure the creation of new geometry into a new Embedded Block definition. I’ll have to take a look.
Agreed - very useful. I disagree with the idea that it’s “obfuscated”, since it actually requires an explicit call to expose it. By that token, you could say Grasshopper in general obfuscates the GUIDs since the data streams say “Referenced Brep” or “Reference Curve” and you have to deliberately convert that to GUID, so Elefront maintained the same behavior. For “advanced” uses like trying to modify the attributes of geometry within a block, I could imagine adding a dropdown or added feature to the component(s) to expose those things.
Yeah, this is why I say we have to be careful adding a feature that works for Embedded Blocks but not LinkedBlocks, and vice versa. I think it’s important to try to maintain consistent behavior / interaction in all cases, but there are definite improvements to be made to make it more obvious to the user what’s going on or why the blocks are behaving the way they are (both re: Elefront, and re: Rhino).
Again, it’s the opposite. Hear my reasoning : since it is impossible to propagate attribute changes in sub-block instances, the only path left is to carry these attributes inside the block.
The way you manage this is by having blocks actually being separate files. THIS, to me, is more “advanced”, as it requires that these files be “generated”, not modeled, to enforce layer, color, attribute orthodoxy with your whole system, not to speak of file paths…
You live in some kind of Geek god Olympus (pun intended), but I’m sure that this workflow is not commonplace at all.
The lower example is what I was referring to - by default Grasshopper itself chooses to show the readable “Referenced Brep” which is user friendly. If you are someone who wants GUIDs, you can access with the ID container or a plugin, but you could happily use GH to do very nice work without ever needing or knowing GUIDs.
But your point is made, and as I said earlier, I agree this would be useful. I will add it to our development list, though I have to think about how to (if to?) show the user which GUIDs are embedded (and can be modified) and which are Linked (and cannot). Maybe it just throws an error when you do it wrong.
I was referring to block management in general as an ‘advanced’ use of GH. Obviously that’s relative. Maybe you can help me out with a definition.
Elefront was developed years before we ever had dedicated file system. It’s not a requirement. LinkedBlocks vs. EmbeddedBlocks, etc. I would say are a matter of preference, not technical resources. I for one like to store that data outside my active document to reduce the likelihood of accidentally changing something I shouldn’t, and if I were working on a single computer, on my own, I would do it the same way. Perhaps with your ability to manage all of those blocks in a single file, you should take my seat in the Pantheon.
I take your points and will see what I can do to address them. We made Elefront available so others could take advantage of its functions and to hopefully provoke /promote conversations about managing information, so it looks like the provocation part has been a success at least. It looks like Keyu has some really cool stuff cooking, so I imagine these conversations will continue to grow and evolve, and I’m looking forward to seeing the result. Maybe Keyu will make Elefront obsolete, take up the mantle, and I can tend the fields of geek Elysium. More than anything it’s exciting to see very cool projects like the one you shared come to fruition, regardless of whatever plugin you’re using, since that’s the point of all this anyway!
