Cautiously wading into the conversation here…
I hesitate to get mixed up in the broader topics discussed here, but I can offer how we’re using Elefront here at Front to manage attributes within nested blocks, in the context of large architectural models being worked on by teams in multiple offices in different geographic locations.
In our case, we also use blocks to manage the propagation of small-scale geometries (like gussets, brackets, bolts, etc). across a large model, with those components carrying attributes along with them. Typically, we would define those blocks in an algorithmic way. That is, if we have the same bracket with 14 different lengths, we’d use a script to generate those, and use the Define Linked Block component, which would create the fourteen .3dm files of those blocks with their attributes. This could include blocks nested within it**.
If those pieces are assembled into another block, and we realize we need to add or change an attribute to the sub-block, we would go back to the original script, make the change there, and re-generate them through the same Define Linked Block component, thereby overwriting the sub-blocks.
If you are using the Import Linked Block component, click update or re-running the component will pick up those changes since it is newly reading in the information. Especially to achieve the functionality described by the OP, I highly recommend Linked Blocks to provide that continuity.
A quick note about that: Point taken regarding consistent filepaths. Our offices are distributed geographically, so we’ve implemented an IT approach that features consistent filepaths across our offices. Perhaps other options there would be something like symbolic links, or some other way to at least simulate filepath consistency. Worst case… Dropbox? Not sure. But if you can work that out, using Linked Blocks we’re able to have someone in Hong Kong modifying dozens of individual parts while someone in New York is combining them into assemblies and someone in London instantiates them across the global model.
Regarding the nested blocks, it’s true that you can’t go modify a sub-block within the active document, because that is a Rhino limitation. Indeed it would be nice to have that functionality. I suppose it would be possible to do the defining of your blocks, and the nesting thereof, within a single Rhino session, which would then keep your blocks live in the active document. We prefer to work in a more piecemeal, distributed way, because I could see that getting quite unwieldy when you have hundreds of block-types.
**An important note about nested Blocks and the current version of Elefront. Right now, when you use Import Linked Block, it does, as the name would suggest, create a Linked block. However, if you are doing this to create a block, which will then be nested, only the information about the block instance itself will be passed. For example:
- I have a single fastener block with some attributes and a Brep representing the fastener
- I assemble those into another block representing a bracket, using the Import Linked Block component
- I then propagate my bracket blocks in a larger model, assuming the fastener will also pass through.
With the default functionality, the fastener block’s geometry (and its attributes) will not pass through. The block instance will pass through, as well as the attributes applied to the fastener block instance. That’s because in the bracket model, it only contains information about the fastener instances, not the geometry within. To get around that, in top-level block (the bracket in this example) the sub-block (fastener) need to be changed to “Embedded and Linked” in order to get the geometry to pass through.
In the next version of Elefront, we will expose a toggle on the Import Linked Block component to give you the option between “Embedded and Linked” and just plain ol’ “Linked”.
Of course much of the discussion on this post is more philosophical, and I’m going to favor my pragmatic side by sidestepping that a bit – I think it’s valuable discussion, but I am simply offering what I hope is some useful information until the smarter folks figure out something else.