Dynamic components made unique after scaling

scottlininger

hmm... what about custom attributes? In case the DC you replace with isn't identical?

What I do currently is:

Make a list of all custom attributes in the old component
Delete the old component
Insert the new component in its place
Make a list of all custom attributes in the new component
For any custom attributes with the same name in both components, overwrite the new values with the old. (So if there was something called "WoodFinish" on both, I assume that you want to preserve the old WoodFinish selection on the newly inserted comp.)
Fire a redraw of the new DC, so it makes itself pretty.

So I only copy over shared custom attributes.

Is the "Swap Component" readable or scrambled? (if I dig into the DC source code)

Scrambled. Plus, it's written in the context of being inside the DynamicComponents object, so I'd have to refactor slightly to make it work as standalone code. Happy to do it, but it might take me a few days to fit it in.

Cheers,

thomthom

I sure would be useful to get a multiple selection swap function working.

One additional thought though; would it be possible to use the existing function within a loop? instead of factoring and rewriting as a standalone, can it be called from an external loop which specifies which component it's to be replaced by?

cpseattle

@unknownuser said:

There was a lot of debate about this before launch. We wanted DCs to follow the rules of SketchUp as much as possible. So the question became: "If I have 3 DCs in a model, and I scale one of them, should all of them update? Or should only the one I scaled?"

I think you can imagine what the arguments on both sides were. In the end, we thought it would be more frustrating to have every instance in the model update instead of just the one you scaled.

We've talked about adding some kind of toggle that would allow you to choose which behavior you prefer. Any thoughts on that? Do you guys think we did it backwards? I'd love to hear your ideas.

Cheers,

wow, my posts never get so many resonses. As far as behavior is concerned, I expected them to work as normal components do now. I will often create a regular component that can be scaled in a single direction - like a comlumn or a step for example, so that I can stretch each to fit and still be able to edit them globally.

While it's true you can still edit the sub-components of a dynamic component, there's a catch. I had a window with mullions, for example. The component is dynamic, so that I can stretch it to be wider or taller without distorting the mullions, which works great, but I can't actually edit the mullion component, because it's size is fixed in the dynamic component so that it won't scale inappropriately (LenX =6", for example). I tried creating subcomponents with buffer room so that I could modify the geometry without exceeding a set envelope, but then I can't have a a plane of glass that properly references the mullion geometry.

I see two potential solutions:

A. A third instance type be introduced that includes edited dynamic components, and a function wherein dynamic components can at least be swapped and edits reapplied for each instance - scale, layer, etc. This may even be possible with some savy ruby scripting, but I imagine a unique naming convention for edited dynamic components would keep it from getting really messy.

B. A less preferred option but one that would work would be to introduce dynamic variables - rather than 'LenX =6"' maybe the syntax could be 'LenX =' wherein the length would always equal the inherent maximum dimension of the compoonent or group. This would allow changes to subcomponents that could effect other dependent subcomponents.

regardless, thanks for picking up the topic!

thomthom

hmm... is it possible to create a definition attribute? If so, you would link the sizes to this attribute. ...though, SU might still make the component unique... ...?

thomthom

@thomthom said:

I sure would be useful to get a multiple selection swap function working.

One additional thought though; would it be possible to use the existing function within a loop? instead of factoring and rewriting as a standalone, can it be called from an external loop which specifies which component it's to be replaced by?

Never mind. I just saw how it works. Since it prompts the user to select a .skp file it won't work.

thomthom

@unknownuser said:

@thomthom said:

I'm wondering, if the components are DC, will they scale properly if I copy the original transformation to the DC replacing the old component?

Well, not really. When you scale a DC with parts that position themselves, the parent component's transformation doesn't actually change... it's the parts whose transformation changes.

For example, if you make a window 2x wide, what really happens is that the window itself is set back to 1x wide, and then the subparts are transformed inside the definition.

So probably the approach you'll want to take is to apply all of the attributes (like LENX, etc) that are on the old instance to the new. There is a right click > Dynamic Components > Swap Component item in SU Pro that does just that, but only one component at a time. Let me know if you'd like some sample code to work from.

Cheers,

Just going back to this for a second. So if I apply a scale transformation to a DC, won't that trigger the DC to redraw in the same manner as if it was scaled using the Scale tool?

scottlininger

@thomthom said:

Just going back to this for a second. So if I apply a scale transformation to a DC, won't that trigger the DC to redraw in the same manner as if it was scaled using the Scale tool?

ThomThom,

Sorry for the late response on this one. I was on a business trip last week and am trying to catch up.

If you apply a scale transformation via the Ruby API, the redraw will not occur unless you tell it to. Here's a snippet of code that forces a redraw via Ruby, by getting a manual hook into the plugin:

$dc_observers.get_latest_class.redraw_with_undo(my_comp_instance)

Cheers,

thomthom

That's a very interesting snippet. Thanks.

plot-paris

I know, I am almost two years late for this. But I just had time to play a bit with DCs again. And I think the behavior is not ideally in line with a typical SketchUp workflow.

Firstly I think it is very important not to set the scale factor of a DC back to 1x when rescaling it. Ordinary components (and groups, for that matter. and even DCs without sub-DCs) keep their scaling information, enabling you to replace the component with a different one, therefore applying the custom scale factor to the new component as well. The workaround of introducing another function to replace a DC is a somewhat awkward, unnecessary step, that makes everything more complicated; in some cases it may even destroy the work of several hours (because you can only do it for one component at a time)...
So please keep the scale factor of a DC (or at least keep the information to apply it to another component when being replaced)!
Secondly the behavior of a DC becoming unique, when being rescaled. A DC without subcomponents behaves as an ordinary component does. It doesn't get made unique. Only when a DC contains dynamic sub-components it becomes a unique component when scaled.
In general I would say this behavior of becoming a different component when being scaled is not in line with the typical SketchUp workflow. An ordinary component doesn't become unique after all. So if one has a fassade-panel for example that fits any size nessecary (but is always the same type of panel, just with custom size) you don't want every single component with different scale to be unique.
However, I do see the benefit of it in cases where you want these components of different scales to be different, for example when having windows filling a few different openings (then you would very much like to select all windows with lets say 80cm width).
So there are two scenarios where one of those two behaviors may be preferrable.
Therefore I would suggest to have an option within the DC window to toggle the "make unique at rescale" behavior

I hope these suggestions can still find there way to Google, even if its two years ago that DCs were introduced...

halroach

@plot-paris said:

I know, I am almost two years late for this.

And I'm many many years later... (almost feels like "back to the future")

@plot-paris said:

So there are two scenarios where one of those two behaviors may be preferrable.
Therefore I would suggest to have an option within the DC window to toggle the "make unique at rescale" behavior

I hope these suggestions can still find there way to Google, even if its two years ago that DCs were introduced...

Any chance there is now a way to do these two different behaviors!?

hank

@unknownuser said:

There was a lot of debate about this before launch. We wanted DCs to follow the rules of SketchUp as much as possible. So the question became: "If I have 3 DCs in a model, and I scale one of them, should all of them update? Or should only the one I scaled?"

...In the end, we thought it would be more frustrating to have every instance in the model update instead of just the one you scaled.

We've talked about adding some kind of toggle that would allow you to choose which behavior you prefer. Any thoughts on that? Do you guys think we did it backwards? I'd love to hear your ideas.

No, you didn't do it backward or forward, you just didn't work it out at all. The only logical solution would be to scale the one DC WITHOUT BREAKING THE LINK TO THE ORIGINAL COMPONENT DEFINITION.

It is essential to design workflow to be able to go back and make changes to ALL elements throughout a project in a quick and centralized way. As budgets change, design options are accepted/rejected/marked up, and products enter or leave the market, the ability to edit a single entity and broadcast that change to all instances in the model could save hundreds of production hours.

I am actually really surprised to discover that this is how DC work and the whole scheme is actually intentional. I am not a programmer but I don't understand why this could not be fixed? User Defined attributes can already feed sub-entites data, like LenX for a certain sub-group can be set to the User Defined attribute "MyLength" so why should it matter if one DC has "MyLength" set to 20 when another is set to 30? I must be missing something here?

Revit and AutoCAD have this ability baked into Families and Dynamic Blocks already. The both use dimensional constraints and user-defined parameters to set the contextual "data" of an entity and objects within can be set to react to that context in different ways.

And I think a "Component Replacer" is more of a band-aid approach than an actual solution. If it could be written as a 3rd party script (I believe ThomThom already did), it would have to not just reset the definitions of all the bastardized components, it would have to note and re-create ALL of the attributes of every component in the model so that all the scaling, visibility, etc. of various components would not be lost in the re-writing.

Please tell me this has already been worked out in SU2017 or something and that is why there has been no further dialog on it!