Need Advice About This Advice [Groups or Components?]
-
Steve, I'm glad to hear that it is helpful. I hope you discover all sorts of ways to leverage components to your benefit.
-
Dave and Rich
I see what you mean "they are in the same place". I use a plugin that makes bolts, and now I see that all the bolts are being placed on top of each other when I use the replace component. Well, I'll be darn. Going to have to try and figure this out.
Well, thanks all for the help. I just never thought about all the components being stack.
Thanks all for your input. Now I am going to see if I can figure out the plugin to correct this problem.
Thanks again for the fast answer
Ken
-
One thing to be aware of is what happens when using the Solid Tools in the Pro version. A subtract operation between two components results in the component having something subtracted from it, becoming a group named "Difference" and as such will not show up in the components window (assuming one instance only) - you can see the modified component which is now a group, in the Outliner however, and of course you can convert it back to a component.
I'd prefer it if SU kept it as a component and simply renamed it with the original name plus some suitable suffix to indicate it had been modified. It caught me out the first time when I modified a component in a model space having lots of model instances so I got quite disorientated at first.
-
Chris, you are correct about the Solid Tools. I agree entirely with you. The Solid Tools also don't change the other instances of the component which I think it should do.
I pressed for that at Base Camp and have asked several times since for a change to the Solid Tools so that if the action is performed on a component, it remains a component and all instances of the component get the same change just as if you edited a component in any other way.
-
I use groups for objects I'm not repeating and don't need to Reload. I do that because I try to keep the In Model component list to a minimum.
I keep the component list in listview - displaying only text. (I rarely find thumbnails useful.) I also try to name every component so it's easy to find in the component list - and Outliner.
(I also keep my material list in listview - applying materials by descriptive names rather than visual appearance. That makes everything much more manageable - essential for when you constantly need to revise a model.)It's not an either or matter between groups and components - they have different purposes - though on occasions it can appear. Using just components over groups seems as counter-productive as using just groups over components - IMO. One isn't single-handedly better than the other.
My rule of thumb is:
If the object is repeatable, make it a component. If not make it a group.If I am unsure I often start with a group - then if I find that I need to repeat it, I convert it into a component. (Component to Group is not so easy. You need to open the component, group the content, then explode the component. Quite a few extra steps. Which is why I usually start with a group.)
I should also mention that I always have the Entity Info window open - giving me information about what I have selected. I only need to do a quick glance at it to figure out of I have a group or component. Thereby avoiding accidental confusion.
-
@dave r said:
Chris, you are correct about the Solid Tools. I agree entirely with you. The Solid Tools also don't change the other instances of the component which I think it should do.
I pressed for that at Base Camp and have asked several times since for a change to the Solid Tools so that if the action is performed on a component, it remains a component and all instances of the component get the same change just as if you edited a component in any other way.
Ditto!
-
@dave r said:
I've read comments about components cluttering up the In Model Components library. So what!? If you delete components and really don't need them back, purge unused. I run the Purge All plugin with a single keyboard shortcut which purges all unused stuff--and it purges unused components before purging unused materials so it takes care of all that, too.
It's not a matter about unused components. It a matter about unique objects that will never be repeated in the model being listed in the component browser.
For instance, if I have a few hundred unique buildings for a siteplan model I do not want them listed in my component browser. I want the component browser to list only the repeatable accessory object like cars, trees people etc. Often for a building I have a set of windows at different dimensions - I name the components according to specs to I can pick them from the list when I need to insert a new window - or replace one. Even just the useful components quickly pile up to a long list so I try hard to prune the list. -
Jim made a tool to 'correct' the unexpected behavior of the Solid Pro Trim/Keep operations - http://forums.sketchucation.com/viewtopic.php?p=356575#p356575
I agree that is should work as you've outlined for all of these tools, or at least offer the option on completion... -
Thomas, I appreciate your position. As I said at the beginning, I never tell anyone not to use groups. For my work, they just don't cut it. It's nice that SketchUp is flexible enough to allow different methods.
TIG, you're right. Jim's version of Trim is much more desirable. If the Google folks won't change the tools, I hope Jim will make the entire set.
-
Whether you use Groups or you use Components - the lesson is please, please, please, USE them!
Because Geometry sticking together when you want it to is great - it makes editing easier.
BUT Geometry sticking together when you DON'T want it to is pure pants!So understand and use how Groups/Components will separate geometry.
Conversely, understand how Layers do NOT separate geometry, and that Layers are intended to control the visibility of geometry that is inside a Group/Instance by using a specific layer for the 'container' and NOT the 'contents'. Assigning Layers to 'raw' geometry is a speedy recipe for insanity...
-
I think the conclusion can be no other than... use components when you need them. Groups are better!
-
@jql said:
I think the conclusion can be no other than... use components when you need them. Groups are better!
Let's agree to disagree on that.
-
@jql said:
I think the conclusion can be no other than... use components when you need them. Groups are better!
I hope you didn't need 987 days for this conclusion?
-
@cotty said:
@jql said:
I think the conclusion can be no other than... use components when you need them. Groups are better!
I hope you didn't need 987 days for this conclusion?
Ah! Unfortunately I just read this post yesterday!
Alas so much to learn, so little time!
I will use components someday this way... I... will... evolve! (it's just so dificult!)
Advertisement