Move all items in group and sub groups to new layer


No you do not. It goes on a “semi-common” layer. This layer is set visible in 9 out of 10 scenes.

Grouped geometry that is different and needs to be changed, need only be copied once for that scene that is different, onto a layer that is visible in only that scene.

No need to multiply the work 9 times !

Geometry groups or component instances can be on any layer, or layers, … common or unique, … subject to the author’s organizational needs.

It is primitives (edges & faces) that should be on “Layer0”.


Please learn to understand how layers work, how groups work and how components work. It’s complex but remarkably simple once you get it.


Sorry, I’ve been out of the country for a while, so wasn’t keeping up with the replies.

Thanks very much for all the input, I do appreciate it.

However I still don’t think it really works for me, as I can’t have any common objects. If I am sitting with my wife, and we say “how about we move that wall and add a window in version 8”, I don’t want it to change in any of the other versions.

I suppose in effect, what I would like is 10 different models, and the ability to move between them using scenes, rather than opening different files.

I.e. I want to look from an angle, and then toggle through my different versions.

All I want is one base design, then create a copy on each layer, and make changes on that layer, so the scenes will work.

Seems still rather odd that I cannot take a group and move it to a new layer, including all it’s child elements…


You can - as long as the actual lines and faces are on group 0 and the groups are on the specific layers.


I can’t see how.

let me take a real example.

I have a house model with a roof. I am trying to insert 10 variations of a new floor, each in a scene.

I now want to copy the roof from scene 1 to scene 10 “external view”

The roof is on layer 1, and I make a copy, and change to layer10, which contains all the elements for scene 10 only.

when I then hide layer 1, the new roof is gone, because all the groups within the group are still on layer1

I have to go into each group, and it’s sub groups, and their sub groups and so on, and select all, change layer.

I have to do this so many times, I have spent 90% of my time just changing the properties, due to lack of inheritance when changing…


Does this help.


Sort of, however it’s not what seems to happen for me. There must be a logical reason, however I can’t see it.

I will upload an example here, a simple one.

I have a model with the following:

Layer 0: items that appear everywhere
Layer Start Only: layer for items that only appear on the “what it looks like now” scene
Layer Option 1: my first design
Layer Option 2: my second design
Layer External 1: first design with the roof on

I then have 4 scenes

Scene Start: Layer0 + start only
Scene 1: Layer0 + option 1
Scene 2: Layer0 + option 2
Scene 1-External: Layer0 + option 1 + Layer External 1

In the model uploaded, everything works fine through the scenes, however I have not put the roof on Scene: External 1.

I want to copy it from the starting model.

So I do this:

  • Make “start only” layer visible
  • copy the roof
  • move the roof to layer “External 1” (which is a visible layer)
  • new roof disappears
  • need to go in and change the layer of all the sub groups…

You can see it in action here:groups.skp (157.9 KB)

Imagine this with tens of layers, tens of copies, and tens of nested layers of hundreds of groups…


Again… @wcndave …heed what you read.

In your example model I find all the raw geometry within the Group named ‘Option 1’ is assigned to a layer other than the default Layer 0

If you persist in changing the active layer away from the Default Layer 0 you’re inviting modeling mayhem.

You’re making the model way more complex than it needs to be.
Changing the layer assignment of a Parent group does not change the layer assignments of its subgroups.
Leave your subgroups on the default layer and assign only the topmost (parent) groups to other layers.


But that does not mean you build 10 houses!

You DO have common items. Everything BUT “that wall and added window” are common to all versions. (Until you create other variances.)

Leave the commonality on A common layer (be it “Layer0” or another common layer named “Common Walls” or whatever. As long as the primitives are still on “Layer0”.)

And when we told you this before, you said it doesn’t work because I have to edit all the groups and set all their children to another layer. … But no,… @Box has shown you that this is not true.

What is unfortunate is that your model now has too many copies, with subgroups and primitives on the wrong layers.

To enter heaven… you must delete all copies but the original. Open the original and set all primitives to “Layer0”. Repeat for any nested groups.

You can also set all nested groups to either “Layer0” or a common layer you’ve created.

Then follow this rule:
Copy only things that are uncommon or unique to a version.

If you change a wall in one version, then this wall is no longer common to all versions. You know it is different in at least ONE version, os you must group it and copy it to that versions layer.

But what about the other 9 versions ? Do you copy it 9 more times to 9 more unique layers ? I would not, myself. If this wall stays the same in the other 9 versions, I would copy it ONCE to a layer that is common to those other 9 versions. The layer would have meaningful name “Bedroom Wall - Option 1” or whatever.

You can use Attribute Dictionaries attached to layers and groups in order to keep track of options and descriptions.

Use Aerilius’ Attribute Inspector to work with dictionaries and create them. Even if they only have one note what the layer is for, or why a group copy is on a certain layer.


Thanks Box! As they say a picture is worth a thousand words. I was having the same issues as the OP and very frustrated that simply assigning an object (especially duplicated ones to create scene variants) to a layer doesn’t recursively assign all objects in the sub-group to the new layer. This seemed like a bug to me at worst, and at best lousy user experience since there is no indication that it is merely the out group being assign. SketchUp should have assign to layer, and assign all to layer commands.


Sad to say, this sounds like you didn’t really understand the discussion above. In SketchUp there is no need for nested objects or geometry to be associated with the same layer as their container and no advantage gained from doing so. Hiding the container or its layer always hides all the contents regardless of their layer associations. Conversely, associating nested contents with anything but Layer0 can create very confusing visibility issues.


@slbaumgartner I fully understood the discussion thank you very much. My point remains that it is a bad user experience as witnessed by the length of this thread, the poor explanations by support personnel and the only cogent one from Box that required essentially a video to clearly explain the concepts behind layer0 usage and nested ownership.Whatever the case, you can’t argue that it is a blatantly obvious behavior. I gave two options: a bug or a bad user experience and I stand by my point. Good software should make clear potentially confusing scenarios, and on the whole SketchUp does a good job of it with warning dialogs and other hints that often explain non-obvious behavior. I just think they should make this clearer so as to avoid confusion perhaps via dialog warning, or provide a command like “assign all nested to layer” for those whose working style is more conducive to such a feature.


@guomo I totally agree. I came to SketchUp not from other CAD programs, but from being in an Adobe environment for 20 years. Adobe made its layers operate as the term “layer” would imply: They have an order of presentation (a layer can obscure the layer below it); child or sublayers don’t have more than one parent; generally properties applied to a parent are inherited by the children; etc. The behavior of layers in SketchUp is totally different than in Photoshop or Illustrator. Trimble could have avoided a lot of confusion and made their program much more intuitive to use if they either chose a different term for the property they call ‘layers’ (sets? tags? containers? labels?), or used the same structure of behaviors that layers have in Photoshop.

When a new user is moving objects around in space, it is counter intuitive for an object such as a door (a group of faces) to be said to be on a layer, yet the faces that comprise it to be on a layer that is not a child or subordinate to the door group. Having properties of association that are independent of one another, as SketchUp does, sounds like it’s extremely useful in many contexts. However, choosing the term “layer,” which has a real-world corollary, and then having them operate according to mathematical rules that do not apply in the real world, is just not enlightened programming.


Yes, most of us came from CAD where entities actually are put on layers. So, we often fall back into the trap (as I did above quite a few times,) of using the word “on” instead of “assigned to use” with regard to SketchUp’s shared behavioral visibility property sets they they poorly call “layer”.

Also SU does not yet have anything like CAD’s nested layers (because SU really doesn’t have true layers.) Instead it currently has nested entity containers called components (of which group is a special sub-type.)

Yes, it actually can be powerful, if the simple rules (repeated above multiple times, by multiple sages,) are followed.

For example, I can create a “layer” named “People”. Then I can insert little person component instances all over the model, into various geometric containers (group and / or components,) and choose globally whether I want them visible or not, simply by toggling the “People” layer, in the Layers inspector.

Oh many of us agree on that ! There are whole other topic threads where we’ve debated this.

I myself am a proponent of changing the name in the UI (to “vizard”,) and then to implement true geometry layers (as a special sub-type of group under the hood.)

One of the challenges is that there is a mountain of online documentation and books in print referring to SU’s visibility behavior as “layer(s)”. All the online help, all the built-in Instructor content, all the video tutorials, etc. etc. would need to be reissued for the newer “way”. (Or warnings added to older online materials about the change in nomenclature, for newer versions.)

All that in what twelve languages now ? It’s not as trivial as just changing the caption on the “Layers” inspector window, or a drop-down picklist label.

But, yes, I totally wish they never used the word “layer.” It is too closely related to 2D work, and brings with it the notion of Z-order (ie, stack order.)

The word “container” is a much more 3D-like kind of idea, that has the notion of holding things and separating things, and having sub-containers, etc. And SketchUp already has these, (groups and components) which is what long term users use to organize and separate geometry.


Comments as a new user of SU. Made all the same mistakes. This thread primarily and a few others has been instrumental in figuring this all out. I know I am opening up an old thread, but as this was the most complete one I found that helped display many different iterations of the layer0/layers/toggle/groups/hide/unhide I will now share this one point. The one place I consistently change the active layer is as follows. After modeling, grouping, and using layers to create visual groups. I am ready to start creating scenes, I do change the active layer when adding notes and dimensions. That is easy enough to keep track of, and easier than creating them on layer0 and moving. Usually by that point I am close to my final presentation, or creating scenes for hard copies prior to printing. My rule of thumb, layers are for forming visual groups made up of grouped components. Active layers other than 0 are for labels, dimensions when making scenes. Also I don’t use layout yet, although I have, so i am creating ‘layout’ views in SU.

And finally… meditate the following… SU is not Adobe… Layers are not layers… over 5 times before drawing.
I also would point out so many of the helpful/popular videos I watched, never once mentioned the layer0 rule before teaching groups/layers/scenes.


These are on the short list of exceptions to the “primitives on Layer0/leave Layer0 active” rule.

The exception is motivated by the fact that they are not geometric elements of any model structure, so there is not likely to be any modeling error resulting from them not being visible when you expected them to be. In contrast, you can get extremely confusing consequences if for example a face is associated with a different layer than its edges. Or when part of a structure refuses to appear when expected yet you still get new entities “sticking to” it.

Sad but true. Many of those videos are somewhat old, and it took a long time before this standard advice became well-absorbed into the community lore.


IMO the same applies for all applications that use blocks/components/whatever you call them. AutoCad blocks also need their contents to lie on layer 0 unless there is a clear specific reason for deviating from the rule.



Hey so i have read through the entire blog and full disclosure, I know how sketchup layers differentiate from other CAD softwares…

Now with that said! I am in need of a fast way of turning a group, its sub groups within, AND, the entity itself to a specific layer.

Now the reason i need this is because i am trying to find a way of working my layers between sketchup and 3ds Max.

What i have found is that if i have a layer called “Building” for example, and i draw a geometry, then group it, and then assign that group to layer “Building” the Layer0 entity still sits within that group.

Now when I import that sketchup file within 3ds Max that group is now showing up on Layer0 and not on “Building”.
The workaround that i have found is to double click on the group that is within the “Building” layer, and then triple click or select all of the entity and change that to “Building” layer.

When done this way the “Building” layer will show (with its drop down with all groups etc.) when it is imported into 3ds Max along with Layer0 as a separate layer.

This may sound like sketchup Blasphemy but if there was a plugin that could change a groups layer right down to its core entity then i could just save it as a new file, retaining the original.

Now, if there is a better way to import layer accurately and efficiently i am all ears but i have not yet come across anything which is why i ask for a Plugin that can change a groups layer to its core.

Thank you,



Have you tried changing the export options to “By layer” rather than the default ?:

What would be better (if SketchUp’s 3DS exporter doesn’t work for you,) is a custom 3DS exporter.


Hey Dan,

Thanks for your reply. Yes I tried that to no avail.

I did however find a good way of doing this, and that is using the sketchup plugin called PutOnLayer_sortname.rb which can be found here…

The plugin can be found half way down the page. The plugin at the top is called PutOnLayer_bmw_wrh.rb and that one works but it is not what i am after.