I’d like to lodge this feature request to change Explode behaviour:
If the to-be-exploded group/component is at the lowest level of the hierarchy, (i.e. containing only raw geometry), that the default behaviour is to assign to Layer0
That there be an Explode Preferences toggle for behaviour on nested groups/components, with the default being that it explodes to Layer0, and the option to explode to the layer of the parent group being exploded.
In my own workflow, I virtually never want the parent layer to be assigned to child groups on explode, and when I’m not paying attention it can cause no end of problems.
There is no reason or excuse that exploding a group of raw geometry assigns to other than Layer0. For beginners this is yet another mysterious way that faces and edges end up on wrong layers (anything other than 0), but even for experienced users it can be problematic. I can’t think of a single use case where this is ever actually desirable behaviour.
I know that I’m not the first to suggest this — as I have seen similar comments in other threads — but when I searched the forum I didn’t pull up any feature requests for this change. If it already does exist as a feature request, then apologies and maybe a moderator can move this comment there.
An even cleaner and more transparent behavior: just leave the layers alone when exploding. If something had Layer0 assigned to it before its parent was exploded, keep Layer0. If it had some other layer applied, keep that layer. Let explode just move things up one step in the hierarchy, without silently changing layers.
I support Christina’s idea because one doesn’t know why contents use a layer so explode shouldn’t presume to change the assignment, regardless of whether to the container’s layer or to layer0.
Edit: I can imagine how the developer thought “this group of stuff was on the roads layer. Surely the user expects the contents still to be on the roads layer after explode.” But that line of thought derives from CAD and doesn’t follow the learning about how to use SketchUp’s layers safely that has evolved since.
Usage: Extension: With background Observer processes etc and Context-Menu items…
Questions resetting Current-Layer away from “Layer0” - but it is still allowed.
Assigns “Layer0” to all manually added Geometry [Edges and Faces] - irrespective of the Current-Layer setting.
If there’s a suitable Selection…
Context-Menu = ‘Explode-To-Layer0’ [the newly exploded groups/instances geometry has Layer0 assigned to it - ignoring the original container’s layers - unlike the annoying native-tool]
Context-Menu = ‘Selected-Geometry-To-Layer0’ [Layer0 is assigned to selected geometry, the process can also include all geometry nested inside selected groups/instances - useful to fix messy explodes and thoughtless modelling disasters].
Before SketchUp 2019 introduced dashed lines enabled as a property associated with layers, I was in nearly complete agreement with you. Unfortunately, in order to get dashed lines, you now are forced to assign raw geometry (edges) to layers other than layer0!
My use of “nearly” in the above paragraph was forced by my occasional use of assigning NON geometry elements (guide lines, points, dimensions, and labels) to layers other than layer0 occasionally - as I find it at times a PITA to, for instance, put a single guide line into a group so I can control it’s visibility (by assign the group to a layer) while leaving the guide line itself on layer0).
to be a better way to go. You will end up with geometry (your dashed lines) on layers other than layer0 - but you need that to preserve the “dashedness” of the line.
Sigh - I’m yet again wishing that Trimble had chosen some other way of implementing dashed lines!
No, you aren’t required to assign raw geometry to layers other than Layer 0. There’s no need to change the procedure of leaving all geometry on Layer 0 to utilize the dashed lines feature.
Technically, you’re correct. When I need a single dashed line, I can indeed put it into it’s own group, then assign the group to a layer other than layer0 that is associated with “dashedness”. But there are times I WANT it to interact with non-dashed lines around it - and putting it into a group prevents that interaction!
You can selectively group the edges that need to be dashed and assign a dashed layer to that group, not to the edges. The edges will inherit the layer’s dash behavior from their group, the same as they inherit layer visibility. This technique also avoids questions about why some of the edges in a group are dashed but others are not and why dashed edges break non-dashed edges.
Edit: rules are made to be broken. If you are expert and fully understand the implications, nothing in SketchUp prevents you from doing dangerous things with layers. But others are best off following the guidance.
Unfortunately, I actually have a use case where I currently WANT dashed lines to interact with non-dashed actual geometry!
Also unfortunately, it’s one I’m encountering in my job and my employer considers all my work to be proprietary, so I can’t share it. And I haven’t been able to imagine ANOTHER use case I could present here that illustrates my problem without violating my companies policies.
I have inadvertently created a tangent discussion about a use case for having geometry on a layer other than layer0 that has veered away from the problem this topic was created to address (behavior of “Explode” in regards to layer assignment of exploded geometry), so I’ve created a new topic:
to address my issue. Please follow up there if your comment isn’t about the behavior of the “Explode” command.
I have a suggestion to this…if we are working with components that are being added to each other to make a model, maybe each component when/if it is exploded gets put on a layer that is named for the original component that was exploded as the parent and if there are multiple layers within the component those would get moved to a sub-layer of the parent layer.
That would create new layers that the user never asked to create, and sounds like it would assign layers to raw geometry. Also linking exploded content to what it was exploded from kind of goes against the concept of explode, which is to bring different entities into the same drawing context as equals.
there are actually quite valid reasons for retaining the layer association on raw geometry if exporting for CAM software…
geometry ‘layers’ and certain layer colour’s indicate cut’s, etchings, tool run-off, etc, many firmwares cannot work with groups of geometry…
however, it is prudent to only explode the groups in the export ‘copy’ of the model, once it is finished following the conventional wisdom regarding Layer0…
I agree that there are rare use cases of needing raw geometry on other than Layer0, but these should not be anything but fully intentional on the part of the user.
And I’m not convinced that those few specific workflows justify the current default Explode behaviour — which causes untold problems for orders-of-magnitude more users.
So instead of needing a plugin (such as TIG’s above) to Explode to Layer0, maybe it should take the plugin to explode to the parent layer for the type of workflow you describe.
I do think Christina’s suggested default behaviour makes the most sense overall and is the least disruptive in creating un-anticipated / un-desired outcomes.
I think it is up to CAM software to implement a way to handle groups/components without them needing to be exploded. An exporter could explode under the hood, apply the layer from the parent to the children, export and undo these changes.
I tend to support eneroth3’s first comment its seems to me to be the most logical.
If the user wants more control when exploding, then rely upon a script such as TIG’s.
Did we receive a warning from TRIMBLE that the introduction of the linetype feature resulted in this fundamental way of how it handled raw geometry when components and groups were exploded…?
Not sure what everyone else works with but I have to handle massive DWGs with chaotic layer and block structures and the unsolicited reassignment of entities into the anything other than the expected Layer 0 has caused me hours and hours of frustration… I can only imagine this is a nightmare scenario in large architectural offices that have to deal with DWG data interchange…
Completely unintuitive and contrary to that the “best practice advice” we have been exposed to, never should have happened… but I guess it will never be fixed either !
I don’t think this has changed (When you explode an object, it still inherits the tag of the parent )
I guess it was useful the early days.
Check this model (version 1.3.71)
Jack is correct. When a tagged component or group is exploded the contents inherit the tag. I just checked in version 3.1 and it’s the same.
Since this isn’t going to change, at least immediately, it’s easy enough to immediately change the tag association immediately after exploding while the geometry is still selected. Or run TIG’s Default Layer Geometry to fix all of the incorrectly tagged geometry. A keyboard shortcut could be set to make that nearly instant.
