I am having another go at trying to master DCs. Las time I tried, I gave up in frustration. I found it very difficult and, frankly, not useful enough for an end user (quicker to use a standard component and edit it - obviating the whole point of automation!). But I don’t like being beaten by something.
One problem I have encountered is that the names of elements within a component (sub-components) doesn’t seem to update when you change its name in Entity Info. So if you created sub-components that were originally identical to one another, then decided you need to make them unique, they are correctly identified with their new names in Entity Info and Outliner but not in Component Attributes. Is this another thing that only updates when you log out and back in again? That would be infuriating. Any way to update it on the fly?
One could go into lengthy detail about the naming system of SketchUp, but the short answer is yes, you can change the name at the top of Attributes by double clicking on it.
Someone correct me if I’m wrong- this “Name” you’re trying to change was created when the component was born, and is distinct from the "Name’ attribute, which you haven’t added in your screenshot. As a header for Component Options, this Name also serves as a placeholder for the Name Attribute until you add it.
*Please Note: A copy of anything can only belong to one component with that Definition (the name shown in Outliner and in Entity Info, not to be confused with Instance). For some reason, SketchUp requires the “Name” you’re asking about (above the attributes) to also be distinct. BEFORE copies are made (or delete them and Redraw as I did; see the .gif for clarity).
@bthomas3 Thanks, that works. I guess I assumed that the name that applies in Entity Info and Outliner would also be the one used by Component Attributes since (as you point out) it takes the name first from what was created. So what the system is in fact doing is taking the original name as its default but making a copy of it that is then unrelated to changes elsewhere. I guess there must be a reason for that but it is a bit unintuitive. If there is a reason, maybe it should add something (like a symbol) to the “birth name” to make it clear that it is something new despite having the same name.
Maybe you can help with another problem I have. In this model, I have tried to fix the position of the glass. Yet when I alter the size of the component, the glass moves in the Z direction. I cannot fathom out why.
While not required (I rarely set the RotX,Y,&Z attributes), it is a good practice to set the X, Y, Z, and LenX,Y,&Z attributes (you can add all 3 at once by clicking the header instead of the attribute). The Scale Tool is commonly used to more quickly modify components (to any size, in set increments, or to preset values), and certain modifications may leave you scratching your head when everything gets wonky.
All of your origins are currently the same as the Component’s origin, with Positive X pointing Right, +Y pointing back, and +Z pointing up. I generally do the same except with parts that will or could have a textured material (like wood grain). In that case, I’d leave all of your horizontal parts as they are and change the vertical parts so the “X” axis points down the long edge (pointing “Y” across, leaving “Z” to usually be the direction of panel thickness). All your grain will then point the same way, so even if it’s wrong, you only need to rotate your material 90 degrees.
A reference (“=1 light casement window DC!LenX”) can only “look” one level above or below itself. You need a Name Reference, like you’ve done, in order to look down the tree, but looking up is as simple as “=parent!LenX”. This is super helpful for swapping out parts with other parts (especially when the axes are set up consistently), and works as well for a jamb or rail as it does for an entire style of window.
(Your Question) I think the issue with your glass is twofold:
A. the Glass Component’s origin isn’t actually on the corner of the component, so click into the geometry, make sure you have it all selected (Ctrl+A or Triple Click or drag a big box), and move it to touch the origin. An offset origin can be useful, but not for your purposes.
B . DC Parts get confused, usually regarding placement, when you make changes from too far in. Basically, you want to select the parent of the one you’re working on, not the component itself, so it has a solid parent/shell to reference. I try to keep the ones I’m not working on collapsed, especially when the lists get long. Usually, Redrawing the shell sets everything straight, but sometimes you have to go all the way into the part and Redraw it, step out, Redraw that, and keep going all the way out. This happens frequently enough that I’ve set a keyboard shortcut (“~”) for the command.
SketchUp is really powerful once you get over it’s unintuitive quirks. I hit on most of the roadblocks that nearly drove me to drink early on, so hopefully they’ll keep you learning and playing. Hope this helps!
@bthomas3 Wow, thanks for that. A full answer indeed and one I shall work through methodically.
I can absolutely see why DCs were introduced and can see how useful they could be for, say, manufacturers (if any of them produced SU drawings). The disappointment is that they are time consuming to create and there is a very steep learning curve (quite unlike SU itself). The consequence is that you see very little take up(just go to the Warehouse, see how few DCs there are and how poor most of them seem to be). Also, the facility does not seem to have been updated since it was first introduced, in what you might call its beta version. Of course, the two things are probably linked: difficulty arouses little interest and little interest means developers focus on other things, in a downward spiral.
Those of us who do persevere probably have too much time on our hands…
I think dynamic components are a great starting place for people needing a little automation. I think though that most serious automation goes far beyond the basics (in both complexity and features) with the Ruby API. In fact DC is simply an extension that abstracts the user from the code involved in automating drawing using the API.
