Dynamic components - creating dc variations workflow?

[gsharp]

What is the best practice for creating a DC from and existing DC? (in particular METRIC DC’s)

Background - I am creating multiple DC variations of a door. They will have similar variables (attributes) and formulas

but also have different elements and materials.

I want to minimise the amount of scripting by reusing DC script structures that are common to all

But I am aware of the many comments on the forum about the buggy handling of attributes and units in DC’s

and the risk of hidden data and common attribute names cross contaminating attributes in DC’s.

But I still haven’t found a clear workflow documenting what is an agreed best practice.

Accordingly, I have outlined different approaches that I have considered below

1. Don’t do it ! start each DC as a brand NEW file from scratch
2. Create an instant of the DC and modify it in the same file but SAVE to a new file after editing the instant
3. Create a copy of the original DC, SAVE it as a new file, EXIT and OPEN the new file and edit into a new DC.

Please feel free to recommend an approach.. Or suggest a better workflow!

I am aware of DEEP MAKE UNIQUE extension but only have a vague idea of what it might do
and cannot find any clear instructions of what it is doing? and when it should be used !
I have it installed but it has never been an active selection in my context menu (which would be the only hint to me of when it might be appropriate)

Now none of the above processes above is discussing the separate task of saving (SAVE AS) the DC into the Component Library..

Which adds another layer of confusion due to there being two SAVE AS commands in SU!

and it is not clear in many forum discussions which is being referred to!

PS: I sent this post to CHATGPT… attached below is the detailed response..
DC WORKFLOW.pdf (151.8 KB)

@pcmoor I did see your response in Feb25 and thanks.. knowing your expertise in DC’s that is what I will adopt now seeing your clear explanation of what DEEP MAKE UNIQUE actually does!

Nevertheless I will leave the post as it might trigger other workflow suggestions.

It is surprising that such a obvious DC workflow has not been clearly summarised until your response in Feb..

PS. ChatGPT didn’t suggest that workflow

[pcmoor]

Approach 3 (Modified & Enhanced):
Create a copy of the original DC file, SAVE it under a new name, CLOSE SketchUp,
REOPEN the new file, and then begin editing the DC.

THIS IS FALSE, changing name does not make it unique, copy the DC in same file, then make it deep unique, can then change definition name and saveas to new file. Deep unique is important for groups, which are required for OCL unlisted parts. Whenever you copy a DC in same file, always follow by deep unique.

[gsharp]

thanks Philip.. I will adopt the DMU process … but still not clear what DEEP MAKE UNIQUE actually does? do all the attributes in a DC have a visible name and value and a different (hidden) internal name and value.. ? if you have a DC with three levels, surely SU assigns unique ID’s for each level and each attribute on that level and if you copy and rename that DC the unique new name would flow down to all the attributes below it.

eg
DC called DOOR1,with door handle called HANDLE, and a key called KEY (DC Definitions)

LenX saved internally as DOOR1!LenX (level 1)
LenX saved internally as DOOR1!HANDLE!LenX (level 2)
LenX saved internally as DOOR1!HANDLE!KEY!LenX (level 3)

then if the DC is renamed DOOR2, then it replaces the DOOR1 name and all are still unique?

“OCL” = ?
So Option 2 is ok as long as your immediately run BMP immediately on copying the DC?

[pcmoor]

The DC is an instance with a definition, when you ship an instance, the definition goes too; you may rename it, but the definition identity is still the same, you may add for formula, or whatever. It will function well unless you place it with the DC you first started with, or another with the same definition, the first placed DC will override the next placed one, that is the first placed definition will have precedence.

A DC with a sub DC, will on redraw become unique, the parent will become unique, but the child will not, unless it has a sub DC

make a cube a component, open and make the raw geometry a component, close
copy and make parent unique
the child is not unique

OCL is Open Cut List, I recommend using this for material handling, lists, and schedules as it reports only visible components and not groups. The next release will have better DC attribute handling but can use ruby via NAME attribute for now.
This saves a lot of DC work, not to figure material, visibility and custom attributes in the native report writer.

[gsharp]

As a follow up Philip,

If you forget to run DMU on creating an instance from a DC, is there any way of executing or cleaning the instance DC later ?

[pcmoor]

Yes, you can!

Place the DC in new file, copy it, then right click one of the DCs and deep make that unique and then “saveas” it to overwrite the original DC definition

Besides the right click “saveas”, DCs can be dragged and dropped from home folder to any selected folder

[gsharp]

Thanks, just to be clear.. the SAVEAS is the pull down menu SAVEAS? or the right button context menu SAVEAS… this is often not clear when people discuss DC’s and the both have different implications when used with DCs.. ie keeping the attribute and option menus accessible..

[pcmoor]

right click context menu “saveas”