What is the point of attributes attached to **groups**?

Continuing the discussion from Glitch with creating Dynamic Components:

I’m taking this into its own thread. See the previous thread (linked above) for my mistake (asserting that groups don’t have attributes).

Here’s the GIF I made. I intended to show that groups can’t have DC attributes to rebut @gkernan’s post in the thread. Instead, to my surprise, I confirmed it:

While I could add attributes to the grouped geometry using the DC Attributes window,
I couldn’t access/change them with the DC options window. Now I’m trying to imagine a use case to use attributes on groups. And my imagination is failing!

Any use cases you might suggest, that involves attributes, where using a group would be preferred over a component?

Certainly - as a developer you might want to hide the code from prying eyes.

Of course if you know ruby you can always dig into the model and find the attributes.

How does choosing a group “hide the code”? Any formulas in the attributes will be visible - and editable - to anyone with Pro who downloads your model.

1 Like

Sorry - spoke too soon. I miss read what you said.

One advantage is that the component remains unique which may be to your advantage since copies won’t all change simultaneously.

Also - you don’t end up cluttering up the component window. So you can have 1 master component (container) and a bunch of groups and or nested groups.

It is my opinion that the SketchUp programmers have a valid reason for letting you use Groups as well as Components. So why not use them when it benefits your work flow. Obviously Groups are just tools and you don’t have to use them if you don’t want to.

Are you sure that you have accessed the DC when you select it for Options? I say that because I have noticed that creating a DC seems to create an extra layer of nesting without you knowing it. I don’t know why. But it means you often have to click to get inside the first level before you can access the options.

components (or DCs) should be saved via the right click menu, if you wish to access them without the file wrapper

The point is really to make groups of the sub parts, thus when they are internally copied via Copies and the number of copies are reduced, or if they are outer-shelled, exploded… to simplify the DC there is no residue that requires purging

1 Like

Do you mean by using Save As (see attached)?


Yes, here is a workflow:

It is better to have a ‘working’ file with your component(s) and use the save as to upload it in your component library (or 3D Warehouse)

1 Like

That’s helpful, thank you.

It may explain something else. Just saving the component normally creates a backup file as for other SU drawings. So when you look at your component browser, you appear to have duplicates of everything. I presume the approved method ensures this doesn’t happen?

You will be notified to overwrite existing file.
If you had it uploaded to the 3D Warehouse you get a choise to Update the component, or abort .

Note this post from yesterday …

Generally, as @Anssi said, group definitions are hidden from the “In Model” components browser list. (So this is a very big reason.)

Secondly, the DC extension engine treats nested groups differently than nested components, as to both browser visibility and where the DC attributes are stored. Basically you could say that the DC engine considers each group instance to always be unique and therefor always looks to the group instance for it’s DC attributes. But components may or may not have any unique properties. So the DC attributes can be stored in both the instance and definition DC dictionary, and any instance attribute trumps the same “default” definition attribute.

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.