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
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.
Because, for me, all instances are at the same level (and this is the way they have to be).
The embedded “parent” is in the file but none of the instances have this title.
Also, I don’t want to have different way to manage linked o embedded blocks.
I like the double click to enter edit block and that I can edit any of the instances and after that the others are updated.
I agree that all the block “managing” system has to be more user friendly.
Cheers.
But how is the proposal different ? Are groups also special citizens that should also be in a separate space ?
a) If a block is Linked and you double-click it you get a new Rhino file to open where all the geometry, groups and layers are in full view.
b) If a block is embedded within its own file, I want to also see all its geometry layers and groups the same way.
The rule is simple: “Keep parents as geometry in their own source files” for immediate access. So if they are embedded they remain visible as geometry in some layer. Just give me a visual cue (like a dotted cage) to remind me that this geometry is instanced somewhere in the file.
A few tips:
Wishes from my side:
Thanks!
I really like this idea. It seems like the panel could allow “unlocking” of a block so elements in the block could be edited or having buttons to add/remove geometry from a block.
No, they only need a group manager because, at the monent, groups are something invisible that is difficult to manage (we can have nested groups and there’s no way to manage them quickly).
But this is another thing that i wished a lot of time ago…
Let’s go back to blockedit.
At the moment,when you enter in blockedit mode, the instance you double clicked is isolated from the model.
In this mode you can select all the parts and see in the object properties the layer and other properties like when you are working on the model.
The only thing that could be useful would be to isolate the instance and hide all the other geometries to have a better view of the block.
Another way would be to open a new floating viewport with the block isolated and cplane centered with insert point.
I would agree with a better edit block mode but not to have a parent block that is in some place in the model and that have this super power to destroy everything or to make a mess…
I use blocks for screws, bolts, nuts all the things that you buy and put in the project (all things that have a standard shape and that I don’t need to modify); also, I use blocks for my laser cutting scripts.
Only to explain what i do with blocks.
Hi Steve, glad to hear that.
I think that many users don’t use blocks because they are “hided”, a panel could be more helpful to start using them.
@pascal Wait a second. I didn’t know you can perform viewport operations outside the Block edit dialog. With other dialogs (like options) the Rhino screen freezes. The user is conditioned to keep their focus within the dialog and constrain only to the buttons given to them.
Hi Thomas - - all Rhino commands should work inside of BlockEdit.
-Pascal