In real world objects can have multiple properties or adjectives. For example: a wall can be an exterior wall and at the same time can be for demolition and at the same time can be oriented north.
Tags is the ideal tool for replicate this in a digtal model.
There are extensions out there that achieve this feature, but with strange tricks that fail soon or later (for example when importing a external component).
I think this feature should be native!
Unfortunately, although I agree with you about the value and logic of multi-tagging, I think this is a horse that has already left the barn. The developers implemented tags in a way that is entangled with graphics, including visibility of tagged entities and dash patterns for edges. Given that framework, allowing multiple tags per entity would create huge issues of confusion. What to do if two tags set different values for these properties? (BTW when dashes were introduced, several of us argued that they should be a property of edges, not of tags, but were overruled).
Perhaps the devs thought that IFC would handle the concepts that multiple tags would have provided…
You could use empty wrappers to achieve something along the same lines maybe..?
Multi Tagging.skp (97.4 KB)
Here is a beta extension for solving what you ask. Ferol was accepting Beta testers, but he has progressed I believe to almost be ready to launch. It solves many issues with multi-tagging objetcs. Liserok Manager [Multi-Tagging] - Beta Testing
In SketchUp Tags are what in CAD applications are called Layers. For storing property values for objects, I would use attributes enabled by the Dynamic Components shipped extension, or IFC classification.
It’s no problem to add beta testers. The plugin is essentially finished at this stage; every now and then, whilst I’m working, I come across a minor issue that needs fixing, but I’m not really focusing on it much anymore – I’m just using it in my work to test it before the official launch.
But more importantly, in the meantime I’ve developed a lot more plugins, and the Manager is now just a small part of the whole Liserok ecosystem that I’m building. And I’ll probably have to present it all in stages, as the Manager plays a certain role within it.
@cescmari If you want, I can add you to betatesters…
In my opinion, the name “tag” is misleading. Layer is a better name for goal to assign colors and line types to entities. Why not go backward?
Agree with you that IFC can handle properties or adjectives or “tags” well. But for now is not possible to control visibility of objects with IFC properties. This would facilitate the control of the model and presentations.
This is a trick that really makes the job.
But is a trick… A little waste of time and implies to be well organized.
It isn’t a waste of time if it makes the job easier.
Imagine being well organized. Why would anyone want to be organized? Surely that’s expecting too much of the users.
I remember back in 1993 when I was learning AutoCAD. I remember my teacher spending a lot more time on layers than what I thought was important. I mean, I just wanted to “CAD ■■■■ up!” (could that be a bumper sticker?..). Then I started actually drafting and I realized layer management was the most important thing to focus on.
I understand the usefulness of multiple tags for sure but it can easily become an issue, especially when talking about multiple users of the drawing files. Over-customizing tags by continuously adding new ones can lead to significant structural and operational decay of the drawing. It isn’t something that is studied often in CAD-related courses, but it’s actually a central study topic in database theory. And whether we like it or not, CAD holds many database characteristics, it just also happens to have visual elements directly related to those characteristics.
That being said, when you dig into grouping, tags, and the outliner, you can achieve the control you’re talking about with multiple tags/object but without the risks above. The only book I’ve read that details this is “Sketchup to Layout” by Matt Donley, which I highly recommend.
Layer order makes sense in a 2D application, where you’re essentially placing things on top of each other. In a 3D application, that hierarchy doesn’t really exist. Objects have positions in 3D space rather than a simple front-to-back stacking order.
That is why the name was change was changed.
I think of grouping tags like a folder structure. The placement (above or below like layers) the object lives in the model is not really as relevant as is the hierarchy (grouping and build structure). Think of a facility with several building, each building has common items inside - say furniture. You can group the tags from fine details to large details, but keep in mind the top level controls visibility for everything below. So if I made a group for all furniture, then another group for each building (separate groups for each building - and include all the furniture groups) then add the upper most group for the facility - and include each of the buildings groups which is holding all the furniture groups.
With this structure you can show or hide each buildings furniture independently.
You can show or hide each building independently (hiding the building would also hide that ones furniture.
And the overall facility could be hide or shown - which would mean all items (not practical but good to illustrate hierarchy.)
I made each furniture object in its own group and assigned tag RawFurn.
Same for each building - RawBld
and same for Facility - RawFacility
and these tags are outside of tag folders.
You are mixing tags with entity hierarchies in this case.
I understand the use case and I would hope to see some native solutions to this kind of thing in the near future - as you say, being able to assign multiple tags to the same entity is a fairly common data organisation function and certainly one that would facilitate some additional functions.
that’s the method I use pretty extensively
I don’t think that the architectural limitation is a reason. Just make tags layers again. They’re layers. Then just bring tags back as a new feature. Under the hood it’s just adding one more key-value pair that takes a list of values. Then let people decide whether to use them.
But they aren’t layers, which was the point.
If you have 2 tagged objects side by side, one is not above or below the other, nor does one exist on a higher plane of hierachy than the other, so being called layers was a misnomer.
Renaming from layers was supposed to help people to NOT make the assumption that they work like autocad layers. New people were assuming that they isolated geometry when they do not, and becoming frustrated and screaming into the forum about how they are not layers… Not sure how the name affects how they work though…
Beat me to it!
