Erratic Duplication of Dynamic Components?
-
Hello All,
I was saddened to find out that a Dynamic Component (a door) I have been working on is duplicated and/or made unique when I change one of its parameters such as width or height. A quaint #n is added onto the end component name to mark the event. This really stinks because it means my ability to push changes to multiple DC instances from a single definition is effectively lost every time I change an instance's parameter.
To put it in concrete terms, say I start a project with a certain 8 paneled door DC. I design the whole project, setting various doors to different heights and widths, and the client decides they want single panel doors, or doors with circular windows, or scrolls, or whatever on them. I can't push that change to all the doors! This seems to defeat the whole purpose of components!
HOWEVER, I also have a wall component that DOES NOT seem to exhibit this behavior! I can have 10 walls in the model, all set to different widths, and they ALL remain linked to the original component definition. I can go into that wall component and add a column or whatever random shape and it shows up in ALL the instances!
So what gives!!??
As a test case, would anyone take a look at the attached file, make changes in the Component Options for each and watch the Outliner panel as you do so. Do you see the same result?
What is it about the two DCs that make them behave differently? Are there certain "rules" that the wall DC follows that the door DC does not?
-
the wall component, although has a nested group, this group has no changing attributes. You will find any one level DC will not be made unique by SU operations unless you do, it is the nested changes that cause this. So one designs to take advantage of the differences. I make a complicated DC with various nesting able to be simplified via explode, outer shell to a one level component (which can be replaced with its original or another), so copies remain same, this has added advantages for material reports, file size, intellectual protection if shared, material painting....
-
Thanks @pcmoor I see what you are saying...
The WALL DC has only dumb objects in it with no parameters.
The OPENING DC has sub objects that use parameters.
But this seems insane! You mean, the second you take advantage of parameters for your sub-objects you loose the ability to have central command of your DCs?!!!
Perhaps you can explain your modeling techniques more? So you have a DC you copy around a bunch of times the explode it? Doesn't that kill any link you have to the original definition?
Advertisement