Problem importing modified dynamic components

SketchUp Dynamic Components
1

I have encountered some unexpected behaviour while creating and importing dynamic components, and I am not sure whether I have stumbled on a bug, or whether my mental model of how these things work is not complete enough to anticipate SketchUp’s behaviour in a fairly complex (and possibly unusual) situation.

I built a rectangular window Dynamic Component for an architectural model I am working on. The Window DC contains a bunch of sub-components which resize and reposition themselves, and several of the sub-components contain nested components, with a maximum of 3 levels of sub-components. My workflow for creating and using DC’s like this window model is not to build the complex DC in situ in the full house model, but to create a working file in which I build my DC in the context of some critical elements like bits of framing, trim, etc., then once it’s all working as expected, I save the DC as a separate file, then import it into my house model and create all the various instances of it as needed inside the main model. It all worked as expected and saved me a lot of time generating detailed measurements of the parts for multiple sizes of my window design (so far so good).

I then needed to build a derivative of the basic window model (in this case, one with a raked top), so I opened my Window DC working file, saved it as another working file, and edited the Window DC to have the features I needed. Among other things, I changed the name of the DC so that once installed in the house model I would be able to easily distinguish the raked derivative from the rectangular original, and I made one of the side jambs unique so that they could have different lengths and renamed the two jambs (including “left” and “right” in their names). Once the geometry and formulas were all working, I saved my Raked Window DC to it’s own file, then imported it into my house model. One component of the imported Raked Window DC had some unexpected dimensions. To make a long story short (well, maybe I’ve already passed that mark), I determined that once having imported the original rectangular Window DC into my house model, the derivative Raked Window DC inherited at least one of the sub-component definitions from it’s rectangular ancestor. I was able to recreate this effect inside a new file by importing the two DC’s in different orders. The derivative DC was consistently altered by the presence of the original when imported into a new file, but the original seemed not to be so influenced by the derivative if imported second.

Here are some observations I made while experimenting with importing these components:

  1. Everything about the derivative component worked as it did in the working file where I made it, except that one sub-sub-sub-component was seemingly swapped for a corresponding sub-component in the original DC, holus bolus. The formulas changed to those of the original’s counterpart, and even after changing the name in the working file and then re-importing it, the name, formulas, etc. reverted to those of the original.
  2. The other sub-components which had been edited in the derivative DC imported with uniqueified names (Jamb#1, #2, etc.) as expected. Even though the problem sub-component had been edited in my work file, and the whole DC saved to its own file, once imported (in the presence of the original DC) that one sub-component’s attributes were stomped and it inherited the attributes of it’s original counterpart.
  3. Another highly-edited sub-component of the derivative DC experienced no such interference from it’s counterpart in the original DC. I cannot say for sure, but I don’t think I intentionally made that sub-component unique in my derivative file, so it’s not entirely clear to me why it did not also experience the same sorts of problems.
  4. It might be the case that the component-stomping behaviour only happens to the most deeply nested sub-components of a hierarchy of nested components.
  5. I was able to fix the problem by using the “Make Unique” command on the problem sub-component. After I did that, all parts of my derivative DC imported as expected: the problem sub-component was given an unique name and all it’s attributes appeared just as I had saved them in the derivative DC file.

I appreciate that all of this is difficult to follow, and I would be willing to upload my files for inspection and further discussion, but as a result of performing and saving this “Make Unique” manoeuvre in my work file, then saving it to my DC file, I no longer have the non-unique sub-sub-sub-component to do any testing with, and you won’t see the effect I’ve described. I have not taken the time to recreate the issue with fresh files, as it would be a fairly involved piece of work to recreate, but I am willing to give it some effort if it could help fix a problem in the software.

That said, I am not sure whether this is a problem with SketchUp, or with my expectations of how SketchUp should behave. If the former, I’d be happy to do my part in getting it fixed (testing, reporting, etc.). If the latter, I may need some help to develop a new workflow that is based on a better understanding of how editing, saving, and importing DC’s really works.

Here’s what I think is going on (but I could be way off as I’m only speculating about SketchUp’s internal mechanisms):

  • SketchUp must have an unique identifier for each unique component definition in a file.
  • By Saving As, then editing aspects of a component, it is possible to create two files, containing different versions of a component which share the same “unique” identifier.
  • When those components are imported into a new model, it is possible to have collisions of component definitions based on this unique identifier. It would appear that whatever definition gets imported first will prevail.
  • I expected the sub-component of the derivative file to become unique when I imported it, especially since its attributes had changed, but the effect seemed to be stomp on the new information rather than importing it.

I would have expected that once a component has been written out to two different files, then changed in one of those files, the two components would not be considered to be instances of the same component definition when imported to the same model. I can imagine instances where having a component definition transcend files in this way could be very powerful, but I can imagine it to be just as likely that doing this could be confounding and produce unexpected results, as it did in my workflow. I think I’d be happy with either of these behaviours if it was made clear what’s really going on and what to expect as the result. It would be even better if it were possible to choose between these behaviours with something like a “make all sub-components unique” command either while editing components or saving files. The ultimate would be that SketchUp could figure out that a not-uniquely-identified-but-different component was not the same as an existing component, and make it unique on import.

There remain a couple of things that make me a bit uneasy about the possibility of encountering this situation again, and that make me think that somewhere inside SketchUp there might be a bug producing unpredictable behaviour with regards to all of this:

  • I don’t seem to be able to predict which components (or sub-components) might be treated as unique when imported into another file. It seems that editing some attributes of at least one of my components was not sufficient to force it to be treated as unique when imported into another file, but, from what I can tell, editing some other attributes does seem to be sufficient. I think this because some of my derivative sub-components were treated as unique when imported, even though they had not been subject to the “Make Unique” command.
  • The effect of stomping on a not-uniquely-identified component on import doesn’t appear to be independent of the order of importing. That is, the presence of my original DC would cause the imported derivative DC’s subcomponent’s definition to change, but not vice versa.

Clearly, there are aspects of this that I don’t understand. My aim in writing and sharing this — beyond attempting to clarify for myself what was a pretty confusing situation for me as I experienced it — is to have some SketchUp gurus or insiders take a look at my story and my analysis, and to let me know whether this is an intended behaviour of the software (and if not, hopefully it will be fixed at some point), or to give some suggestions for how to avoid this sort of confusing situation by tweaking my workflow.

thanks in advance for your help,
Doug Ward

2

From my experience

If you want to change a formula for a DC sub component then you need to work with the original DC in situ, then make the copied parts unique before the change. Otherwise will update ( an action which can be used in the design in some cases, like when formulas are overridden by user input, one can reinstate the original)

Scaling is another issue, best to work from a known “rest position” and the formulas result in the same “grey” value, if you change the value, then scaling happens

Generally copying a DC without moving it, or forcing its nested parts to become unique, can reveal unexpected results as the copied children remains same, best to insert a new instance where the nested parts will become unique.

3

Yes I have experienced the same issue -I guess it is known.
I made the same conclusions.

Renaming parts is a problem
Instead make new parts

Just makes it harder to re-purpose DC’s Particularly when they have a lot of complicated formulas that have to be re-done.

4

I have lately tended to use groups instead of subcomponents inside my DC:s. This avoids the proliferation of component definitions cluttering the In Model components browser when every dynamic component that differs from its siblings in any other way than simple scaling will breed a new component definition, and using a component as a dynamic subcomponent in different DC:s will really wreak havoc.

Anssi

5

I agree with you. I use a combination of both as needed, For objects made of parts of geometry, I always use groups and double wrap in component so as they can be made to update in a swap. Sort of best of both methods.

I have notice that passing data to heavy nested groups programmatic. Using groups the “rest position” construction is very important, whereas with components one can scale the definition.

So I start with groups then make them component when they misbehave…“that will learn them”

6

Thanks everyone for your feedback. It’s reassuring that I’m not the only one who has run into these sorts of issues. @Anssi, @ChrisStewart, @pcmoor, and @jim_foltz have contributed several very helpful posts (here and elsewhere) on closely related issues that have given me lots to explore and lots of clues to help me understand how to design DC’s, particularly with nested groups and/or components. Your contributions have been an awesome resource for my learning.

There seems to be a lack of consensus on whether it is better to use nested groups or components inside DC’s in general. In my recent case, I started with most of my primary elements as groups, but after running into strange DC behaviours, I switched all the elements to components. That fixed a lot of the odd internal behaviour, but it is likely what resulted in the non-uniqueness problem I described above with the modified and imported DC’s. For now, I think I’ll go with Anssi’s and pcmoor’s advice and use both groups and components, then change them if and when it becomes necessary. However, that means designing and using DC’s is a little too much of a black art for my liking. As ChrisStewart points out, it makes it hard to re-purpose DC’s, which, for me, is extremely important in terms of getting my work done efficiently with SketchUp.

With all this unexpected behaviour that we all seem to find (or worse, NOT find) from time to time, I also wonder about how reliable these things can really be when released into the wild (e.g. via the 3D Warehouse), or in the context of collections of related components. Is there a failsafe workflow to ensure that DC’s won’t interfere with each other, other than to remake each one from scratch? I’m hoping this issue gets some attention in future releases, because Dynamic Components are incredibly powerful and in a lot of cases I can’t imagine getting my job done any other way.

dw

7

I have not encountered problems with either groups or components not re-purposed.
( I agree that there is a hidden identifier)

I suppose that there may be times when you want a shared sub-component to to be altered -generally (I guess) that is the only benefit of using component instead of group.

I said re-made from scratch but what I really meant was exploded so really only properties need to be re-entered. That is the key I think not just re-name but explode and re-make.

I do not think that it is likely that once the identifier problem is worked out that unexpected behavior will be a problem
Because you can have multiple components with the same name but SU is actually using that hidden ID.

This allows people to download objects from 3DWH with the same name but not have conflicts

At least that is my take on it. (but I may be misunderstanding the system.)

8

Hi, dougward, as I understand SU, it is made of a lot stand alone features. There is no quality management to harmonize them. That’s open source.

I made my dynamic windows this way.

Maybe that gives you a hint.

9

This topic was automatically closed after 91 days. New replies are no longer allowed.