I know that with regards to layers in Sketchup, best practice is to draw all geometry on Layer0. If you create groups or components you then use other layers for those groups or components.
If this is the optimal workflow/methodology why does Sketchup behave in a way that seems to run counter to that? What I mean is this…let’s say: You have some geometry, all on Layer0. You then group that geometry and place the group on Layer1. You then decide to explode that group. All the geometry inside the group has inherited the former group’s layer; it is no longer on Layer0, where it was before it was grouped. The geometry is now on Layer1. Isn’t this sort of odd considering best practices dictate that these entities should reside on Layer0. Is there some sort of workflow or functionality that this behavior facilitates that I’m overlooking? If not, it seems kind of strange that the program would lead a user towards a condition that is considered to be less than optimal.
I was sort of laughing to myself and thinking, This is sort of like if an AA group used a pub for their group meetings.
This is an issue that many have asked to be corrected for a long time, it does have its uses but they escape me right now.
Tig’s Layer watcher avoids this issue, among other things.
I’ve been going to my AU meetings in pubs for years.
You’re right, it seems the following workarounds ought to be part of the code/procedure or at least an option?
when exploding a group on a layer other than layer 0 , before clicking elsewhere and while the exploded group is still highlighted in blue, you can reassign back to layer 0.
alternatively, before exploding group, assign it to layer zero, or delete the layer and select radio button move contents to default layer, then explode.
How difficult would it be for developers to build in an option after explode and whilst everything is still highlighted to move things back to the default Layer 0? That would allow an option to either do that or retain them on the group layer (though if even @Box cannot remember why you would want that option, maybe it’s unnecessary).
The rule of drawing with layer0 and apply layers only to containers has evolved in the community. SketchUp was not originally designed with this rule in mind and thus explode doesn’t follow it. However people have been calling for some time to have the behavior of explode tweaked to better suit the workflow even SketchUp’s own teaching material endorses.
What you really want to do is not assign Layer0, but keep whatever layer was previously assigned. The exploded content may very well contain groups and components with other layers and there are rare cases where it can be beneficial to assign layers to raw geometry (e.g. hiding the seam between adjacent containers in some scenes but not others).
Implementing this as a plugin is not trivial as you don’t know what entities had what layers before the explode operation. Implementing it in SketchUp itself is as far as I can see quite trivial; it’s just a matter of keeping the data that is already there rather than overriding it with other data (the layer of the exploded group). For Trimble this is much more of a design decision than getting the implementation to work.
That is quite ironic. Can we think of other things that were not originally conceived but are nevertheless a common part of workflow in practice? It would be nice if software followed the law of natural selection: if something is done commonly, it gets written into the DNA. Personally, I think this kind of “unsexy” thing is usually more important than new functionality. Nice as new functionality can sometimes be, it is generally peripheral to core work.
I’d say using the term “layer” in the first place is an example of something similar. Normally layers are like placed in a document that objects ar placed on, whether it is a 2d sheet or more of a 3d box. In SketchUp where faces and edges stick but also can be associated with different layers, the whole place analogy fails. It makes little sense to say an edge is on one place while the face it binds is on another while they are next to each other and interact with each other. Instead groups and components become the “places” and layers becomes a property of each entity.
When first designing the software it kind of makes sense to use the term layer as it is close to what layers are in other programs, but with sticking and how you can use them or individual faces and edges, not just a mesh as a whole, the phrasing gets confusing.
Agree fully! 2019.2 has a lot of improvements in this area. I think the section place name prompt coming after placing rather than when activating the tool is a good example. It may sound “unsexy” when trying to sell the products but it just feels so much better when you use it. Now you are not interrupted when you want to place a section cut, but can first place it in peace and then, when you know where it ended up, come up with a name for it. I hope to see more polish like this!
Software evolving would be ultimately when its core functions are minimised, and a learning module would be added: sequenses of actions were recorded (if a user explodes and then assign everything on a layer, this might be the ‘standard’)
Each time when you create some geometry and need to triple click to get everything selected and then grouped would evolve in a single click.
Off course, software developers would loose their jobs,…
So they implement (almost ready) features first, so they can fix it in a later release…
Like rhe naming of rhe secrion plane…
Or the now added different units for footage and volume without individual precision settings…
Right–this was the first point you made to Simon, and he may have taken what he said from me. But what I was driving at was respecting the layer assignment of the geometry in the container, and allowing that to be persistent regardless of what that assignment is. Thanks for pointing that out; I was imprecise earlier. I was using ‘layer0’ merely because that’s the specific example I was focusing on. But I was thinking along the lines that you mentioned…
….But strangely enough, I was playing around with this and found that Layer0 is a special case. If the entities inside a container have a layer assignment other than Layer0, that layer assignment is persistent/respected and wins out after the container is exploded. I was not expecting this. When playing around with this and testing this out I found that enabling ‘Color by Layer’ helps by giving you quick visual cues as to what is going on. Also, along those lines, with ‘Color by Layer’ being enabled, you can see that the layer color of the non-Layer0 entities inside the container is what is displayed; the container’s layer color is not. And on the flip-side, the layer color of Layer0 entities inside the container are not displayed by ‘Color by Layer’; the container’s layer color is.
The design of this with respect to Layer0 and how it’s treated differently than the other layers reminds me a bit of how AutoCAD deals with Layer0 with respect to blocks and the block insertion layer. Well, not all of it of course, but the layer color display part. And AutoCAD’s ‘ByBlock’ color option has similarities too.
I make a layer and assign it before I start drawing. After finishing an object, I then make it a component. By doing this, nothing else or new drawing will “stick” to it. later, I may assign several components as a group. This seems to work well for me.
Layers don’t have any impact on whether or not things stick together. The only ways to prevent geometry from sticking to other geometry is to put it in a group or component or to leave space between them. You should make sure you are creating and leaving ALL geometry (edges and faces) on Layer 0. Only components., groups, dimensions, labels and screen text should get layer associations other than Layer 0.
Yeah, I’m not really sure what gregnier is saying other than reiterating the basic way that Sketchup works with regards to stickiness. Not sure whether he was saying that creating layers to keep objects from sticking together (which is incorrect…as you pointed out); I’m just thinking his wording was unclear. I don’t understand what ‘make a layers assign it before I start a drawing’ even means. How can you assign a layer before any entities are even created? However, In any event, it doesn’t seem what he said or tried to say was on topic here.
Sounds like he is changing the active layer so that he is drawing on that layer before creating groups or components. This is not good workflow. As @DaveR says above, all raw geometry should remain on Layer 0. So Layer 0 should remain as the active layer 99.98% of the time. If you don’t know what those .02% include then you don’t need to change it.
Wouldn’t it work best if SketchUp just left objects on the layer they are on, when exploding. My edges, for example, are on Layer0 and I’d wish they stay there when I explode a group. I don’t explode things very often it seems… I guess I don’t see the use. I do import dwg often and do not like every edge being on a layer. I often fix up dwg before import and put everything on Layer0 in CAD–but grouped how I want.
I think it would be best if at least raw geometry were left on Layer 0. There are benefits to the current behavior when exploding nested groups/components, though.
I don’t explode components very often either but at least when I do, I know the sub components will stay on the layer of the parent. And when exploding to raw geometry, I know to immediately fix the layer association while that geometry is still selected.
This is a bit like labeling all your socks “socks”, and then place them in a box. I prefer to place them all in a box and then label the box “socks”. It’s easier to edit or re-label at a later point as the data isn’t duplicated between objects.
Good catch, and also an example why Layer0 isn’t “really” a layer but rather represents the lack of a layer. Other examples are how it is always shown on top the of the layer list and can’t be renamed.
