Dynamic components made unique after scaling
-
which undermines any advantage the feature may add.
I could live with this if the swap function replaced the scaled
component with a new component of the same scale (as is the case with
regular components).can anyone enlighten me as to why this is the case, or whether anyone
has written a script that will swap (or reload) components with a
matched scale?this feature was so close to being genius. I don't get why they
couldn't take it one step further. -
I don't have version 7 handy and I don't exactly remember how this works. So the idea is that you have a DC. Lets say its a window. And you have inserted 10 of these windows. If you scale one, it is no longer the same component as the others? I think my brain is tired right now, because I'm having a hard time thinking through the pros and cons of either scenario right now. I'll play around with it when I get home onto my own computer tonight. Anyone else wanna jump in?
Chris
-
As you noticed, scaled components do indeed become unique. Sub components can still be edited as normal components though.
I dont know the reasoning behind it, but id take a stab and say that it is because they are different from the original, therefore unique.
As for the swap thing, if your components are scaled the same you could have just copied them from the original, although im guessing its a bit late for that now.
-
@remus said:
I dont know the reasoning behind it, but id take a stab and say that it is because they are different from the original, therefore unique.
That's exactly why. Remember that DC's are implemented with Ruby. So they have to follow the same rules as if you where modelling it your self. And you would have to make the components unique to do that.
If you have a DC windows that 1200x1200 and you have one thats 2400x1200, those are two different things. As in real life. The benefit with DC's is that you have a set of rules for how the components are generated.
However, I see the need to Select All DC of same Type. And Replace DC Type. I'll dig into it and see if I can add it to my Select Toys plugin.
-
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,
-
I don't think that every instance should update. I think it should behave as it does. At least in my work it's a great benefit. I work for an architectural office making visualisations.
Before DC's I had to make a unique component for each window size, even though they where the same family. With DC's I can set up one DC, which defines the style and rules for how the object should look.
However, it would be a great addition if you could replace a DC family with another. Say, I want to change all the windows on one floor with a different type. The DC's are the same family (derived form the same DC, but different sizes). It would be very nice to select just the windows I'd like to replace and have them updated with another type. I'm thinking that the new type of components sizes to fit the size of each individual component it replaces.
Also: is there a way to work out if two components derives from the same DC? I'd quite like to incorporate into my Selection Toys plugins a method that allows you to select all components of the same family type.
-
Im guessing theres a reason you cant just use the component name to identify similar components...
-
@remus said:
Im guessing theres a reason you cant just use the component name to identify similar components...
Not for for similar DC components. They get renames when they are resized and made unique.
Say you have a DC named "HelloWorld".
If you place two instances out there and scale one of them, the scaled one will be name unique and given the name "HelloWorld1". You could do a string pattern comparison to check for instances beginning with "HelloWorld", but it would be reliable as they might have been manually renamed by the user.
So some other method has to be used in order to identify whether two components derive from the save DC. -
@thomthom said:
Also: is there a way to work out if two components derives from the same DC? I'd quite like to incorporate into my Selection Toys plugins a method that allows you to select all components of the same family type.
There is an attribute dictionary called "dynamic_attributes" that contains all of the DC attributes. You'll find it attached to each DC definition.
Inside there you'll find an attribute called _name and a timestamp that is updated each time a DC is altered via the Component Attributes window. These should be sufficient to determine if things are related (though it could also lead to confusion if you happened to base one family off of another... so it might not be what you're looking for.) If you want something more explicit, you might want to just create a DC attribute called "Family" that is your key for doing the work.
Sounds like a fantastic script idea. Let me know if I can help. PM me if you need any offline advice.
Cheers,
-
Thanks Scott. That was rather easy to implement. Updated version of my Select Toys is up: http://www.sketchucation.com/forums/scf/viewtopic.php?f=180&t=14975
Next step would be to make a component replacer.
I have been thinking of a plugin which let you select a component, or multiple, then activate the tool which then presents a dropper cursor where as you can then click on any other component in the model and then replace all selected with the component you picked.
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? -
@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,
-
@unknownuser said:
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.
hmm... what about custom attributes? In case the DC you replace with isn't identical?
Is the "Swap Component" readable or scrambled? (if I dig into the DC source code)
-
@thomthom said:
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.
@thomthom said:
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,
-
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?
-
@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!
-
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 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.
-
@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?
-
@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,
-
That's a very interesting snippet. Thanks.
Advertisement