Blocks & updating

Hi there, I often find I have multiple instances of the same component in a drawing and wondered if there is a way of setting up a drawing so that all instances are updated when one is modified. I thought Blocks would do this but apparently not, unless I’m mistaken ?


@inukX Instead of updating the block, maybe you would like to give History a try… Just activate History, then the copied objects (child objects) should automatically update after the original one (parent) is altered.

They will, but it’s a bit complicated… When you create the block originally, the actual geometric components (curves, surfaces, etc.) are destroyed and replaced by a block definition. You then copy that block definition around where needed. The problem becomes when you want to modify the originals… they’re not there anymore! Only the definition exists in the file (a rather abstract concept).

In Windows Rhino you have the BlockEdit command which sort of re-creates the geometry in order for you to edit it, then redefines the block with it. Although still rather clunky, it’s much better than what was possible previously. Hopefully all of block handling and editing will improve soon, there are a couple of threads on that running here currently.

Unfortunately, BlockEdit does not yet exist in Mac Rhino. :confounded: So, you will need to go back to the old system:

  1. Pick one of the block instances (easiest if you know where the
    original was and use that), and use Explode to turn it back into
    "real" geometry.
  2. Modify the objects as needed
  3. Select the modified objects and call the Block command, give it the
    same insertion point as before and THE SAME BLOCK NAME. It will
    tell you the block already exists and ask you if you want to replace it,
    answer yes.
  4. All the other block instances (your copies) with the same name should update.

HTH, --Mitch

1 Like

This is one of the improvement items. Ideally something like this would occur:
_one could select the block name and the first instance placed would be highlighted.
_edit block would automate the exploding of geometry.
_if no instance has been placed, editing would open this geometry in it’s own Rhino file.
_when done editing, routine should have an “update block definition”, with option to retain the old copy (if desired) with “Old-01” appended to block name.
_block would then update, auto-populating where placed (or closing new window if not placed) keeping the same name, while showing last saved time.

Could possible integrate versions of some kind in the block file instead of retaining old copies with different names?

Other improvements? ~Dave

Brenda has taken the lead on that one…

1 Like

Thanks for the suggestions ! I’ll try both out and see how it goes.

Well, I’ve arrived at the point that I need to modify a block element. What progress has been made on this?

I like Dave’ suggestions, and this brings to mind my recent need to do some boolean work with a block only to find the bloke is really just a story being told with the drawing and there’s no ‘existing’ geometry to manipulate.

To do a boolean subtraction requires one to explode a block into actual geometry, copy said geometry to the clipboard, command-z back to restore the blocks, paste copy of exploded geometry in place, and then do a boolean operation.

A bit tedious.

The question here is why do you really need blocks in this case? Blocks are good for representing many repetitive elements based on one definition that you can place where you want and update all simultaneously. Blocks are not good for representing individual elements that you are going use to interact with other geometry. The main purpose of blocks is to save file size when you have a lot of the same object, and/or to allow updatable instancing. If you don’t need either one of those, you don’t need blocks.

To modify a block element, just explode it, modify it and then re-define it as a block with the same name as the original. In Windows Rhino you can actually (partially) edit blocks through the BlockEdit command (not available yet on Mac.)


I got in the habit of using blocks to keep file sizes as low as possible. Just an all round good policy I think. It may not be of much use here, but it’s sort of like using a turn signal even when there’s none to see it. A good habit.

Not necessarily if it actually hinders your workflow instead of helping it. Sort of like sticking your hand out the car window to make hand signals instead of using your turn signal. :stuck_out_tongue_winking_eye:


Well, sorta but not really. If I can build something once and populate it throughout a model as needed, then I don’t see why it would be a waste of time. It may take an upfront effort, but later when the inevitable design changes take place, I’ll be able to leverage the effort to make changes quick and complete. The block system as it is does not seem very well done. I say that as I’ve had to blow up a block to make an edit, reselect the elements and make a replacement block. Afterwards, all the instances have moved and I have to re place them. In other programs, one can make global edits to any instance on any layer and have all the copies change immediately. This functionality is a major assets to work flow - especially down the production line.

Hi James - before you edit a block to redefine it, use ExtractPt to place a point object at the instance insertion point - then, when you redefine the block, snap the new insertion point to the point object - your other instances should now stay put. BlockEdit will save you this trouble, whern it arrives for Rhino for Mac.


1 Like

So when I select an instance to edit, place a point say at one of it’s corners? So far, I’ve made blocks and simply typed in a zero for the insertion point.

Often, when making objects which are blocked, I usually make them where the part would live and leave the shapes that create them right there…

But for some trivial objects which may be moved a lot, I sometimes even include the wireframe curves that make up the 3D or even a 3D object used for binary operations. If I need to mess with the object, I explode it, and work on it, and re block it.

[I generally include lots of points in my blocks for alignment, and always include a point where the insertion point(handle) would be. That way if you need to reblock it, you will know where the insertion point was last time, so that all the other careful insertions and 3D translations aren’t irrovokably #ucked.

Although grouping is lost when an object is blocked, most everything else is retrievable, and unfortunately: the creation layer.

Thanks for the mention Helvetasaur.

1 Like

All I am suggesting is that you mark the insertion point before you explode and edit the block instance so that your other instances do not move around when you re-block. ExtractPt will do this.


1 Like

You can try to use inserting another file into the main 3dm file as a block, and copying this block inside the main file around.

When the block needs to be edited, you just edit the .3dm file (which was inserted as block) and update the block definitions in the main file with the Blockmanager command,

you get this afterwards:


1 Like