V6: Making a Better Block Manager

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.

1 Like

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.

1 Like

All very nicely explained. Blocks don’t really want to be related to layers at all; the information within them does. I think of them as the equivalent to Folders in Windows; a container for a collection of items and information. The analogy starts well in Rhino - double clicking a Block opens it, just as it would a folder in Windows. Thereafter, the current logic (in addition to the layers confusion that Brenda alludes to) falls apart. If double clicking opens the top level block instance, why doesn’t the same action do the same for subsequent (nested) blocks?

+1 for Better block management with named object tracking/counting.

I do think quite a few of Brendas original digital asset management requests could be handled with autode$k Vault Basic & the rhino2vault plugin…

Prehabitat, thanks for the +1,

[Yet, I don’t want Autodesk anything on my computer because I feel they just assume it’s really their computer.

Beyond the question whether or not it is Rhino’s best interest to employ competitor’s plugins, I don’t like using plugins for a workflow foundation.]

Way back in 2011, I spent quite some time trying my best to communicate the problems of the current V5 Block Manager. Nothing changed, and V5 was shipped the way it was. Now people are (I think) saying more or less what I was saying back 5 years ago.
Since the original discussion list evaporated when this Discourse forum was set up, I thought maybe I would re-upload here the documentation I wrote. There are three parts to it: one is a screenshot of an assembly. Second is a diagram of the block structure you would want to create for the assembly, and three is a discussion of how and why it doesn’t work in Rhino.
Looking back, I can see there are probably better ways to express the same idea, but this might still be useful.



4 Likes

Ian,

It seems that we both identified the issue of the nameless singletons.

It seems we both identified the need for a basic part to be counted. That is why I (also? ) suggested a reverse tree, where you see root objects, and then those things that were made of them.

Though, I hope that whatever is made is flexible. I just don’t want it to look like solidworks, when it’s done.

(In a 100MB (no meshes) drawing, I now have 378 Blocks, representing 2557 individual parts in one drawing. I only used 1 external block, a Honda Engine, which is about 105MB with its mesh.)

For some reason, looking at your 3-cylinder engine, is going to make me listen to a video of Triumph 675 Datona engine.]

Dale,

Have you considered making BlockCommander into an object browser? To start with, all objects not in any block definition would be listed at the root level.

Thank you,
Steve

Is any of this going into the V6 block manager?
I didn’t see any changes in the last beta, but it’s been a month.

@Brenda

Suggested typo fix in the headline: ‘Manager’ vs. ‘Manger’

1 Like

@Schultzeworks, thanks. I can’t edit the OP any more.
2,100 hits, and you are the first person who noticed my typo.

“No one can proofread their own writing,” unknown.

done. I wish fixing Rhino bugs was as easy ; )

1 Like

Thank you.

We can’t have the blocks swaddled up in the barn.

3 Likes