V5 RS9 Layer Bug?

Rhino Rhino for Windows
12

In the stripped down file I uploaded, the 3 (approximation of) nuts, can be shut off from two non-nested layers.

As much as you may try to move them, they will continue to respond in this fashion.

I sometimes make groups of instances; I wonder if that might be causing Rhino to get confused. It still looks like a bug to me.

I am considering moving everything onto one layer except for work and construction layers, but what am I going to tell people–that Rhino blocks are klunky to use or bugged?

What I want: to create a block, and then it basically be global, like a global variable, and then I want to be able to spawn an (local) instance on any layer from that (global) geometry that I can move to any layer I want.

I have also had problems with external file blocks that make me want to distrust them, though I want to experiment with them for making blueprints.

[BTW, my project is basically a grounds-keeping machine, which has around: 966 block instances, 20 extrusions, 103 points, 97 curves, 175 polysurfaces, 17 surfaces, 1 linear dimension. I have tried to keep good organization in this project. Perhaps I can distort/adulterate the file dimention-wise so that it could be studied.]

13

Yes, so what you’re asking for aren’t “blocks” as Rhino or the CAD programs Rhino can transfer blocks between knows them.

What you could do is maybe place the source geometry for your blocks on a different layer from anything else, that way you can put the instances on whatever layer you want and their visiblity/etc won’t be changed by turning off some other layer that you’re working on. It’s not really disturbing that geometry in blocks can be turned off according to two layers, blocks are an alternate form of organization that can cut across layer relationships, and again as I don’t think you’re getting it an instance of a block is NOT a piece of geometry, it’s an invisible…I won’t even call it a container, it’s a pointer to the geometry in the definition, nothing to you do a block instance directly impacts it.

14

When a block is defined, I want:
1.) The source geometry stored globally irrespective of any layer constraint.
2.) The source geometry removed, perhaps with an option to keep the original.
3.) The source geometry replaced with an instance on that current layer, for convenience.

I want instances to have the ability to be moved to any layer–without editing the source.

I want to be able to group blocks to form things such as a group of nuts and bolts, whereas a nut or bolt may be block instances that are irregular enough not to justify the creation of an additional block definition.

As if it matters: what I have learned working on moderate-large projects:
1.) I deal with systems instead of areas.
2.) I hide areas I am not working on, which why I years ago requested something akin to the “Invert Hide” which was from GTK Radient’s “Region” command.
3.) I never have applied materials by layer, but by object, which become parts of larger systems.
4.) I make 2D work layers, for not only wireframes, but curves which describe not only the constraints of the part, but also the interaction between that part and others.
5.) I make 3D construction/workup layers for 3D workflow for operations such as filleting and some binary operations, so I can go back if I want. (Generally, I wish we could record history on a 2D or 3D fillet, and unfillet it)
6.) I use the incremental save so often, I wish it had another decimal place.
7.) I am constantly using the “Visibility” pallet, which I have added locking, and zoomselected so I can center my work.
8.) I find that I like drawing in snap-referenced 3D rather than using construction planes. It could be said that I draw in absolute, rather than relatives.
9.) When going for accuracy, I try not to adulterate parts by translations. In other words, I would rather create a hidden copy or a block and rotate the instance, knowing that I can spawn a never-translated part.

[Etc… No, I would rather not explode a polysurface to apply different materials to it’s surfaces, because I would rather not degrade accuracy for presentation. I wish we had per-surface materialing on polysurfaces.
I’ve spent enough time reworking and untrimming polsysurfaces to consider starting a tread of “Valid Polysurfaces that can be Exploded, but not re-solid’ed.” I wonder if the trim/winding order could be saved with a dirty/modified boolean indicator?]

15

I am at a loss now, because I am facing the prospect of re-blocking everything on the default layer; this is suboptimal : (

16

I’m not sure what this means. Objects in Rhino exist on a layer. You can edit a block (BlockEdit) and move the parts to any layer you like, and you can move any instance to any layer you like.

Again, I don’t know what this means- when you create a block using the block command, the things that you selected to go in the block are removed/replaced with the block instance. Isn’t that what you are asking for?
See if this page helps clarify how these work: Using Blocks [McNeel Wiki]

-Pascal

17

Hi Brenda,

to achieve the spawning behavior you are looking for try:

  1. Make the block (if it did not exist before)
  2. Enter the block  by double clicking on it
  3. Put everything in the block on the default layer or a layer called 0 (this is for example an AutoCAD convention). This layer has to always stay on.
  4. Change all the object properties (display color, print color, line type, print width, material, etc.) to By Parent.

This will make the objects in the block inherit all the properties of the their parent.

In case you have to modify an existing file with many blocks and if you have some scripting knowledge you can make scripts for all the repetitive tasks in step 3 and 4. Otherwise use the above as a best practice for working with blocks if you want them to inherit properties.

Hope this helps.

18

Sivano, thank you.

If wanted Autocad, I would buy (wretch) Autocad. I don’t want everything on a layer called “zero” ; it’s neither contextual nor human named.

Also, I am looking at 1,500 objects, I am drawing the kind of machine that makes my 2600k and GTX 570 a little gummy to rotate, so I shut off layers I am not using.

I material by object. I am making things of other things, which are divided into understandable systems. The parts of these systems have varying presentation. (My final outputs are a monochrome drawings and material’ed renders.)

Pascal. I have always appreciated your input.

Having a block instances locked to a particular layer robs me of the very interactivity I bought Rhino for, and recommend it to others : )

Anyway, to change a layer of a fastener, I had to ungroup it, blockedit it, regroup it.

Unfortunately, Rhino doesn’t know that I have blocks on the “Set” layer. If I tell it to select everything on that layer, it doesn’t. The Block Manager UI isn’t aware of what layer anything is on. So, to put everything right, I have to click on and off layers, visually checking to see which objects disappear and reappear, and those I have to change.

It’s just not a feature but a limitation that block instances must live on the layer they were created/spawed on. It can be done better.

19

Hi Brenda- I understand that blocks may not work the way you want them to, but so far nothing you’ve described is a bug, that I can see. If you have not, please do read the Using Blocks page that I posted earlier and, while it may take a bit more planning and understanding than you like, I bet you’ll be able to use blocks more ‘smoothly’. And, BTW, what is the use you are making of block?. what problem is it that you’re trying to solve with Blocks?

thanks,

-Pascal

20

Hi Pascal,

I make blocks of:
1.) Fasteners
2.) Duplicate objects, especially complicated ones with high meshing or memory demands, such as threaded parts, which I do have some in my project, aside from the place holder fasteners.

(…which brings to mind, I wish we had imposters, which could be swapped in the Block Manager. In other words, with a single click, I wish we could have a simple part that could be substituted for a complicated one, or a outline of a part that could be swapped for a finished one.)

I use blocks for:
1.) Global replacement and organization
2.) Rendering mesh reduction
3.) Memory size conservation. I am at 644,832k after meshing, with nothing in the cut/paste buffer.
4.) Smaller file sizes. My project saved small is still 36.5 MB using extrusions wherever I can.
5.) Occasionally, I define a block to preserve a non-translated non-adulterated, thereby more accurate version of a part, when I am going to be doing things such as rotating an object. It would seem that spawning a fresh instance of an object would be totally free from floating point degradation from translations.

As far as the layers, I might want a washer attached to a hydraulic system or holding some plate on. It seems logical that the user should be able to put a block instance on any layer they choose. I feel that it’s inconsistent that the user can throw any other object on any layer they want, but not a block instance; they are special things with special limitations.

I am kind of down because I may resort to moving every block to the default layer, which means that I can no longer hide systems with a single click.

21

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 : )

22

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

23

(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 : )

24

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.

25

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

-Pascal

26

[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.]

27

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.

28

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.

29

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.

30

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.

31

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