V6: Making a Better Block Manager

unhandled

#1

I’ve done some posts with suggestions for a better block manager. In using Rhino v5 on a drawing with more than 200 different blocks, I have some additional suggestions, requests, and comments.

1.) We need an option to list blocks (or exclude) that are not made of other blocks. We need to know what parts to make or purchase before we even think about assembling them. In other words, which blocks are root blocks, and which ones are only assemblies of those blocks? We have “Top Level,” but we need to also know the “Bottom Level” blocks.

2.) The Block Manager should be a dockable side-panel or non-UI locking floating sheet. We can’t do anything–including change the view to see anything once it is open.

3.) Part counts should visible in the default view. We can’t do find things such as find zero-count unused blocks, or high-count objects worth simplifying, -or “what can be done to simplify this?” If the initial opening would be too slow, add a button or check-box to invoke the counting process.

4.) It would be useful to be able to choose the sort columns in the block manager. We could find everything from one vender, or find high part counts, or unused blocks.

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.)

6.) The block manager should be be able to copy blocks with a new name for modifications. Adding duplicate meta data can be time consuming to place in the new block. This feature would be useful if the user make a part from the same raw stock, such as I-beam steel. This is handy for things like bolt or framing sections of different length. An option to cut and paste a single-blocks meta-data would also work for this purpose, but would probably be harder to program.

Part Previews:

7.) Part previews are handy, but would be recognize if they were ghosted. There are other modes available by right clicking, but not ghosted. This changeable mode was not evident to me, UI wise. It’s logical, but I wouldn’t trip over it :smile:

8.) Part previews should be a larger.

9.) It would be beneficial to have part previews that have the handle point color coded, such as red, or a slow blinking insertion point, so we know where the part will be placed, or where to put the handle should we update one part with another. Otherwise, a newly inserted part will likely have to be moved, and we will likely have to zoom the view to do it.

10.) We should also have previews whenever we are given the option of overwriting another block/parts, to avoid mistakes when replacing/overwriting blocks.

11.) It would be handy to be able to a volume calculation on several blocks, for checking the final weight. Using blocks costs us some read-only functionality that would be useful to preserve.

12.) It would be handy to be able to fetch the block metadata with only a mouse click or two. Quickly tell me about this block without finding it in the Block Manager. In other words, when we get the properties of an object [F3] on Windows, I would like to be no more than a single click away from the information I added to the block, such as the notes, link, etc… Another way of saying it, is I want a quick Properties or Get-Info on a block, without looking it up in the Block Manager. "Hey, where did you find that part? I don’t know right-click on it, and read where to order the darn thing."
See: Block information: UI Suggestion: Selected Block Properties

Imposter System:

14.) For large projects, it would be handy if each block could have an associated imposter, a simplified representation of a the block definition. The imposters could be toggled on/off globally, or by selection and marking, such as we do with visibility and locking.

This would help in two ways: It would help with rendering/working speeds for very large projects. It it would help by allowing workers to hand off allowed part areas so that others can complete the blocks. Perhaps also, this can help with the locking issues. Within this system, imposters objects could be color-coded by the user to convey special meanings, such as: red for problem, yellow for testing.

The external imposters blocks could be given an a suffix in their file-name or extension to differentiate them from detailed models, such as .3dmi

This system, originated from video games would also allow simplified rendering at a distance, What comes to mind was a person who was designing a factory in Rhino. When looking at the factory as a whole, machines imposters could be switched on, allowing the machines to be quickly moved without the views being slowed by their complexity. Rhino does adoptive degradation, but allow the user to decide which features are important to them.

Going Further:
15.) It would be useful to have in the block manager table, a date field that automatically stores the last time a block was modified. This would help with versioning. These variables might exist internally, but it might be handy to also know what could use a refresh.

16.) A few user fields–even if they were limited to a set length would be a powerful addition to a block definition/block manager. For instance, a user could find out whom is working on what.

17.) Replace Block/Select Block/Definition should open with the presently selected block open, because we will likely be selecting a block named similar to the one we will be replacing. Of course it should still? error if we try to replace something with an exact duplicate : )

18.) (Suggested by Micha)

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.

20.) It would be good if when a block is selected the block name should show in the command line, instead of “Block Instance.” We select a lamp, we could see the name we gave it, such as “Instance: Desklamp Guzzini-Sorella.”

Some notes:

On my current project, I have created all blocks on one layer, the “Default” layer, which worked very well. I then moved the each and all of block instances to other layers. For a single person working on a project, I find no disadvantage to doing this; your mileage may vary. In my Rhino usage, I now treat blocks as global variables, with all the positives and negatives.

I did all my blocks on a layer because finding which layer a block on, or deleting, or moving blocks on layers is terrible and frustrating process, fraught with occasional disdain for the UI designers.
See: Blocks Living on particular layer: Phantom blocks and layers that can't be deleted

Singletons: for my good sized project, I had to make everything that wasn’t a block–a block, so I can have a counted list of it. This amounted to perhaps 15 percent in a somewhat symmetrical machine. I don’t like locking up objects, but I need them counted.
See: Named object Request: Count Named Objects List

Additional References:
Global Material Change Bug: V5 RS9 Layer Bug?

Super Block Manager by Don: Wish: Block Manager

Thank you,
Brenda

Changes: Added imposters
Corrected punctuation, typos, slight modifications for clarity
Tried to make 12 more readable. Thanks MattE.


Update on activity focused on Block Manager
Wish For Rhino 6: BOM Generator
Blocks & updating
Wish: viewport proxies for blocks
R6 wishlist: Manage layers within blocks
Count Named Objects List
Can't delete reference layer
#2

Agreed, maybe for starters especially with: 2 (dockable, non-UI locking), 6 (copy) 7+8+9 (better previews).

-j


#3

Added 17.


#4

18.) If an exist linked block will be edited, than Rhino should use the current block file path and not an other path. Here Rhino is using d:/temp often, but my linked blocks can be found in the current project directory.


#5

What an amazing post, bravo. Thanks for taking the time.


#6

We could also need a proper LinkEditor that handle both blocks and referenced texture files.
So it is easy and fast to fix a file. All in one place.


(Pascal Golay) #7

@Dale, just fyi, this thread, re ‘BlockCommander’, and down the road.

-Pascal


#8

Thanks ATX.

Holo, I agree, and also like the idea of readable/visible paths along with the chooser. I should hope that there is an option so paths can be relative, so fewer things are broken. For example…

Instead of:
C:/Users/Holo/My Documents/Design/Birdhouse/Widgets
C:/Users/Holo/My Documents/Design/Birdhouse/Textures

We sometimes might want:
./Birdhouse/Widgets
./Birdhouse/Textures

Because now we can move the project to a server without breaking anything, as long as we grab the whole kit and kabootle.


(Pascal Golay) #9

Hi Brenda-

In theory both relative and absolute paths are stored- I think the default is to prefer the absolute path if it is valid. Do you find that this is not working?

thanks,

-Pascal


(Marc Gibeault) #10

Hi Pascal,
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).


#11

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… :persevere:


#12

MattE,

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.


#13

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.


#14

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.


(Dale Fugier) #15

Hi Brenda,

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.

Thanks,

– Dale


List of ALL blocks and their children
#16

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.


(Dale Fugier) #17

Brenda’s 1, 2, and 3 (I think). Maybe more…


#18

Dale, I will check out BlockCommander tomorrow.


#19

Hi Dale,

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,
Brenda


#20

Just spending a few minutes playing around with BlockCommander here, too. The first thing I managed to get it to do was crash Rhino :cry:

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.