I have heard about only working with components in a workflow. What are some of the pros and cons of a workflow of this nature? Could anyone shed some light on this?
1 Like
For my workflow, repeat my workflow, I use only components, no groups. There are many reasons.
The easy one is that editing one instance of a component results in all other instances in the model getting the same treatment. Less work than if the things were all groups.
- Consistent modeling. There’s never any confusion as to what something is in my models. They are always components. I see complaints from time to time that users forget whether they made a group or a component. They make multiple copies of a group and find out later that they wish they’d made it a component. Or they forget they made it a component and wish it was a group. Both of those situations result in more work. I never have that problem.
- Outliner is useful because every component gets a different name, even if I let SketchUp name them. Outliner is basically useless when ever entity listed has the same name.
- Component origins can be placed to make inserting instances of components dead easy. No such option for groups.
- Components can be given gluing and hole cutting properties. Not groups.
- Components are collected in the In Model Components collection. You can drag components in from the Components panel and easily place them where you need them.
- Components can provide backup when things go pear-shaped. Ever notice that Erase and Hide are next to each other in the Context menu? Select either one and the appearance on screen is the same. Fat finger it and hit Erase when you meant to hit Hide. Then, tomorrow, you want to unhide the thing only to find out it doesn’t exist. If it was a component, drag another instance in from the In Model collection. If it’s a group (and it was the only one of its kind) you will have to redraw it.
A long time member of this forum and Sketchucation once had a crash. When he reopened the SketchUp model, the entire workspace was empty. He’d used a mix of components and groups. All of his components were still available in the In Model collection and he was able to bring them out into the model space. He only had to rebuild the groups. This is fortunately it seems to be a rare thing but I know of another fellow who had a similar experience except he used only groups. In his case, he had to start from scratch and redo the model. He did manage to have it done for his presentation the next morning but he pulled an all-nighter to do it.
7.The Dave Method works with components. It doesn’t work with groups.
8. Components have description fields which can be leveraged with labels in LayOut.
9. Components can have advanced attributes.
10. Components can be saved in collections for later use.
11.Components make it easy to do symmetrical modeling. Aaron’s Ironman Helmet from last week is a good example.
12. Component Descriptor works with components.
There are more pros for me but I’ll quit with an even dozen.
The cons I hear from others which are never an issue for me:
The In Model Components collection gets filled up with components. I don’t see that as a problem. They are displayed in alphabetical order. If they are given appropriate names, the one you might want is easily found and I’d much rather have components of all the parts of the model and be able to access them there than risk loosing groups and have to remake them.
“I edit one and the other copies get edited too because I forgot I made a component instead of a group.” I see this as a complaint about having an inconsistent work flow. Even with huge numbers of components in my models, it’s not a problem for me. And I know when I need to use Make Unique.
Some folks teaching new users say to make a component only if there’s going to be more than one copy in the model. If there’s only going to be one, make it a group. What if that one group is the one you erased instead of hid?
There’s also the “make it a group first and then make it a component” camp. That’s like saying, I’m going to paint my walls red but first I’ll paint them pink. That’s a work harder not smarter sort of thing.
Fortunately SketchUp allows those who want to use groups instead of components or use both, the option.
15 Likes
@DaveRpretty much covered all of it… MY workflow would include using Components for “parts” and groups for “collections of parts”. I am sure Dave would use Components for both, but one of my favorite things about SketchUp is that there are so many ways to do any one thing!
6 Likes
I agree entirely with @DaveR. Just for the sake of balance, I’ll list a few of the alternative views I’ve seen argued in the forum, and rebut them where I disagree.
-
“Dealing with the create component dialog slows down my workflow. Groups don’t impose that burden”. Personally I’ve always found this one hard to swallow. The time difference to hit return when the create component dialog pops up is infinitesimal and the need to move that fast suggests one isn’t really thinking much about model structure or semantics. In the models I build, almost every object has multiple copies that need to match, so it is faster just to use components in the first place without even considering groups. Components also can be named when created, whereas groups cannot. But, to each his own…
-
“Components hurt SketchUp performance compared to groups”. It is true that a large number of components will cause the component browser to become clogged and sluggish. I think that an equal number of groups vs component instances will have the same effect on the outliner - either will clog it up if large enough. So that’s a toss-up. Another reason I’ve heard from an extension developer is that each time you add a component SketchUp generates a thumbnail of it to show in the component browser. Groups do not have thumbnails, so they don’t pay this penalty. Evidently if an extension generates hundreds or thousands of distinct objects it is a big penalty.
-
“Components bloat file size more than groups”. This relates to the last point in the previous item: if the model contains a very large number of distinct components, all those thumbnails stored in the file will increase file size. Aside from the thumbnails, there is a small amount of extra data for components - e.g. the load path. It will be important only if your components are very simple, containing a small number of edges and faces.
1 Like
“Components hurt SketchUp performance compared to groups”. It is true that a large number of components will cause the component browser to become clogged and sluggish. I think that an equal number of groups vs component instances will have the same effect on the outliner - either will clog it up if large enough. So that’s a toss-up. "
This is a valuable point.
I’d like to add that too many components makes the Components browser very slow to open and view and this becomes highly problematic on large models. Also when opening a SU file it can take forever.
It would very very useful to know more about this as it relates to large models.
Does SketchUp’s internal referencing system handle groups and components differently?
If a model has 1000,000 unique groups, does that behave any differnetly to having 1000,000 unique components?
What about if you have 1000 unique groups but each group is used 1000 times. IS that any different to 1000 components with 1000 instances each?
1 Like
I concur w Aaron for my workflow as well. Importantly, imho, SketchUp offers both organizational “containers” to utilize.
Both inherently have advantages and disadvantages for any one individual or office workflow and procedures.
As @DaveR points out there are many benefits of components and I believe, for one just starting out w SU, components are the right point of begining.
In my architectural modeling I rely a lot on both groups and components. Everything you can buy of the shelf, e.g. doors and windows, are components. If I change one instance, e.g. replace the door handle, I want that to happen with all similar components. I also want to be able to count them.
For things built on site I typically use groups. Imagine I make a floor slab, copy it, and make a hole for the stairs to pass. In such scenario I don’t want that change to apply to the original slab. The two was identical until I edited one, but they were identical by chance rather than by definition. The same applies if I copy the slab to form a new level.
Typically I’m not interested in counting the slabs and see I have 1 occurrence of slab A and two occurrences of slab B. Slab “type” B isn’t really a type, just two slabs with no relation that happens to have the same measurements. The exception is if these objects are prefabricated. Then I’d want to define two distinct slab types and ask the factory to produce 1 slab of the first type and 2 of the other.
5 Likes
I’ll 'fess up and say that I have encountered this as a problem myself. Fortunately, there is a neat little extension that helps alert you when you edit a component. It’s called Edit Flag and you can download it from Sketchucation. If you edit a Group, no warning. But if you edit a Component, a dialog box pops up and tells you how many instances exist. It’s a little clunky but it works.
If you follow Dave’s workflow, you wouldn’t need to know if something was a component because everything is. I am not sure how he knows if it is a unique component or not but I am just as sure he has a way!
3 Likes
Keeping Entity Info always visible is an important part of an efficient workflow.
11 Likes
With selection toys, you do not need to bother what it is. You can switch vice versa and have best of both worlds, all the time.
I tend to stick with the original, If it is a repeating thing, make it a component, otherwise, use the not interupted way of making groups.
Thank you @thomthom
4 Likes
For parts of dynamic components I prefer to use groups to avoid them clogging the component browser. Also, using the same component inside a DC and outside it is a recipe for disaster.
2 Likes
I’d just like to Hazard a warning in that Selection Toys can only convert Group copies into ComponentInstances as long as their link haven’t been broken. If you open one of your group copies that is enough to break that link as SU will make it unique automatically.
Personally I tend to work with Groups as default. Then make components on demand if the object I work on needs to have multiple copies. Key objects I always name - same thing for materials - semantic naming. That makes it easier to find them in the component/material browser/outliner. (And I set all my material/component browsers to list view as I find looking for the correct item via thumbnails to be too unreliable.
3 Likes
In my production/warehouse/building design I use both components and groups. Anything that can be reused (parts, desks, columns, equipment) or re-modelled/detailed by someone else (working areas) - Components. Groups - things like slab (as it is one in the building. But will re-name the entity name to have its name in Outliner. Note - People, USE OUTLINER!) or if I just need to groups several objects to move/rotate them easier. Basically - for easier manipulation when I specifically don’t want other copies to change as well (and don’t want to hit “make unique component” every time).
Why I don’t use components for everything. Mainly due to how Components Browser in SU works (“in model”) - having hundreds of items in the list makes it unusable.
THANKS! simoncbevans for the tip about the “Edit Flag” plug in. That’s a real help. I’ve never understood why “Make Unique” is not the default. Or at least an option of being the default. (anybody want to write that plugin?)
I draw cabinets, so I copy/paste a cabinet, hide the rest, zoom in then start editing, at which point I can’t SEE the original component. Often, by the time I notice the error, I’m already 5 cabinets down the road which means starting over. I understand the power of components, but with great power comes great potential to do harm.
One of the first thing we teach is to have a shortcut for editing: Hide rest of model.
It is found in the Model Info panel in the Components tab.
4 Likes
It is for groups. That is what groups are for.
Whilst I like the Edit Flag, it could certainly be improved. It doesn’t need such a large dialog box and I would prefer it if it didn’t pop up on top of icons I make regular use of (meaning I have to close it or move it). Also, it has a safety feature built in that prevents you from immediately interacting with your component without first clicking on it again. I would like to be able to turn that off as I find in unnecessary and quite irritating. According to Sketchucation, the plugin has not been updated for five years so maybe it’s time.
I think it has already been pointed out (quite gently) that you don’t really need the plugin if you use the native tools properly. Keep Entity Info always in view and it tells you whether you are working with a component or group and how many instances exist.
I fully agree what Dave has written.
I use groups only for one purpose. To subtract or intersect two groups to create a new entity.
Even when a “constructed” group is created it is converted to component immediately for the reason described by Dave.
1 Like
A warning that you are editing a component should ideally not be modal at all, just a small text in the corner of the screen. It would be enough to shift the graphical center of gravity, meaning you notice it, but not be disruptive.
Extension developers have long asked for a way to draw to the viewport like this outside of an active tool, but so far nothing has happened.
2 Likes
I don’t understand the term modal but I wonder if this is possible? When you open a component for editing, you select it with the cursor arrow and double click. What about having a small context popup off the arrow as a warning?