For an architectural model I started to create DC windows of a certain style in a separate file. At a certain point in production when I thought they’re ready to go I 'save as’ed them, loaded them via the Components window to my master file, and they didn’t scale correct in Z dimension. They did work correct in the working file though, were I created them.
Doing the same in another file: They behave as intended.
Taking other elements from the master file to a new file, and loading the DCs: they work as intended.
It seems to me, the master file where I want to apply the DCs has some hidden DC ‘info’ whatever kind stored. I may be wrong though.
Is there any plugin to get rid of these kind of hidden DC info, if at all present. Or am I going wrong somewhere?
(Of course I did a ‘purge unused’ and really made sure they are visibly gone from the master file).
May it have something to do with SUs sometimes strange behaviour converting cm to inches? I always work in decimal, not imperial?
Also, it makes me wonder, when I at some point will create a newer version of the DC with more features, will I run into this trouble all along?
What is the overall workflow with DCs, of course including all work arounds that SU requires?
Pointing me to topics or giving actual advice on the matter would be highly appreciated.
Thanks in advance.
Ronen
If you want the window DC to cut faces, you need for it to be lying flat on the XY ground plane (which is the “cutting plane” within the definition’s entities.) You can move it down into the cutting plane if necessary.
Also in the definition’s model (before saving) you need to open Model Info > File and set the gluing properties and check “Cut opening”.
The situation is described in a very complex and confusing. If I understand correctly, the file you call a “working file” is attached, but the problem only appears in the file you call the “master file”. In this case, it should have been added as well.
I also work in the metric system, but it never bothered me. Especially if the problem only appears in one (Z) direction.
Well, I want to use the features of DCs. That’s why I create them.
But I don’t want imperfect DCs to crash the files where I actually need and applied them, without any chance of ‘updating’ them with correct, perfect DCs.
are you “reloading” the DC? or just copying over to the master? many times a reload of the DC yields different results than a copy & paste. if the working file could be imported as an entire component (e.g. your work file has a room all defined) then you import that into the master model which then resides as a complete component.
I placed your DC window in all window openings, scaled them to the required size, and in all cases I got the correct result. The manually adjustable dynamic values also work properly for any frame. Check the attached file!
When I find out that they’re not working in the master, my workflow is to delete all instances from the model and from the components list. Then ‘load local collection’, and try the new, fixed version. It was definitely the new version, and it didn’t work, only in this master.
Afterwards I tried copy & paste as well: no difference here in this case. (I had cases where copy & paste did a difference.)
What I didn’t do, and might have been the solution, close the master and reopen it, before loading a newer, fixed version of the DC.
It seems that closing the master and re-opening it before testing any new DC version make them behave well.
I’ll keep an eye on that.
I found this in this forum which seems to relate to the issue:
Right now, I still don’t know how the intended workflow of SU is using DCs, especially if I want to update them once in a while with new features while keeping their various recalculated attribute values in any applied model is.
The most obvious thing to try (as has been suggested) is to right-click either one of the instances, or the definition of the “In Model” collection in the Components inspector, and use the Reload… command. (A browser dialog will open so you can select the updated DC component file.)
There is an extensive chapter in the User Guide for DC use …
Do you acutally know? I tried, but as expected, it loads the DC without taking over the specific attributes applied to the instance of the DC…
The fact that in the dialog you may choose any other DC, or any other SU file already hints to it.
Any other design program would step in here and ask me if really want to replace the component with something completely else, e.g. something of a different size.
Context menu ‘Dynamic Component/ Swap Component’ does do it either. In fact I see no difference to ‘Replace Component’ from within the components window.
When you change a DC with nested DCs it will automatically become unique, a new definition, this is generally required as position is changed. So swapping and it updating is not possible as the they are different components, however you can swap and have attributes update provided you use an extra container and the current formula as per the modification
This done via the swap not the reload, and you need a script to do bulk swaps RSEWindFixDCvOne.skp (64.4 KB)
Thank you pcmoor!
I succesfully swapped them with the modified DC you attached.
If I may ask, can you explain a little deeper how you altered my DC?
Of course I studied it, tried to reproduce it, but I failed…
I appended my try. testcon.skp (385.5 KB)
In an example:
You start building a house. You roughly design a window of a certain style.
You create a DC out of that design, to apply this window design to the different window sizes on your house.
You continue editing your model, whatever, terrain, other elements.
You check back with your client, he wants the design of the windows to be altered or more detailed.
You want to/ need to update your initial window DCs.
Their tree might get more complex. You may add a feature to cycle through materials. Therefore, you might add the Material Scaler to groups or components inside the DCs tree.
But the basic variations for all windows stay the same, they have certain height and width.
My general questions for a workflow like this would be:
What would the worklfow for the example look like?
When creating DCs, and having in mind, that at some point I will update them or add features to them, what do I need to take care of regarding their tree in the outliner?
Follow up to question 1: Or I need not take of anything, and rather build the update in a certain manner, e.g. using a container?
What are the limitations?
Should I use components in the DC?
Should I use DCs (nested) in the DC?
Or rather stick with groups inside the whenever possible?
Isn’t there any thorough guide or tutorial somewhere for the use case outlined above?
Of course, SketchUp Team should be in charge here, because they’re the authors of this plugin, but maybe it’s even better having someone else write it, as he would not presume anything.
It’s kind of tiring that with SketchUp you always have to figure it out yourself…
Again, any help is truly appreciated.
So you can create all window, door, structural elements… DCs with this ability if required.
Please consider the instance method of labeling and notation, which means you do not use “Name” attribute nor change the header in the attribute dialog.
Dynamic components are the safer option, dynamic groups can be considered, but they should only be on the lowest level, and copies of groups with a scaler can be problematic
I understand Live components are likely to take over, in that they will receive the development whereas DCs will not be developed any further; so DCs require the use of ruby scripts to overcome their short comings. You need to decide if the investment is worth while. Personally I would give a go, then reconsider when live component authorizing tools are released, it maybe that there will still be a place for DCs.
Well, I am on a trial with SU 2021. I have an offer for the subscription. But my general mood right now is to stick with SU 2019. I have lost so much time due to the inconsistencies of SU, that I am not really ready to follow along the misbehaving of SU any longer.
Anyways, I will have look into the Live Components.
Thanks again.