EDIT2: The user is conditioned to expect Windows API dialogs (Options window, Worksession manager, Block manager) to prevent viewport operations. The Block Edit dialog (unlike the others of its kind) allows viewport operation and so it breaks consistency. The block edit dialog should be a floating dockable panel just like the UV Editor.
EDIT:
This wish relates to embedded blocks ONLY. (not linked) and recommends a simple rule:
“Keep parents as regular geometry within it’s source file”
a) If a file is linked as a block, the parent stays in the source file and only instances come in
b) If a block is merely embedded, so the source and host files are the same, then it stays as regular geometry while it’s being instanced within the file.
ORIGINAL:
After many years using Rhino, blocks are still hard to use. Specifically, what gets me every time is that the parent block exists somewhere in memory invisible to the user. We delete all layers and all geometry and there is still invisible stuff in there and it’s cryptic how to bring them back (the Insert command is not in the manager and is not discoverable; should be named “BlockInsert”). If units change after the fact the definitions get out of scale sync. Block layer structure is no longer visible; a block with parts on multiple layers is hard to know which layers it occupies. Block insertion point if forgotten is messy to rediscover during an edit.
I WISH: →
a) once an object is turned into a block, this FIRST block should NOT be an instance, but it should be the parent block itself.
b) Rhino should have a way to notify the user that is a parent block and should be able to move it across layers like other objects.
c) If the user resizes or rotates this parent block, then all child instances should resize too.
d) The user should have a way to show/hide/edit the parent block bounding box and origin.
e) If the user deletes the parent block then the definition itself should be gone too.
Hi Thomas - I am not sure I follow - what would happen if you deleted this parent thing? BlockEdit, though imperfect, essentially allows the modifications you describe, but by editing any instance.
If you delete the parent thing, rhino could issue a warning that all instances would also disappear … or let them disappear and we we can undo it … or have the cursor show a parent block symbol when a block is selected … of have a faint bounding box highlighting the parent blocks as a screen visual cue. Something, anything. I am sorry the current block situation is just not doing it. In this matter I don’t care if you have some way of accomplishing it, we could also drive a car by sitting on the roof and using ropes to steer like Mr Bean. This block interface always gets in the way. I simply hate it.
Yes, I am aware of all block facilities and over the years I keep asking the same questions and I keep forgetting the same questions. It’s just not intuitive. Some of us need to actually physically see the parent objects at all times.
What’s wrong with inserting a new instance of the Parent block every time you want to actually see it? You can do it @ world 0,0,0 with no transforms, so you have your “pure” orginal version, and then either via BlockEdit or by exploding/changing and redefining the definition make it update as needed.
While Blocks in Rhino still could use many improvements, especially the Block Manager, IMHO at their core and how they work in Rhino all makes sense and would find it problematic if the very concept of how they are handled changed.
I have no idea about what you just said unless I sit down to think about it. It shouldn’t require mental calculus to do such simple things,
The way blocks parents are hidden is a problem every time. It is counterintuitive. I will remember it for a week on a project and two weeks later I forget how they work again.
I am not here for people to tell me that this frustration is fake. If you are cool with it fine by me, but I am not.
I’m trying to be helpful. Maybe I don’t fully understand and also see you asking for a radical change of how Rhino blocks system works while admitting you have a problem wrapping your head around how they work prompts me to offer a solution or maybe just a way of thinking about them that could help. We work on models that consist of 90% of blocks, heavy, complex stuff, and all seems to work fine and well-streamlined (obviously countless things can get better…)
Back to your issue of the Parent block that always exists. Currently in Rhino the Parent Block, which is a block definition, is “virtual”, and it’s copies are Block Instance objects.
What I proposed (and use over here as well) is when I want to “see” the “Parent” (if you want to think about it this way), you just Insert that particular block definition, at world origin, with no transforms (in fact you can insert it anywhere, just need to remember the origin point). And then operate on this, as if this is your Parent, then delete it when done. How is this different than having a Parent always sit there in the file, visible? You can, if you want, dedicate one instance to serve as a Parent, keep it on a special layer and show/hide as needed, too. Rhino won’t stop you from doing that. But why keep junk in your file if at any point you can turn your “virtual” block definition into a visible “Parent” one?
I guess I am just offering a different way of thinking about it, if this helps.
For sure I would not welcome to see a fundamental change of how Blocks work in Rhino, and luckily I don’t think it is likely to happen anytime soon.
-Having to keep figuring out each time which command instantiates a definition is a nuisance.
-Looking at the block manager and not seeing an edit or insert option is a nuisance.
-Typing “Block” and reading the command line list to see which of them resample an “edit” or “Block insert” and not finding it, is a nuisance
-Having to come to the forums to keep asking how to bring back a block geometry and having Pascal keep reminding me of the “Insert” command (Because someone didn’t want to name it “BlockInsert” and make it discoverable) is a nuisance.
-Not knowing or remembering which layer the definition lives on is a nuisance
-Having to explode an instance for adjustment and then forgetting where the insertion point used to be when the other instances were created is a nuisance.
-Creating a block definition and then days later the scale changes on the file but figuring out how to get the block definition to the new scale without messing up all it’s instances is a nuisance.
-Having a user delete all objects in a layer and then be told that he cannot delete a layer because some abstract block geometry lives there and having to figure out how to relocate it is a nuisance.
-Having definitions being hidden creates a second layer of geometry; which an unnecessary abstraction. If the original geometry during construction was nested in a layer structure of it’s own, that organization is no longer visible once it’s placed into a block abstraction. We can see the objects layer-colored, but have no idea how to rearrange or relocate their components
I like things simpler and not hidden. All geometry should be visible to the user and obey all unit scaling and layering operations as any other geometry.
The parent blocks may contain subcomponents that live nested in various layers, instead of hiding this structure, I’d rather see a visible box highlighting me which geometry in a layer is part of a block parent. On top of that we don’t want to have the parent blocks in some separate place, they could be part of the whole model. In a classroom with a hundred desks, I like to know the one surrounded by a bounding box is the original parent. If I rotate it within its bounding box then all desks rotate, if I rotate the entire thing including it’s bounding box then only itself rotates.
I prefer more visual UI interactivity. Right now just too much of it is cryptic.
But I don’t think that’s really the biggest problem with ‘blocks.’ The problems are more that editing is cumbersome, they can slow down performance when they’re meant to improve it, people try to use them for MCAD-like “assemblies” which they aren’t for at all, people want to use them to make variations, etc. This abstraction about the ‘parent’ not being ‘in the model’ is not pretty minor. NO geometry is Rhino is really ‘in the model,’ it’s numbers in a database somewhere. And a ‘block’ isn’t actually the geometry in it, the “block” is the insertion point, it’s a “link,” not the stuff in it.
That’s not going to actually work in any example more complex than what you showed. Most real-world models would be a indecipherable mess of block bounding boxes. The problem with UI change requests and the reason 99% of them go nowhere is that you need to think through all the implications for lots of different situations for different users and reconcile them or it’s just a non-starter. I’ve had a similar idea, to make editing easier, of somehow having the block definition editable all the time in the model, maybe through layer structure…but there are many, many…many details to be worked out.
Imho one thing that mcneel could do quickly is to bring the block manager into panels so it can be always visible and accessible (this would give more control when using blocks because you can select an instance and see it’s details in the panel)
Adding some buttons to manage blocks would be the second step (I mean grouping all the main commands) .
The third should be to manage better nested blocks.
I don’t accept that argument. It generalizes to apply to anything 3D. Did you argue against 3D software in the 1980 because models can become complex and wireframe views would be an indecipherable mess ?
Complex models are organized in layers. You never work on them in full.
If we want to work on a portion in the forest, we either turn off other layers or isolate the objects. How do you make heads and tales of groups right now in your complex model ? Is that indecipherable mess ?
Also, is your model going to be full of parent blocks. Seriously ?
Organizing large models with layers, blocks, groups, and/or worksessions is a nightmare. And you want to add another wrinkle to it with these special block instances that are editable and somehow differentiated…good luck with that!
As I said I have had a very similar idea to have blocks editable without going through BlockEdit, but the reason you want to do it is utterly baffling. There must be…possibly as many as 10 people whose primary confusion about blocks is that they are instances of geometry that’s “hidden” in the model. The primary problem people have is with the idea that a “block” is NOT the geometry in the instance, it’s that invisible insertion point, that hyperlink, so when you change its layer or assign a material to it something “unexpected” happens.
So right now you have your UI mess and you want to edit a block definition to assign render materials to its sub components or tweak a surface. You are telling that somehow magically you manage the mess when you show reveal the block for editing ?
I can already brainstorm several ways for the graphical solution: Here is one for you - Show/Hide ParentCages.
Also, your solution to clutter has been to stuff things under the rug ? … abstractly ? invisibly ? This is people’s idea of ergonomic UI ? Were you among those that argued to remove isoparms from extrusions so that we have no idea if an extrusion is capped any more ?
The blocks as they stand now are already a poor design to greater degree, their logic fails on multiple fronts and you are getting stuck in a triviality of far less importance than what a graphical solution would solve. Invisible definitions is not a solution to clutter management.
Well, if you use Blocks often enough remembering how to insert them should not be an issue; either via command, or make a button, alias or keyboard shortcut (Rhino is great with this flexibility)
I agree, it’s been extensively discussed here that the Block Manager needs love. Insert button seems like a no-brainer and should be there; Edit is trickier since it’s not so obvious what we would edit (what particular instance? Unless some new UI would be created to edit just the generic definition…)
You can just double-click the instance to enter the block edit mode (or as above, make macros, buttons, shortcuts, if you use it often enough). What can be better here is double-click should allow to go deeper into editing nested blocks… Note you also can’t edit non-uniformly scaled instances, but in V7 “BlockResetScale” has been added to somewhat remedy that (I know, not ideal workaround…) That’s why editing newly inserted instance is a good idea if needed as I mentioned before.
The definition does not live on any layer, its always the objects in the definition have particular layer assignments and in a messy file can cause problems with not being able to delete layers that contain such objects used in some (sometimes unknown) definiton. I agree that if Rhino prevents layer deletion because of that, it should offer a way to delete the definiton or offer an option to move these objects to another, new or user-selected layer.
BlockEdit helps here, no need to explode it.
Agree, this should be addressed and was a nuisance here for a long time, too.
In general I agree with your assessment that Blocks management in Rhino still could use lot of work, just don’t think your original proposed solution would help or add to the problems.
That is a no-no. I am working on a fairly complex model (but not too much) of a robotic application and it has connectors, joints, and bearings as instances. There is at least a hundred bearings in various orientations and sizes. You always need to work on a definition that doesn’t have any matrix transformations to it. … and suppose we do use the Block reset scale to get back to metal, then we have this scenario where (in this case) the model changed units from mm to cm somewhere half way. So now a few of the definitions are out of scale compared to their instances. That turned out to be a small fire having to put out. (Made a bug report about it). If block parents were left as geometry, these things wouldn’t even be a thing. Now McNeel has to deal with corner cases.
Overall, this tells me you are probably an architect using blocks in a rudimentary fashion for fixtures of standardized sizes. I may not be using blocks often, but when I do it’s all out (like when it rains it pours). That’s why the ergonomic flaws haven’t hit you in the face as hard while it all came at me in a week at once.
Yes, it does. Create a block out of objects in the three separate layers. Delete all objects in those layers. Now try to delete the layers themselves. You get an error. "There is a block definition named “Block xxx” on layer “Layer xxx”.
ok, that’s not an argument against undiscoverability. You agree it’s undiscoverable, but rely on the user’s memory and familiarity. As long we understand this style of thinking is incompatible with ergonomy.
Bingo! The DEFINITION should be conceptually entirely independent of the instances. The definition should NEVER appear in the model, only instances - even if it’s stored in the same file as the model. An entire well thought out internally consistent infrastructure for dealing with definitions should be developed. Definitions should be treated, no matter their actual storage location, as if they are completely separate files as they would be if they were located in some network file on the other side of the world. Considerable thought would need to be devoted to making this conceptually seamless, but once implemented would seem effortless and “one concept fits all”. If an instance needs to be modified, the command to do so should automatically open the definition editor with guidance on creating a new definition from the original which can then be modified and relinked seamlessly to the original instance. In an ideal world any definition, regardless of where it’s located, would “know” all the the locations where it’s been instantiated so that if it’s changed all instances will be updated.
Why couldn’t definitions work like git so that the “Master” definition could be checked out, stored more locally, and checked back in? This would require authorizations, etc.
And, yes, this would definitely be a “big boy” system. It seems, however, that a lot of the people finding the current system “less than optimal” ( euphemism for “completely useless junk”) are in fact big boys.
What I really like about Rhino is, that it has some quite abstract / generic concepts. Some of the usage / workflows is then up to the users creativity. Of course, if you compare rhino s blocks with components in Feature-Tree based / Solid-Modelling Rhino Blocks are not so strong. But with a nice Layer-Structure you can have nearly everything that is questioned in the initial post.
I recommend and teach the following structure:
Blocks (one inital Layer containing all Block-Definition-Geometry)
__FirstBlock (everything for the first Block, e.g. Wheel)
____FB_crvs
____FB_constr
____FB_srf
____FB_axis
____FB_nestedBlocks
____FB_at_000 (this is where i define the Block / First Instance - and most times apply -BlockEdit)
__BlockB
____BB_crvs
____BB_constr
____BB_srf
____BB_axis
____BB_at_000
…
Wheels (insert all instances…)
Nails
Hinges
And i think it is nice, that Rhino does not force us users to do so… but allows different approaches for differnt tasks.
And Blockedit can be used quite freaky, as it allows editing in different positions / rotations.
So, the main problem is EditBlock…
Just to give some ideas:
EditBlock (double click on instance) could open a floating viewport with the block definition to edit (no need to have the block with all the other stuff that can hide part of the block)
EditBlock should have the ability to create a new block definition from the old one (to take old blocks unchanged and to avoid all the work to explode the instance, modify and create a new block)
EditBlock should have some extra buttons to help the user finding and replacing the instances he want to modify (a ReplaceBlock button)
BlockManager should have some shortcuts to enter EditBlock mode and to identify and select (in a better way than now) istances
I don’t see the need to change all the way Rhino insert the blocks, only better ways to edit and duplicate them.
Is that really an artificial limitation applied for arbitrary reasons ? So you would rather recreate an entire Rhino inside Rhino just to edit definitions and handle their layer structures ?
My proposal is simpler. Just make them visible like other geometry and in YOUR case you can create a Rhino file dedicated just for block definitions and import them into your working file, this way they will always be outside your working file.