Is there any way to save tag to component

I would like to save a tag to a component so when I place that component into the model it already has the correct tag assigned. I use the same library of components to complete drawings for estimating and have to manually assign the tags every time I draw. It ends up being a lot of repeat work that I would love to eliminate.

I’ve searched quite a bit and it seems that this is not possible in SU but I am wondering if there is some sort of plugin that anyone knows of that would accomplish this. Thanks in advance.

If you refer Tags as layers when you save a component or copy paste it preserves the Tag.

There is another option:
If you apply IFC category to your components you can tag them.

You can also use Add Ifc Quantities to Selection to attach quantities too.

This is possible to set up with some compromise. First, understand that a component, either inserted from your library, or from the 3d warehouse, or dragged in and dropped from your desktop is basically an independent .skp file. That component you are inserting can have any number of sub components nested in it, and can also have any number of tags associated and saved with the file. So your component can have three cubes in it, all of them sub components, and all of them assigned to their own tag, let’s call them tag 1, tag 2, and tag 3. If you import that component the three sub components will appear and the associated tags will be populated in your Tags pallet.

However, the outermost component shell that contains all the sub-components will be untagged. This is because untagged is the default for the entire SketchUp modeling space at the time the file was saved. Importing a saved .skp file as a component basically places a component wrapper around a saved file, using the name of the saved file.

There are ways around this, both with compromises. One is to make a component of your object before saving it, assign that component a tag and then save. When imported this will arrive double wrapped or “nested” in your new file, it will have the component wrapper you made with the associated tag, and it will have an outer wrapper that is untagged created as part of the import process. Right click and explode once to delete the outer container, or leave it double wrapped.

The other way is not recommended and can cause extensive problems with your file. That would be to tag the raw geometry of your object before saving your file. This would result in an imported single wrapped component that obeys tag visibility, the outer component shell will still be untagged. However, tagging raw geometry can lead to serious conflicts in your model as raw geometry can merge even when not visible, there be dragons here, ye be warned.

A third method is it to create your desired tag in the working file (make it a template) and change the active tag to that before inserting your component, it will be inserted single wrapped and assigned that tag, but don’t forget to change it back to untagged before continuing work! This also can be tricky.

This double nesting is not the case with “copy/paste”, because the component is not a saved .skp file. Ao another workflow that could serve you would be to create a file with all the components you regularly use and keep it open in the background, then copy paste things out of that collection file. They will be pasted single wrapped with tags assigned. Depending on the number of components and their size this can work.

I generally use component collections and a version of the first method and either explode the component once, or leave it double wrapped wrapped.


Thanks for the explanation. I might experiment with your first option. I don’t like needing to remember to explode the component each time but if I leave it wrapped it will mess up my bill of materials report. Maybe I change the setting on the report to go deeper one level and that will solve it. I am going to try it and will let you know how it works. Thanks again.

1 Like

Thanks for the IFC tip. I have not worked with it before. Are you able to customize this to fit different materials/components? I will do some research to see if that may be a sufficient work around.

Thanks again

Actually when assigning an IFC category you are indicating what type of element it is, for example a wall or a window. The Tag parameter and the other available parameters allow you to tag that element in Layout.
I have made a plugin that extracts the IFC information of each element and creates a CSV file that can be inserted directly as a table in Layout. In the case of windows you would have a list with all the types and their units.

This video shows how to take advance of that information in layout

@endlessfix just discovering this tagging issue for myself.

Created a component library. All component files have the same tag structure as my template.

Your comment here makes me wonder if it is possible to make the outer wrapper tag active during the save process so that the component saves with that outer shell tag in place. Is this thinking correct?

The logic of your thinking holds, but as I recall this does not work. A saved file does not “remember” or save the active tag at the time of saving. I think it has no effect on the save. I’m not at my computer now, but you can easily try it and see what you get.

Is this a possible secondary solution?

I have a library of components in a single file. Some 150 items. Each is saved with a top level component “shell” with a tag. What if I created another “top level” component shell that was the sacrificial shell that didn’t get saved?

Or I guess, I could also open the saved component file and add the top-level component shell back to it and tag it properly. Correct?

Right now, Im looking at your other idea of just having the main library file open in the background and copy/pasting components from it into the new project.

Will test as you have suggested.

It’s a curious feature to me. I would love to know why this was programmed this way. Seems like if I setup a component in a file and want to save it just as it is that the software should actually save it “just as it is” instead of stripping out a major piece of it and not tell me that it has done so.

Interesting thing to brainstorm about.

Then all 150 items would import together with either drag and drop or component browser.

Not sure I understand this idea, sounds like the items would come into a new file triple wrapped? Or, how do you not save the outer shell?

Of course I don’t have any insight but I assume it was a handy way of encapsulating the referenced geometry so it does not immediately merge on import and because the imported file or component is really a sort of xref that retains it’s link to the original, when you update one of the “components” in your file it really alters the base component file saved within your file and auto updates the other instances as references. Or if you drag and drop a .skp file from your HD the component in your working file retains the file path of the original, and if you update the original file separately you can right click in your working file and choose reload to update the xref. Components are really like mini .skp files thats why “save as” and “reload” are available in the context menu.

So a file with raw geometry only gets a component shell added when it’s brought into another file so it can act like the “component” it is.

It’s really just adding something, an outer shell, not stripping anything.

It does seem like you cant win this game. For instance if you have a file with a component object in it which has a tag associated and you File>3Dwarehouse>share model to the 3Dwarehouse then re-import it, it comes in double wrapped with an untagged outer wrapper which retains your inner tagged component. But… if you instead select your tagged component and use File>3Dwarehouse>share component it re-imports single wrapped but your tag has been erased and replaced with untagged.

I have not yet found any solution to importing components with their tags, apart from copy paste. But it feels like there should be a way, perhaps it is somehow exposed to the Ruby API in some clever way that can be leveraged for an extension?

Not the behavior Im seeing.

Using my component library file as an example:

I have 150 or so components. Each has groups or components within it. Each has shelled labeled and tag. Lets say a tree like this:

Component Shell - Name1 - Tag1
- Group1 - Tag2
- Group2 - Tag3
- Component2 - Tag4
- Group3 - No Tag

When I right click on this component I see “Save As”. I follow all the prompts, save it in the right location and then open the file. What I now have is this:

 - Group1 - Tag2
 - Group2 - Tag3
 - Component2 - Tag4
 - Group3 - No Tag

Is that not the behavior of “stripping” off the outer component shell and tag?

What makes a bit of sense to me is that when one saves a component to it’s own “file”, the save process uses the component shell name to name the file. Perhaps this process is the one that removes the component shell? Not sure.

I think what makes zero sense is that this behavior is contrary to all other save processes in every other platform. When I make a word document and save it, I don’t have the first page removed. It’s an action that is counter-intuitive to me. I see a component in model space. I like what I have and I want to save it just as it is. So I right click and hit “Save As”. That action of saving, on every other platform, means that, what ever I have selected, and all it’s associated attributes, will be saved just as it is in it’s current state.

I think it might be easier if I was saving to a blender file or .3ds file or even to a .dwg. This is not the case though. Im saving a sketchup component to a sketchup file. No translation needed.

I think this is probably the conclusion and the only “win” is to keep the library in one file and open during the modeling process so I retain my component naming and tags. Frustrating.

Wish the programmers were able & willing to shed light on this mystery for me.

You are correct on this.

But if you bring that saved component into a model via the component browser you will have the Upper level as well, the file itself is the ‘shell’.

1 Like

Ok…that makes sense…and now that I have gone back and read @endlessfix 's April 25th comment I can see that he is saying that same thing there and I just didn’t understand.

and thus the complexity is now understood but I still struggle with it in principle.

The .skp file is, as you said, the shell. The save action doesn’t remove the shell, but instead the shell becomes the file and when I open the file it’s, in effect, like double clicking on the component. When I browse for that component in the component browser Im seeing a list of .skp files that, upon dragging into the new model, are converted back to their other state as a component with the named component shell.

I think the issue that I am only now seeing is that when a component is saved, there is no way to attach the top level tag connected to the component to the .skp file. And this is why when one drops it into the new model it is placed on “untagged”…the default action for anything not having a tag. What is then really lost in translation is the tag id for the component shell.

This would then be the ask. Can Sketchup programmers find a way for the .skp file to hold onto to the tag id that is then reapplied to the component upon insertion into a new model?

This seemed like a complicated request at first, but upon reflection, if one is using the right click menu to save as, would it not know that what it is saving is a component and the tag id could be saved in the background for the moment that the component is dragged into a new model from the component browser?

Thanks for humoring my investigation. Current best solution is open library file and copy/paste from it to the new model.

1 Like

Got to say that this whole process has made me re-think how im saving components in the first place.

I’m using them exclusively in Layout to build a stacked viewport system. Actually realized that I don’t need the top level shell on a tag. I need the different objects within the shell on tags because the visibility of those objects is different in each viewport. If the top level is tagged and gets turned off, the entire system doesn’t work.

Weird how a smaller problem with no good solution led me to look at the problem differently and find a solution that solves the larger problem.