A thought about Brendas’ comment on having all blocks in a model on the same layer (something that I keep thinking isn’t ideal, but it’s a lesser evil than anything else I can think of, in the absence of a way to not have Blocks assigned to any layer): Would it be possible to add an option in the Block Definition Properties window that comes up when making a Block to allow you to create the new Block on a layer of your choosing, including a ‘Set As Default’ check box next to it? That way I’d get a simple visual prompt at the point of creation to remind me that I’m probably, ummmm… on the wrong layer
As a side effect of this, if the layer that I’m ‘sending the Blocks to’ is turned off, I could chomp my way through a model creating Blocks and the parts would disappear from view as I went. When the screen is empty, I’d know that I’d turned everything into Blocks!
Yes, I agree that creating all the blocks on any particular layer is…interesting. I would rather have the master not attached to any layer.
My using “Default” is a kludge. I had found that I usually delete all the predefined layers except for “Default,” which I use as a only until things are moved to other layers.
On the positive: there usually a “Default” layer in a Rhino 3D drawing, so it’s usually not deleted or renamed.
On the negative. There’s nothing intrinsically special about the “Default” layer, so the block definition is still locked to that layer. Another issue is on on .stp export things are not so rosy for the receiver.
Regardless, after I define a block, I move it’s instance to whichever layer I want. Though the ghost still remains.
@dale
I am looking for help on saving links - filepaths as well with the count command in blockmanger.
like in Brendas, 5
’Notes and links should also be copyable/exportable with the other items in a list, along with the other data. Where did we find those parts? What is the point of collecting information, if we cannot extract/use it? Connect Rhino to the building and buying pipelines. (On my project, I will have to copy and paste all the links and notes individually from Rhino to a spreadsheet.) ’
@Lifeline, Thank you for necromancing this thread.
I have had some real-life issues, but I am curious if some of the suggestions posted not only by myself, but for other, are being implemented in V6.
We use the ability to assign linked blocks to layers as a tool. In fact, if this feature went away, my workflow would have to change considerably. I can’t imagine how this would be an improvement.
I installed WIP one day because after spending hours trying to reassigned an object and each and everyone of the nested block to the layer I wanted, I got very frustrated. This thread gave me hope this would be better in Rhino6.
I am not as disciplined as Brenda, I often, in the heat of designing, import my object to the current layer and later have to pay dearly when I want to change the object layer.
Like many describe here, since we do not have the ability to assign visibility to a block, I use Layer and sub layer as a kludge to help with the design of complex assembly. Since I an more an integrator I often import STEP files which contain many nested objects.
The ability, in a single command, to change the object and all nested objects layers in the “edit in place” function would be most welcome.
Ability to assign visibility per block would be awsome…
Seeing the nested objects as a tree function rather than a flat list would be gravy…
I started this thread, because I saw the block manager as something that clearly needed some attention. The block manager isn’t as sexy as say working on Grasshopper, but it is an important part to get your ideas to the real world.
This thread got almost half as much attention as the pinned welcome to the Rhino forums. It seemed fairly well received and contributed to by others. Rhino3D is obviously a commercial product, owned and directed by their financial needs of their owners. Though, I feel a little bad that not only my ideas and needs, but the needs of others may not have been truly considered.
I helped a friend with a project, with a greater complexity than a riding lawn tractor, and with hydraulics. It had hundreds of parts. I found Rhino3D a good inventor’s tool because the user interface was so interactive. So, a complicated mechanical machine was devised in Rhino3D, but then summarily imported into something else–largely because of the block manager.
Fast forward to almost 2020, and what has changed ? NADA.
My guess is that I have ranted about blocks for so long that the Rhino devs chose to never give a f… so as to irritate me to death and hopefully get rid of the damn bugger.
Sorry for all you folks who are also desperate for improvements on Blocks…
While I don’t think that it’s realistic to believe that there is only one person–doing all the programing for Rhino 3D, it is my hope that the Rhino 3D forum remain within my idea as an outstanding forum, where people get along.
While I (am) sorry about the lack of progress and attention that a lowly block manager gathers, I am even more sorry that a project that was developed mainly in Rhino 3D–was transferred to another designer and design package; much of the reason was directly related to shortcomings in bill-of-materials centered functionality.
Because of Grasshopper’s expanding architectural usage, Rhino 3D will see increased of larger projects.
Most of the things I have ever asked for: A better block Manager, some work on the 3D OpenGL pipeline, and smoother Cycles real-time response, and additional material mapping for extruded parts have all been centered on allowing Rhino 3D to work better with larger projects.
What an epic thread! It’s reassuring to see that others are having issues.
FWIW, I’ve got to the point where I instruct colleagues (Architecture) not to use blocks in Rhino - or at least the only scenario I’d accept is a reference block built in Rhino .3DM with no blocks of their own contained within. Forget developed CAD drawings or blocks in blocks.
Ignoring the endless list of problems they create, my biggest issue now is that they often irreversibly corrupt our files.
Blocks are so important to large scale projects I wish there’d be more tangible progress in this area. As it is I reckon putting the poor beast down would be more humane.
Interesting thread that I wasn’t aware of. And from 2015 too…
Well, I managed to get a bit of traction with developers in this thread recently:
Which resulted in something that might completely circumvent the crusty, ancient fossil that is the current BlockManager:
So, a bit of a stopgap solution, but it’s better than nothing…
@Pascal said that I was 20 years late to complain about Blocks, so I guess this thread was 15 years late, but I wonder when it’s time to let go of the past and instead try to invent a better future?
At work, we’re currently underway of switching out our PDM/PLM system, so it doesn’t just work with Solidworks, but other CAD software too (except Catia). It’s a monumental task, but finally started actually in (a very small) part due to the introduction of Rhino in our workflow. That’s years of projects and revisions we either have to convert or just accept that we start from rev 0 again, and several people who haven’t worked with versioning before that now will have to learn. Still worth doing!
‘Container’ files (blocks, or whatever they are called in your favourite software) are perfect transportation method for corruption…
I’m not really picking a side, apart from a principled ‘anti-block’ stance
Large projects need blocks, and I do large projects.
I always get told that I probably should be using other tools, and my answer is : yeah, but I like/need Grasshopper too much.
The modeling part of Rhino is in trouble because it really catters well for no one these days : Solid modeling => antiquated by ALL the parametric CADs out there (Mecha and Architecture alike) Free-form modeling => at last adding the popular Sub-D modeling, but I doubt it can compete with existing players.
To me, Rhino can only stay relevant if it can (in order of decreasing importance) :
-Integrate Grasshopper more tightly in terms of interface, in the way tools work (GH equivalent tools should have the same options, for example), and in terms of geometry denomination (what is a “Brep” / what is a “Surface”…) .
-Get Blocks right (just listen to what users have been crying for all these years goddamit !)
-Improve solid editing
-Get a reasonably good Sub-D and retopo / UV mapping workflow rolling
-Make the interface a bit smarter (not an ovehaul ; it kinda works as it is but there’s lots of little silly things that can be improved). Integration of GH2 will require to bridge the gap between the two interfaces anyway.
The good block/instance/copy system is a must for working on working on projects with multiple parts.
I don’t think the present system needs to be completely rewritten. I think the most serious programming issue is that blocks presently become defined to a particular layer. If I draw a bolt or a washer, I may use it in many layers.
If there was that kind of artificial limitation in object-oriented programing–perhaps you would have quit programming.
My workaround for this for making all blocks on the Default layer, chosen only because the users don’t often delete it–goes bad if I have to explode something.
As for the rest, it’s meta-data, which would need to be saved, and some UI additions to give the users a bit of power–and perhaps an imposter system to give the power users a bit of speed when assigning large projects.
