Block layer can't be changed

Rhino Rhino for Mac
1

when creating instances of blocks, they get created in the layer in which they were created. you dont seem to be able to move or copy the instances to another layer (which is a pretty clear bug)

2

I’ve been bitten by this many times. Do any old Rhino hands have a strategy for block management that makes them easier to deal with?

Anomalous, my only way to’ resolve’ the issue has been to make a new block on the intended destination layer (or a designated block definitions layer) and replace the original with my new one. Still, I agree with you that’s it’s not desired behavior.

3

If the objects referenced in the instance were all on different layers, then it wouldn’t be a block.
That’s the current behavior. A block is a named combination of objects that exist in the file. Objects exist on layers. They are on they layer you created them on. The instance just points back to that single definition.
The block insertion point is the only thing created when instancing or inserting a block and that invisible point DOES EXIST on the layer current at the time.

You can edit the block definition and change the object layers. Then all instances that point back to the block will reflect those changes. If you want one instance to have the objects on one layer and another instance to be on another layer, then they can’t be the same block. YOu can have as many block definitions as you want.

4

Perhaps I should ask instead, is what problem are you trying to solve? It sounds like the Block command is ill suited to that need. Maybe there is something better.

5

the objects that make up the block existed originall all in one layer. for example, in this case, the block is a complex door. I need to be able to use this block on multiple layers (eg on different floors of a building, each of which is a layer with sublayers). I’m using a block because the design of the door details is not entirely fixed, and I’d like to just be able to make changes in one place - ie the block definitiion, and have this update all the instances throughout the building.

I come from a background in solidworks, where this kind of thing is the norm, so assumed this was how blocks worked in rhino.

cheers

Ben

6

OK, thanks. That helps.
In this case, because of they way they are created and managed in Rhino, you’ll probably have to have different blocks for the different floors.

If it’s just the display color you want to change, then you could set the display color of the objects within the block definition to “By Parent” so they would take on the the appearance of the layer the insertion point is on. You could use BlockEdit to change that object property.

7

Thanks John.

Its not the colour, its the fact that design details are still changing (dimensions of particular features on the doors, for example). originally I just had the doors as copies of a set of grouped objects, which was fine until i had to change something, at which point i had to then manually replace all the old versions with the new version. This was what I was hoping blocks would address. if this is not the purpose of a block definition, I’m not sure what benefit it really has (other than maybe a bit of memory saved)

8

I am not getting a clear picture of the problem. Will all the doors on all the floors be the same? Do the component parts of the block need to end up on different layers like maybe, handle, frame, door, glass? Are these names different for each floor, like floor1-handle, floor1-frame…? Do the doors go on different layers on each floor? It seems to me that the problem you are trying to solve can be exactly solved with blocks, but I don’t have quite enough detail to make a recommendation.

9

What you’re describing about blocks IS what they’re for.
I’m not clear on why it isn’t working for you in this case.
If it just visibility, then place the insertion point of the door blocks on a layer that corresponds to that floor. Then when that layer goes on and off, the door blocks will not display either, even though the layers the entities are drawn on are not turned off. By turning off the layer the reference point is on, then the block does not display.
Is this all you’re after?

10

When I need to do this, I set up layers something like the following:

Common
    Com_Doors
        Door_Jamb
        Door_Slab
        Door_Hardware
        Door_Lite

1stFloor
    1st_Walls
    1st_Doors
    1st_Windows
2ndFloor
     2nd_Walls
     2nd_Doors
     2nd_Windows

Build the door (the geometry to be blocked) on the Com_Doors and its sublayers as needed, then block it. When you insert the door, insert it on the appropriate layer, such as 1st_Doors. This way when you turn off the 1st floor, the doors on that floor will turn off as well, the doors on 2ndFloor will say on. Conversely if you need to turn off all the door hardware on all doors for all floors, you can turn off the Door_Hardware layer.

Hope that helps,
Sam

–EDIT–
I just realized this is under Rhino for Mac, so I don’t know if this behavior is the same on the Mac side, but that is how it works on the Windows side.

11

OK, what both Sam and John described above is the behaviour I’m looking for. Its just not what happens on Rhino for Mac.

I just tested it as follows:

  1. start with empty rhino file.
  2. draw two boxes on Layer 1
  3. select both boxes, and turn them into a block. (ie Create block definition from selected geometry)
  4. now activate another layer as your working layer. (eg Layer 2)
  5. Create a block instance on that layer (Layer 2)

if what you have been saying is correct, when I toggle the visibility of layer 2 off, the block should be hidden - but it isnt. it stays visible. if instead I toggle the visibility of layer 1 off, now it disappears.

so it seems that all block instances are tied (or at least their visibility is tied) to the layer on which the block was first defined, NOT the layer on which it was inserted (which is how you describe it working in windows)

I’ll try it on a windows machine next chance I get and see what happens.

cheers,

Ben

12

tested the exact same thing it under windows, and it works the way it should.

same thing under mac doesnt work, as I described above

13

Creating Layer 2 is not enough. Before you insert the Block, you need to make layer 2 the ‘current’ layer. New objects are place on the current layer.

Or you can select the existing block instance and change the layer it’s on to Layer 2 in the object Properties panel.

14

Hi,

I’m reviving this topic because I’m having the same issue as anomalous.

If you:

  1. create a block definition on layer 1
  2. create a new layer called layer 2 and select it as your ‘current layer’
  3. ‘Insert’ the same block definition you made in layer 1…

You would hope that it would insert into layer 2 (which is selected as the current working layer). But it DOES NOT. It inserts instead into layer 1 or whatever layer it was originally created in.

I 100% agree with all of Ben/anomalous’ issues and assertions and also think this may be a bug specific to the mac system.

Please help!

Best,

David

15

I need to be a little more specific here:

  • When you insert a block created on layer 1 into layer 2, it DOES insert into layer 2 (I confirmed this by checking in the object properties window)
  • However, if you then turn the visibility of layer 1 OFF, the block (on layer 2) disappears
  • The block will also disappear if you turn off the visibility of layer 2

This has got to be a bug. Why would you possibly want an object or block to be in one layer and have its visibility controlled by another layer its not in?

Best,

David

16

That’s correct, that’s NOT a bug :wink:
The layer on which you insert a block will control the visibility of the block. The layer on which you create an object will control the visibility of the object.

In your example, the object(s) in the block (and also the first instance of the block) reside on layer 1 whereas the second instance of the block is resides on layer 2. Turning off any of those consequently turns off the visibility of the second instance.

17

wim,

Thanks for the quick reply. OK, I see what you mean, but I’m not sure what the benefit of this is. If I create a block on one layer, then yes, I want that layer’s visibility to control the visibility of that block. But if I take that same block and insert a new instance of it into another layer, then I want THAT layer to control the visibility of THAT instance. Does that not make sense?

To go back to SamPage’s previous example, lets say you have a door block on a layer called “Com_Doors”. You design your door on that layer, made up of lots of different objects, and then you block it when you’re done. Then, you go and insert it everywhere you need to in your building, on layer “1stFloor”, layer “2ndFloor”, etc. Then, you will want to turn OFF the “Com_Doors” layer because that’s just a layer you used for the construction of your base door block. In Rhino for Mac, if what you are saying is true and this is the intended function, turning off the visibility of “Com_Doors” would hide ALL of the door blocks that you inserted on all the floors.

Why not just have the visibility of blocks be controlled by the layer each instance is actually on???

-David

18

The way I think of it is that the block definition contains both the geometry and the layers of the geometry. The instances can be placed on unrelated layers. This allows you to turn off the doors in the entire building or allows you to only work on one floor at a time - and still seeing the doors on that floor.

Note that while I see the theoretical advantages of using blocks, I’m not actually thrill-seeking enough to start using them in real life :wink:

19

wim,

Ah! Your reply just gave me an idea of how to create the functionality desired in the door/building example! I just tried it and it works.

  • I create a layer called “Doors”
  • I build the geometry for my door on that layer and then block it and call it “door”
  • Then I insert new block instances of “door” onto different layers in my model (“1st floor”, “2nd floor”, etc.)
  • Then (and here is the difference) I DELETE the original block instance from the layer “Doors”. So now, there’s absolutely no geometry on that layer, but if I toggle the visibility, it will turn on and off the “door” instances I have placed on other layers!

This is actually great because, as you said, I now have the control to toggle on all the doors in the building with one click, or I can toggle entire floors on and off. I also successfully exploded one of the secondary instances, changed the geometry, and then blocked it again, overwriting the original, and all the other instance on different layers updated. Yes!!!

I’ve been using Rhino for a while, but I just started using blocks. I really want to use them because I can see how powerful of a tool they can be, but they really take some getting used to. Thanks for your help.

Sorry I threw the word “bug” out there originally. I didn’t mean to insult anyone. You guys have done a great job developing this program – I love it!

Best,

David

20

This isn’t quite accurate.
Your “Door” block definition is on layer Door. It’s not visible because it’s a block definition and you deleted the INSTANCE of the block that was created. Block instances need an insertion point on a visible layer to be show.
If you delete layer Door, the block definition will be lost and all instances of the block on all layers will be gone too.