On some occasion I would have liked the power to decide which to use, to change from absolute to relative.
For example, to start a new project with the same structure as another one, being able to choose if a component is always the same (absolute file path) or different for each but with the same name (relative file path).
There are a lot of very good suggestions in Brenda’s list. For me, 2), 9), 10) & 11) are particularly resonant. I’d like a better description of what’s proposed in 12).
I’d also like the way in which nested blocks are accessed to be more logical. At the moment, double clicking a top level block gets you into edit mode, so why shouldn’t the same apply when double clicking blocks-in-blocks? A dockable block manager would be excellent, especially if it had ‘+’ beside nested blocks to allow you to expand individual branches of the block structure. I don’t like using blocks in Rhino because of the current way in which they are implemented, but their power of organisation is undeniable.
The approach described in ‘notes’ about having all blocks on one layer is interesting. Will have to look into that in more detail. So many times I get caught out creating a block when I’m on the wrong layer; the discipline required is immense…
I created all of my blocks on the “Default” layer because one exists in almost every Rhino drawing : )
Yes, it’s daft, but it works around the I’m-born-on-this-layer, so this-layer-cannot-die-without-me, situation we have.
It still takes some discipline to use this (cough) technique, as all objects included in a block must be on the default layer, and then once the block is defined, it’s instances can be moved or deleted whenever you want.
In this (laughs) idiom, I group the block instances instead of making blocks of blocks, which unfortunately, I cannot find a way to tally in V5.
[With multiple users working on the same project this may or may not cause problems. Making a machine or perhaps a building as an entity made of subsystems, I don’t think there are problems on all blocks being born a single layer or no dedicated layer at all. Though with multiple users, people might muck up the Default layer, but they would do that anyway. On the positive, multiple users might want to create layer names contrary to the overseer’s wishes, but in Rhino, I think there are preventative measures that import irrespective of layers, anyway. It would seem that historically layers’ usage was expanded to take the place of user accounts on the same drawing, which where the real problem lies. For V7 : ) Every block would have an creation/maintainer owner, assigned rights and privileges, which are assignable by one overseer. Then all of the block definitions could be global, and not be locked to a layer. The overseer and their bean-counter would still want to see all the blocks to get the bottom line.]
BTW, I tried to make #12 more clear.
Aside from my request/rant, I wanted to state the obvious: Rhino was made to efficiently and artistically create any three dimensional object the user can imagine.
As much as I hope McNeel continues to have that focus, I think now, it’s time to give the Block Manager a little attention because it helps bring the user’s creations into the world.
19.) I found that sometimes, I build objects around blocks, and I just don’t want to delete those blocks because it costs little to insert a block, but it may be difficult to remember, indicate, or reposition the block was that, that thing was built around. The problem with this is: it will throw off counts.
It would be handy to select an individual block or blocks, and tell Rhino exclude them from being counted.
Great stuff - thanks for taking the time to compile all of this. Tuning up the block tools is certainly on the to-do list for Rhino. Once we kick Rhino for Mac out the door and turn our focus back to the Rhino WIP, you should see some movement in this area.
A while ago, I threw together a Rhino 5 plug-in as a prototype of where we want to head. It is my no means complete, and it certainly isn’t as full-features (based on what I’ve read on this thread). But it might be worth your (and others) time to download, install, and post any comments or concerns you may have.
BlockCommander.zip (22.8 KB)
I’m interested in your feedback.
Dale - can you give a quick rundown of the features/functions we should see in this? I’m away from my computer for a while but would be interested to know what it offers.
Brenda’s 1, 2, and 3 (I think). Maybe more…
Dale, I will check out BlockCommander tomorrow.
I checked out BlockCommander.
Unfortunately, it still has no differentiation between blocks-of-blocks, or child-blocks and plain old or parent blocks. So, we still don’t know what parts to make, buy, borrow, or steal.
For this, reverse-tree would work, from leaf objects to the trunk assemblies, something like this, not so much graphically, because this is not the only way that it can be displayed, but our focus is on the parts. However, a bolt may be user for more than one thing, so we still need a flat list of all the root parts.
We need a box of what parts to make our pistol?
Block Commander is dockable, good. Catchy name, good.
I want a larger font, but need larger icons, please.
It can show unused blocks, good. However we cannot highlight and insert a block, so we would have to use the other chooser.
Thank you for the opportunity to try it,
Just spending a few minutes playing around with BlockCommander here, too. The first thing I managed to get it to do was crash Rhino
The layout is a good start. ‘+’ symbols are good. Not sure what the blue arrows are supposed to signify. Single clicking doesn’t highlight the Block in the model (which is the behaviour I’d expect, along with Shift-click to select multiple items). Double clicking an item doesn’t open the block for editing; it “cough” crashes Rhino “cough”. Right-clicking on a block name to gets ‘select’ to pop up for all items, but clicking ‘select’ on a 2nd, 3rd level nested block does nothing - the button doesn’t go yellow on mouse-over either. A couple more options to go in place of select would be good - SaveAs or Export, assign material (see below) come to mind.
I don’t think having everything expand to reveal that it’s made of a single polysurface is very helpful. As a visible item can’t exist as a Block without being made of constituent geometry, it doesn’t tell the user anything that they don’t already know. It also means the every item has a ‘+’ next to it. For me, the ‘+’ should be reserved to signify that the block contains either more Blocks (bold type ‘+’ ?) or multiple bits of geometry. Then, scanning the BlockCommander list for the +'s will tell the user very quickly where the high density of information lies. I don’t think I’ve worded that very well…
EDIT: Found that unchecking Show Objects in the settings addresses this last point.
It would be much clearer to view quantities if the numbers were in an Excel-style column of their own as Brenda suggested. Expanding a nested block could then sprout an indented new column for the nested quantities, complete with its own scroll bar. That way, you could collapse the list but still be able to view and compare nested items even if they are a long way apart in the BlockCommander listing.
It would be nice if selecting a block in the model highlighted it in the BlockCommander list, especially if shift-select worked for multiple picks. It would make a quick way of learning lots of part names, which can’t be done through the Properties panel.
Taking it off on a bit of a tangent, it would be great if things like Volume, Area etc could be added in additional columns, along with a method of assigning material/specific gravity etc in Rhino, then make the whole BlockCommander capable of export as csv or similar.
Number 20 Added, above.
(And thanks for the support, MattE, and an interesting idea as well.
@Brenda - Item 20. The same thing happens when the pick list appears in a viewport after clicking on overlapping parts. A long list of 'Block Instance" isn’t the most helpful description I could think of. If you name the Block in the Properties panel, the name then appears in the pick list next to Block Instance. Does the same thing display on the command line?
In the command line it just reads:
1 block instance added to selection
If there is only one thing, I’d like to always know what it is.
Seeing part names will help remember their names, such as:
1 block instance added to selection: Fastener 1/2 20TPI Nut Stovers
If named, I would also like the name showed in the command line, when selecting any single object.
1 extrusion added to selection: Motherboard Bounding Box
1 point added to selection: Hinge Point
1 curve added to selection: Les Nessman’s Desk Perimeter.
So, I want my friend to be able to learn what the parts are/do in a machine.
I will start a new thread for this, for regular objects.
I did find an disadvantage to creating all of the blocks on one layer and moving the instances. On export to .STP , objects will be exported to their layer of creation rather than the layer of instance destination.
I haven’t tried the BlockCommander, but I think the idea of a docking block manager is crucial. I think a few features of the layer manager could be implemented such as visibility/locking/nesting. Also a display mode that can be switched per block would be good(including a bounding box display). Each block could have a thumbnail that is drag/droppable. Drag a new Rhino file from Windows Explorer onto the thumbnail to replace it(This would be worth the price of V6 by itself).
I’ve found that in the manager, currently we only have a preview of a block if the layer is active. I should think that this is a bug.
Yes, please, indeed.
An overhaul of how Rhino manages blocks is dearly needed, for speed and ease of use.
We who want to go beyond modeling single objects and for instance - pun intended - make
complex architectural compositions with hundreds of objects recurring hundreds of times, blocks are used all the time. In fact, we often build with blocks only.
For Rhino v6, improved block managing is at the very top on our list.
And how about the underlying concept, capability and functionality of the block manager as we now know it? Surely there are things it should do that it can’t and maybe the current whole idea of what a block system should be as well as how it works ought to be up for discussion in light of experience with the current system?
The creation of of a master block definition and its instances is a must for large drawings.
The most unreasonable part of the overall method is that a block definition lives on (or be local to) any given layer. If you create a block on a given layer, you cannot delete that layer, and you have no way to tell which blocks were created on which layers. Organizing layers and blocks becomes unmanageable.
I (still) create all of my block definitions on the default layer, as most drawings will have them, and I would likely never want to delete the default layer. I then move the instances to the appropriate layers. All is well, except…
If memory serves me, there is a problem with this: when I export objects to a .stp file, I lose layer information.