![]() So, there’s a lot of stuff to think about if you are aiming at sticking with existing functionality as Sketchup Tags. You cannot see all windows of the project if they are living inside of the wall components/groups and you cannot easily edit windows and walls simultaneously if windows are not inside walls. But that process could be totally avoided if Sketchup’s classification methods would be streamlined.Īlso, the dependance of having an organization based on nesting and hierarchization of groups/components makes sense, but has limitations in what regards multiple selections and visualization of isolated objects. I personally use Sketchup as a BIM creation tool and complement it with BlenderBIM if needed. Meta data is a pain to insert and a tagging system as you had before would be helpful in helping us classify it automatically. It must grow into IFC 4 and it must evolve it’s exporting/importing capabilities, but it can be used already. I agree that sketchup isn’t only used as a BIM repository tool. Like an object that has been painted with aluminion should also be tagged as aluminium? Or an object that has been tagged with aluminium should be painted with that material? Materials are one of the informations that should be exported to IFC. However, some of these could also be automated. ![]() Having multiple tags should help us visualize objects, and also select them for some editions like painting them.Though having a window, roof, alluminium, big should be different than having a roof, window, big, aluminium. ![]() An even better classification based on multiple tag system should be considered.The auto classification of objects by tag, or the auto tagging of objects by classification is welcome, but it should work both ways.A merge with current functionality might be great. The concept of multiple tags on the same object is a good one and your previous plugin was trying to address it.(And we could significantly simplify the current degree of nesting required to reflect these relationships). If multiple tagging was implemented (per object), then we would have unfettered ability to organize our models with better fidelity to the actual nature of the underlying relationships, sets and associations. In fact, they’re not tags at all (at least in the commonly understood sense), simply re-named former SU layers (which also was problematic as an appellation, admittedly). The whole point of tags is to allow horizontal associations that don’t require a strict, pre-existing and/or hierarchical structure. The current SU implementation of tags is the only one I know of that doesn’t allow assigning multiple tags to a single object. ![]() This requires careful thought of which order of nesting makes most sense, whereas a set of tags does not need an order. Then the drawing element is only visible if all of its parent containers are visible, that means if I enable visibility of all these tags. Instead of assigning n tags to one drawing element, I nest it within n containers each with another tag. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |