I’m just learning how to use dynamic components. Perhaps I’ve misunderstood how they should work, but I was under the impression that modifying the “Component Options” should be possible without SketchUp forking a new component. For example, I have a dynamic component with an attribute that controls its colour. If I make a duplicate of this component and change this option for one of them, SketchUp automatically creates a new component, so if I then make any changes to the underlying structure of one of these components, those changes aren’t reflected in the other.
Am I expecting too much of SketchUp or is there something I’m doing wrong? Ideally I want to be able to change an attribute via ‘Component Options’ (such as colour) but have the underlying components remain linked.
That’s the way it is supposed to work with DC’s. With non-Dynamic Components edits to one instance of a component changes all other instances, too. With Dynamic Components you get separate definitions. That allows you to do things like have different sizes of the same window type in your model. If it didn’t separate them you couldn’t change the dimensions of one window without changing all of them.
Thanks Dave. So there’s no way to link the underlying structure of these components?
Specifically, what I’m trying to achieve is a system for designing a fruit orchard. Each tree has attributes relating to its total width, height and colour of fruit. I know that it’s possible, for example, to have two non-DCs be different sizes (using the scale tool), so I assumed the same logic applied to DCs.
Once I’ve designed the orchard I may want, for example, to slightly tweak the underlying appearance of each of the trees. From what you’re saying, it sounds as if this won’t be possible?
Provided the nested levels are not dynamic then there is no unique trigger, so if the parent is the only dynamic entity then there should be no update to uniqueness.
Thanks very much pcmoor. In the end I created a dynamic tree who inherits all its properties from the parent. That way, I was able to place the dynamic component inside a group, and change the options on the group, without affecting other DCs. Thanks again
Hi, I’m also learing to use Dynamic Components, a great feature! And I came up with the same issue as CaptainProg. The simplest example I found to reproduce it:
Create new model.
Add two instances of the “Frame” example component, the one inside Components → Dynamic Components Training, made by SketchUp.
Scale one of them. After this step, a copy is made, named “Frame#1”, and the defitinion is duplicated.
Intuitively I would expect it to reuse the same definition.
Reading the thread, I understand that it has something to do with dynamic components nesting? What would be the right way to achieve nested dynamic components reusability?
See what @pcmoor wrote. Since the frame is made up of dynamic sub-components Make Unique gets triggered. That’s part of the design of DCs and it can be very powerful. I guess to do what you are expecting, you could need to use non-dynamic components to leverage using a single definition.
I have tried using various ways of grouping but I am convinced you have to accept the uniqueness thing and work with it
If naming is the issue then either force all components to unique(embed a “scaler” most useful as a swatch and material scale re-setter) then use #number as a placement number.
and/or use the instance name to have match option and attribute dialog headers. (which means you cannot use the “Name” attribute or change the attribute dialog header and use parent! for references)
File size is another issue, so make DCs simple and swap-able or if complicated, have a method of simplification.
You should consider running some ruby scripts along side to achieve some of your goals. Like a script that deletes all hidden options and freezes the option input, thus making the file smaller and changes can only be made by swapping the affected DC instance with its definition.
I use Ruby scripts to better my DC use for … access, placement, orientation, scaling, material selection, simplification,…
Thanks guys, I think I understand a bit better now. My main concern was no naming or file size, but the fact of having copies of the same definition (if you have 10 copies and you want to change the logic, you need to do it 10 times).
But what I see is that the definition of the inner dynamic components (corner, extrusions), are not duplicated, so effectively the definition continues being only once (because the important logic happens in the subcomponents).
Still looks unintuitive to me (thinking as a programmer, it looks like your classes are copy-pasted, which is always a bad practice), but it is not a limitation.
The DC system was grafted as a plugin on the existing component model, so every time the DC is modified in a way that changes the internal structure of the component (like non-uniform scaling or subcomponent positions) a new component definition is created. AutoCad uses another awkward system where the instances of dynamic blocks are anonymous blocks.
