Hi @lars and team,
Great to see this stuff is getting some love. I understand that this is mostly for your architectural customers, but in the name of the small minority here doing industrial design work in Rhino, and working as a team, I’d like to ask a few other things to consider including, that might benefit users in all industries. I numbering them with the g-prefix to avoid confusion with all the previous numbered lists on the thread:
g1. date of creation of the block definition
g2. date of last edit of the block definition
g2. .3dm file name from which this block definition was first created (it’s common to keep using a Block that came from other files)
g3. name of creator (is this the new handle I edited, or the previous one that Alan had done?)
g4. expandable viewer like shown on this example below, where maybe that block had 4 design iteration versions and you are looking for the one version with the 3mm chamfer, impossible to see on that postage stamp:
g5. Have a donotscale/skew/deform/mirror option. So some blocks are absolutely uneditavble from a geometry standpoint. Very important for us for internal components or parts that are reference of other existing parts/constraints and should never ever ever be scaled.
g6. have a to not mirror geometry, just mirror location/bounding box: use case; I want to mirror an assembly of objects, but I do not want to mirror screws, threads, or a microchip on a PCB, I just want to mirror it’s locations/boundingbox.
g7. Ability to set custom SetObjectDisplayMode attributes to a block, or objects inside a block, and that works regardless on what viewport you are in later.
g8. Ability to change materials or color assignments to any bock instance, as overrides outside the block properties.
g9. Cached of imported/referenced geometry blocks (from .stp files) with .3dm native geometry so they are faster to display and open.
g10. Propertiless instance. I want to control how to override/ignore any block information such as color/material/layer/etc. without editing the referenced block. I do not want to think about what layers I need to turn on, for an instance of a block to be visible, other that turning on the layer where that instance lives. Same for seeing an instance of a block (referenced geometry) with a different color and/or material applied. Does this make sense?
In summary, I’d love to have blocks being more useful and more manageable; and this requires a few features that are still unaddressed in its current architecture, regardless of how you visually display them.
Thanks,
Gustavo