FWIW, FlexTools includes a Make Totally Unique function as well as a couple of other useful functions. I can’t say I’ve compared the results produced by theirs vs. others.
1 Like
This method has been working for me. Previously I was taking the copies into a separate file and then changing them and bringing them back in - this was causing the issue described above.
By copying them, then doing a “Make totally unique” before saving out to the separate file, I’m having no issues re-importing the files or having components overwrite themselves
2 Likes
This is the best way to create families or collections and if one should slip through, the import to clean file, (move)copy and immediate “deep make unique” then replace the best fix
This totally makes sense as DCs are the base of FlexTools
1 Like
I’m currently developing a highly structured, professional-grade SketchUp kitchen cabinet library, inspired by the quality and organization level of InfoWood1992. This is not just a collection of models — it’s a fully systematized asset library designed for efficiency, scalability, and real-world workflow integration.
Key features of my approach:
-
Easy searchability – a clear, multi-level folder hierarchy with logical categorization that allows finding any cabinet type within seconds.
-
Standardized file naming – every file follows a strict naming convention (Height, Width, Depth, Panel Type), making it impossible to confuse variations.
-
Fully prepared size variations – each cabinet type comes with all necessary width options, pre-modeled and ready for direct insertion into projects without further adjustments.
-
Precise categorization – no “miscellaneous” clutter; every model is exactly where it belongs.
Given this level of precision and the scale of the library, the “draw everything in one SKP file, then Make Unique and Save As” method simply doesn’t apply. While that’s perfectly fine for beginners or small one-off collections, in a large, structured, professional library it leads to messy file management, broken component references, and long-term inefficiencies.
By building each component as a fully independent, pre-optimized SKP file from the start, I ensure the library will remain clean, scalable, and production-ready for years to come — in other words, a system you can rely on in actual professional projects.
Back in the days, before persistent ID’s, there already was a dictionary attached for the 3D Warehouse and the content developer program (now gone) had some best practices. Check this post:
The only way to get rid of existing ‘Credits’ was to explode and create them again, too ‘claim credit’ for it.
Building the library from a single source file doesn’t preclude everything you want. At the end of the process, you’ll have the same tree structure.
This solution, however, offers many advantages:
- Natural management of component uniqueness
- Natural checking of component uniqueness
- Ability to share common components
- Ability to share common materials
- Centralized source
- You can even create the tree structure in the source file by placing components in subgroups and, using a small Ruby script to export all the files in one click, with a copy of the same structure for the folders. This makes maintenance much simpler.