Wish: Make embedded block parent always visible like other geometry

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.

cheers,

–jarek

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.

-tom

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.

Hi Thomas - the definition is held, behind the scenes, with the insertion point at the world origin - one way to edit this ‘in place, for the definition’ , which I think was one of your wishes, above, is to insert a new instance at w0,0,0 and then BlockEdit that, and then delete the instance when done. If that is really a helpful thing to do, and I have not misunderstood, I think it should be possible to shortcut that process.

-Pascal

1 Like

Two things;:
a) Block edit is almost never useful (at least not to me). If I have a connector and need to change it’s locking mechanism, I need to get in there and edit the surface structure of the shell. So I always have to BlockInsert the geometry itself and start regular modeling operations on it.
b) You guys never thought that we need to know the base point of blocks ? Someone had to write me a python script a while back to add a dot ? Without this crucial info the entire swarm of instances shift when we re-blockify the edited block but miss or forget the original base point.

All the above on top of Dale’s wrinkle that all our block definitions would now be tiny if the model units got changed, because we are not all architects.

Is this built in the current file and Blocked or inserted as a linked file? If the latter, BlockEdit should open a second Rhino, let you edit as needed, and then update the blocks when you save and close that.

-Pascal

Current file. Embedded not linked.

Ok, this is the third hint I get (from you and Dale) that linking was the original design intent for blocks and embedding was merely an afterthought. If that’s the case you guys might as well remove the embedding option altogether and give people only one proper way of dealing with blocks.

Well, I don’t know that we need to get rid of anything, but in the context you describe, it certainly makes more sense to me to insert a linked file than to build it in place - of course not seeing the exact context, but in general, if I need a relatively complex object as a block, I build it in a separate part file.

-Pascal

In that case I don’t see the point in people resisting this thread in the first place.
If they are linking files as blocks anyway, what does it matter to them if the emebeded option were to keep the parent as regular geometry ? (It’s regular geometry anyway when they open their linked Rhino file)

How about 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.

Hi Thomas - Is the underlying problem, for you, the way BlockEdit works with embedded blocks?

-Pascal

I am afraid not. When blocks are embedded, block edit is never useful to me.
(Generally up to 100Mb, I try to keep files autonomous)

So I think the answer to my question is ‘yes’… so let’s drill down on that - what does not work?

-Pascal

Immediate access to the geometry and it’s layers and groups for editing of surfaces and render material re-assignment and immediate visual confirmation of the block base point and without the scaling “gotcha” limitations as presented in the other bug thread.

PS. When I say geometry and it’s “layers” it could be as simple as a main layer and two sublayers. If the layer structure gets too complex, then yeah, I’ll likely move it to its own Rhino home file.