I am seeing strange behavior in SR9 whereas:
I have an object set on one layer, and when I shut off an unrelated layer, the object is also switched off.
I can shut off the same object with two different top level layers.
Hi Brenda, can you post a file containing this object ? Is your object a Block ?
c.
I tried turning on all the layers and cut and past to a new document, and the problem exists in the new document.
There are many blocks and many layers, and Rhino seems quite confused, whereas it wasn’t before. Still, the behavior is quite odd. As soon as I can, I will try to pare down the file so it can be sent.
The sample file is pretty sparse; there are only a few nut-washer blocks and some lights.
When you shut off the “fastener” layer, the fasteners go off.
When you shut off the “set” layer, the fasteners also go off, yet they are not nested.
Bolt Set.3dm (483.9 KB)
The funny thing is: my entire document cut-past experiment did not fix the problem.
The actual file has hundreds of hours of work in it for a friend’s groundkeeping machine : \
**I just noticed the “One Layer On” option in the layer palette, did that addition break something in the build?
It’s almost like Rhino thinks that “Fastener” is a child-layer of “Set.”
Hi Brenda,
While the “blocks” are on the “fastener” layer, the actual geometry contained by the blocks remains on whichever layer it was made on, in this case the “set” layer, so turning off either layer will hide them. This is not new.
Hi Jim,
I have always hated that behavior because it inhibits organization, but:
1.) The fasteners weren’t created on "Set"
2.) Turning off “Fasteners” should not also shut off the parts.
It’s still a bug, well a bug and a dis-feature.
For the first time, I can’t work on and I am afraid to do anything with my largest Rhino project. Please fix this.
Well some random bug is not going to move the stuff in the blocks to a different layer, you edited them somehow.
And it absolutely makes sense for turning off the layer on which the block definition itself, which is an invisible container, resides to hide all the pieces of the block whatever Layer they are on. It can get aggravatingly complex in real life but the logic is fine. Otherwise you’d have no way to hide/lock blocks in one step but at the (block) object or block defimition level, their utility would be greatly reduced.
Who does exist on two different non-nested layers at once?
BTW, the ability to move a block from layer to layer lets us organize our projects.
Additionally, with a project with many parts as I have, it becomes a necessity to stay organized because things get slow with a lot of objects showing, even with my aging yet capable 2600k/16GBRAM/GTX570.
I don’t like the idea of reblock’ing an object to change its layer because there is always the chance to change it in a slight way. I tend to include points for alignment purposes–especially on non-cube shaped objects or objects such as fasteners that are aligned by circular areas, because sometimes the original central point may be more accurate than a calculated center. Though using that technique, I have a block with more than one point, and one of those points is the block handle, and the others are not.
We still have a bug or bad UI decision here as sure as there are objects on two layers.
Objects aren’t on two layers. What’s on one layer is the geometry that’s part of the block, on the other layer is the invisible container for that geometry, that’s the actual “block.” You can move that invisible “block” from layer to layer for organization, but the geometry inside doesn’t change layer(s), it can contain any number of objects on any number of layers, so what’s it going to do, dump everything onto one layer? That would screw up all sorts of properties.
From a usability standpoint I strongly feel that blocks should be layer independent, while instances should live wherever your spawn or move them. The current setup is the second worse user interface design decision in Rhino.
[The first was the usability regression where since V5 Rhino doesn’t remember that a user may apply materials by object instead of layer. I have had to hit that drop-down box hundreds of times.]
I want those few things changed that might inhibit Rhino from obtaining its rightful place as the “Photoshop of 3D programs.” : )
But instances of blocks do belong to whatever layer you create them on or move them to. That’s what you’re missing, a block instance is NOT the geometry, it’s the “block” object that just sorta coincidentally looks like the geometry in the definition.
Having all the actual ‘stuff’’ inside the block move to the block’s layer is simply a no-go, people put complex assemblies with many layers inside blocks, and other CAD systems Rhino communicates with use blocks the same way. They can certainly get confusing especially when you start nesting blocks, but what you’re asking for is something different.
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.]
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.
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?]
I am at a loss now, because I am facing the prospect of re-blocking everything on the default layer; this is suboptimal : (
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
Hi Brenda,
to achieve the spawning behavior you are looking for try:
- Make the block (if it did not exist before)
- Enter the block by double clicking on it
- 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.
- 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.
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.
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
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.