V5 RS9 Layer Bug?

Perhaps if the Layer Manager were more powerful, it could do the equivalent of a block-edit, change-layer, but this does not solve for the case where a user might want to place instances on two different layers to associate it with two different systems or associated parts.

I have used Rhino : )

This is incorrect. As outlined on Using Blocks [McNeel Wiki], block instances are like any other object in that respect they can be put on any layer you like, The underlyiing objects in the block definition may exist on other layers, or indeed in other files (which is probably the best way to do things if you have a set of stock parts) however.

Block manager will let you swap out simple for complex block definitions most easily by pointing the block definition to a different external file.

-Pascal

(Cross my heart) The only way I that worked to change the layer of those nut instances is by doing a _BlockEdit on it. You can try it with the file I uploaded.

Additionally, from the Rhino:Using Blocks, “if a block definition uses the layer you cannot delete it.” So it seems locked or associated to a particular layer.

What I meant was, it would be cool if the block manager could alternate/switch between two objects with a single click : )

Hmm, yeah that’s not unexpected, and not new. You’re still not understanding what Pascal has explained, you’re not getting what blocks are. A “block instance” is NOT a piece of geometry, it’s an invisible box–maybe a window is a better analogy?–on some bunch of geometry. So what “window” can be moved from layer to layer, if you turn that layer off then the window is closed, if you turn off the layer some of the geometry in the definition is on, the geometry also disappears. The layer the “window” is on doesn’t affect anything about the geometry on the other side (unless you have certain properties set to “by parent” as was explained above.) If you want to have different instances of the same block look different, then you can use the method described above about the “by parent” property, or more likely you should rethink that since it’s not necessary to do the organization you’re trying to do and not necessarily a great idea to have parts that are in fact the same look different.

Correct- a block definition necessarily has objects on specific layers; a block instance can be, itself, on any layer.

-Pascal

[Jim, I was suggesting a useful feature, which I shouldn’t have done in this thread.]

Respectfully, I suggest that in the name of usability block functioning could be better and should be changed in Rhino.

A block definition would be most useful if were a layer-less group of entities that describe an instance to later be inserted.

Those instances should be able to happily live on any layer, or could be copied or moved, or inserted on many layers–without editing the block.

I don’t think that an actual block definition should have any layer associated with it at all.

Once it’s created, it shouldn’t need a layer.

You want to edit a block? Insert one on any layer, edit it, reblock it, or insert it, and block edit it.

[I have about 90 Internal block definitions in my project.]

I am block-editing most of my blocks to move them the “default” layer. Having to do a blockedit every time I want to change the creation layer is too laborious.

There is no advantage to having anything related to a block definition linked to a layer. I want the freedom to be able to move the instances wherever I want, and you can, but there is still a remanent rooted on its creation layer, to what advantage, I can only wonder.

In the block manager, I found that nesting fastener blocks meant that getting a simple count was too hard because I could not easily discern my root objects from the UI, so I replaced every fastener with groups of blocks. That way I only my physical fasteners showed, and those can easily be counted, like this partial list.

Block Name, Top Level, Nested, Total
Fastener #12 Bolt x 3/4, 16, 0, 16
Fastener #12 Bolt x 5/8, 16, 0, 16
Fastener #12 Nut-Keps, 32, 0, 32
Fastener #12 Washer, 32, 0, 32
Fastener 1/2 Button-Washer, 14, 0, 14
Fastener 1/4 Washer, 86, 0, 86
Fastener 1/4 Washer-Lock, 4, 0, 4
Fastener 1/4-28 Bolt x 1-1/16, 4, 0, 4
Fastener 1/4-28 Bolt x 1/2, 74, 0, 74
Fastener 1/4-28 Bolt x 5/8, 4, 0, 4
Fastener 1/4-28 Nut, 4, 0, 4

If there was a tree view in the block manager that showed nesting that would be sweet.

But you can. This has been explained to you.

What happens when you want to make one of your pseudo-blocks of a complex part with more than one layer? Everything gets dumped on to one layer? That’s going to be a feature with pretty limited appeal. People Block entire finished assemblies, not just individual nuts and bolts. You’re focusing on the most basic boring possible use for blocks and want a new feature that’s limited to that one task.

As I said, I don’t want the definition to be associated on any layer–only the instances; I want the definition to live in a space where it doesn’t have to beholden to any layer impediments.

I am dismayed at the functioning of blocks, but I can’t keep editing blocks when I want to change their layers for keeps.

I agree, by not nesting blocks, I am not under-utilizing their functionality and wasting RAM, but I need a simple way to get a BOM of all my fasteners and such.

Respectfully, when I nest objects the Block Manager UI I can’t get a good count of them, without crawling the tree by interrogation, and adding those numbers. When the blocks are flat, I can get a good list.

I would like to get some input from users who have made complicated drawings on this.

Jim,

What bothers me, and may be part of Brenda’s complaint, is the requirement to keep the layer holding the block definition turned on to maintain visibility of instances of that block, regardless of the layer the instances reside on, and regardless of the layers the original geometry included in the block reside on.

Silvano’s explanation of how to use properties by parent was very helpful, and I now see how to make blocks work better for me in terms of them deriving properties from the layer an instance resides upon (thank you, Silvano!). However, I still have all those embeded block definitions on layer 0 cluttering up my workspace, and I can’t just turn off that layer or all the instances go as well. I can of course hide or delete the original geometry, but I still can’t turn off the layer it is/was on.

Is there a technical reason the layer with the definition must remain on, or is that a design decision for the user interface?

When Brenda refers to “having block instances locked to a particular layer”, I think she means that no matter what layer you move the instance to, it still cannot exist without the definition layer remaining present and on.

Hi Brenda

Re feedback on making complicated stuff - you post you are designing / modelling a ground keeping machine.
I currently am designing and building powerchairs, - the files for laser cutting, water jet cutting and folding are taken from the 3D model, plus there is a full 2D dimensioned set of paperwork that goes with it.
I wonder why you are bothering to model all the fasteners and nuts and bolts?
I never bother; I just make the holes the right size, and make sure all the components line up. Even for rendering / visualisation, I don’t think its necessary to do that, since generally they are so small.
I started to tag all the holes with notes of the required bolts etc, but I stopped doing it, since in the real world, it was pretty obvious after I’d gone through the whole design process where all those things fit, and approx what amount I’d want …
For this project I am not using blocks at all, since there really arn’t many items the same…
However, wearing a different hat, I use blocks extensively when lighting a show - there they are essential since it is critical to know how many instances of different instruments are being used, replace some with others and so on.
Rhino’s blocks are like they are because autocad and every other CAD system I’ve ever worked with use the same system - if they didn’t, it would be extremely difficult to interchange data; and in fact even so, blocks, along with dimensions and line types, are usually the first casualties when exchanging data among different systems.
Sure rhinos block manager could be better, and stuff could be tidied up, but the basic way blocks work will remain as it is for the above very good reason.
I would suggest, since all CAD systems , as far as I know, use the same concept, and since therefore you cant beat the system, that you take a day or so to “sharpen the axe” and fool around on a few test files, till you totally get it. Even use a different program - for example sketchup which is a free download, handles blocks (which they call components) pretty well, but underneath its the same thing.
And secondly, maybe look at really how complicated (ie in how much detail) you really need to model? Is it really necessary and helpful to model every last washer etc, when these things are all standard boring stuff that everyone gets - it’s the things specific to your design, and the way those parts interact etc that is the important stuff…
Anyway, just sayin - that’s how it works for me…

Cheers
rabbit

Hi Rabbit,

I originally only stuck nuts on the ends of connections. Now, I model bolts, but with no threads. I can have a count of each bolt type, make sure they are the right length, and be sure nothing hits anything else. Oddly, the addition of bolt stems gives a clearer picture in Ghosted view.

My basic bolt block is an extruded hexagon, a cylinder with a small chamfer on the end to for engagement, and two points. To create different lengths, I insert a copy of the geometry, and Solidptson to drag the chamfered end, block it to a new name. Using two points helps with rotations, as well as alignment. The Keps-Nut washer was a fun extravagance, but they are meshed low-poly, and look good in renders. Shh, I like doing cad.

@Mark

The reason to keep the layer holding the block definition turned on allows to work with blocks in different ways.

The first scenario is the one I described above, where the objects inside the block are all set to by parent, receive their properties from the layer the block instance is put on and the layer they reside on should be some default layer, that always stays on.

The second scenario is where you have more sophisticated block geometry, that also should reside on different layers itself (not only a 0 or default layer). This might be useful if you have e.g. construction lines that you would like to keep but not show while using the instances of the block. Or you can have different types of block geometry, e.g. simple (only lines) and complex (surfaces, polysurfaces), each on its own layer. This would allow you to switch on the simple geometry layer for instancing the block and switch on the full, complex geometry layer only for viz or collision checking.

There are many more scenarios where layers inside blocks are useful, even mixed ones besides the two I mentioned here.

I hope this gives a better idea of why layers inside blocks can be useful.

A good best practice is to use only specific layers for block geometry and prefix their names with something that hints at a block geometry layer. Additionally you can group all block geometry layers in the layer manager.

The user cannot delete a layer without finding out which objects, which may may not not still live on their creation layer, are individually blockedited and changed.

We still have one vote against block definitions being linked to a creation layer.