This must be a stupid question, because I’m sure its not an error but intentional.
I just cant figure out how the layers work.
1 - I create a new layer
2 - I create objects on it
3 - later I change my mind and I want to move an object from that layer to another one
4 - so I create a new layer somewhere else in the layer-tree
5 - I select the object, then I select the wanted new layer, right-click + “Change Object Layer” will put the object on the new layer, fine.
6 - but actually the object is still on the original layer also, I didn’t MOVE the object to the new layer but rather COPIED or something like that, I can check this with the little yellow bulbs (toggle-visibility) , if I switch it off on the original layer, the object will disappear. Also, if I want to delete the original layer, it would delete the object also, after a warning of course, but it deletes the object from both layers, it won’t exist anymore on any layer.
Ergo the object has multiple layers the original and the new one too, it belongs to both. This is fine in many cases its very usefull, because I can group the layers by many various way, for example I can disable that object as part of nuts&bolt in general or as part of a specific named gearbox.
But sometimes this behavior is not wanted and I want to move the object indeed, I don’t want multiple layers.
How can I do that ?
Plus question : what does “Copy Objects To Layer” command mean if actually “Change Object Layer” does do the same, it copies object and doesn’t move.
Normally Change Object Layer does not copy the object, only moves it to a different layer. Something else must be happening here. Are your objects blocks?
Block instances yes. Block definitions don’t have a layer at all, only the objects in the definitions have a layer (could be multiple layers with multiple objects). So you would have to edit the block definition and change the layers of some or all of the objects that make it up.
OK. But what if the block definition objects were deleted, can the block still be edited, for example by applying changes to an instance, and then (re)define the modification with the same block name?
Yes they are, is that a problem ?
Because if it can copy the instance to another layer, then it should be able to remove it from the original one.
Or just simply move all selected things to another layer. If it wants the keep the layer structure of the block definition, I don’t mind. But I can’t see why is that so hard ? But why does it keep 2 references to the same object ?
Hi Laci - [quote=“telelaci, post:7, topic:41148”]
Yes they are, is that a problem ?
[/quote]
It depends on just what the workflow is. What are you doing here:
1 - I create a new layer
2 - I create objects on it
Are you adding new geometry, inserting a block instance, or making new objects and making a block from them? If the latter, then the objects that are added to the block stay on the layer they existed on at the the block was defined. Even if the instance of the block is moved to another layer, the underlying objects still exist on their original layer. Note that when you Block objects, the result you see is a block instance, not the original objects…
My workflow is the following.
I wanna build a machine. So first I wanna create freely reusable building blocks. When I’ve created all types of parts (blocks), then I just assemble the machine at the end, by inserting the parts. Of course the hierachy must be nested. Because just imagine a block of a nut+bolt. This part can be in any part of a machine because its so common. Probably its part of other block also, and other block of blocks. This is the purpose of blocks in any other CAD. We don’t want and we don’t need to define them always, but only once, then we just use references together with some individual properties. But a block must be freely usable, that means : the block instance’s layer definition must be relative, not absolute. Just like a directory structure on your disk, what you can move/copy to another subdirectory, keeping the original subtree, that happens with your block’s layer definition too. At least it should.
So the block definition’s layer structure could be static, but the root of the block instance’s layers must be relative and moveable. This is not sophisticated programming problem, maybe it sounds, but it doesn’t.
But if the layers are fixed, then we can’t build any sophisticated machine, because the layer structure will be a big unusable mess.
Is this the problem ? Or I’m still missing something ? Am I mistaken ?
Please tell me how would you build a machine from predefined parts (blocks) ?
Don’t tell me that I should use SolidWorks. My firm bought that program and I have access and I like it, but personally I like Rhino much better. And I bought Rhino to myself, and its not cheap if you are just an individual not firm.
Has Serengenti functions been already closed ? Because this is a very big defect in my opinion. And I don’t understand how other people use building blocks if those can’t be nested. They are not freely reusable. Am I the first one who’s complaining about this ?
What should I do now ? Omg. I’m gonna kill myself.
Regards,
Laci
Hi Laci - I’d probably use linked blocks, but if not, say you make a nut and bolt you want to re-use in your machine-
Make a Fastener layer. Make your nut and bolt in that layer or even on separate sublayers, one for Nut and one for Bolt.
Now, create a block from the nut and bolt. Copy or insert this block instance where ever you like and move them to whaetever layers you like. The top level instances’ visibility will be controlled by the layer the instance is on, and ALL of the instances, whatever (visible) layers they are on can be controlled by the visible state of the ‘Fastener’ layer that the underlying nut and bolt objects are actually on.
You can also make your nut and bolt in a separate file and Insert it in any other file. (I’d name the layers in that Nut and Bolt file distinctively, I think)
Wait a bit. I’m not so good at Rhino yet, I have to read your advice few times, because it sounds Chinese at the moment. I have no idea what is Fastener layer, and to be honest I donno what is the difference (in terms of behavior) the linked vs. embedded blocks. I’m gonna read user manual now.
And I just checked, there is another suspicious parameter for a block:
Layer Style = active or reference - hmmm whats this ?
Maybe this is the culprit. Currently its set “active”. And my blocks instances are : linked+embedded
But it seems there is a solution woooot ! You gave me hope thanks. I always knew Rhino was a good choice, it was worth the money. It can do anything !!!
I’ll be back soon with the answers.
And by the way the nut+bolt was just an example for sake of simplicity. The real life blocks are much more complicated, I just wanted to explain that a block instance can be put in any place on a machine, not only in the root layer.
Hi Laci - I was suggesting you create a layer, name it Fastener (or ‘Nut and Bolt’ or whatever) and make your nut and bolt on this layer, not a layer that is otherwise in use in your model. If you are using external files, it would probably make life easier if you also name layers in those files descriptively and with names that are not also in the main file.
Aww I thought that was some special kind of layer.
And yes it makes sense now, and it might work.
But some things disturbs me. In this way all parts has its layers globally in the root. And yes those layers work on ALL instances. And I can move the block instance to a new layer and that layer controls that given instance only not all. So fa so good.
But I have two problems:
1 - There are many-many elements and parts in a machine, and root of your layer-tree will be huge. Because its not hierarchcal.
2 - There are 2 kind of layers in your design, layers of blocks and layers of the machine structure, and thats a mess, you have 50 block-layers and you have 30 machine structural layer, that 80 layers and you can’t keep in mind what is what, its way too much. It should be hierachical. In that case you still don’t know/remember the layers by name, but you can’t make a mistake, because you can walk thru the tree, just like a directory tree, and you have just a few selections of leaves always, you cant miss it.