That’s true, but I haven’t thought it through and used vague terms. The general idea should be clear, though: that I want components locally inside the project but in their own files, not in the design files.
Now the footprints aren’t cached inside the board file - they are copied there. Indeed, caching (as an idea) exists for making access faster or easier, and if the original is changed, the cache must reflect that. Not so with KiCad board files. And it wouldn’t even be desirable.
KiCad data lacks coherency, as I found when writing a KiCad data installer. Embedding path names into files is also problematic.
However, the LIB:ID notation introduced for pcb files is now also used in schematics. It makes sense to extend that to other data types.
In this case, it is a relatively small step to allow LIB:ID notation in the “model” field. That would necessitate having a 3D packages library table, hopefully existing code for handling library tables could be re-used.
Then it appears what is needed is an “archive” function, to collect the 3d models into the project folder. Then the project would be self-contained.
If I have undersood correctly this is in the roadmap for 6.0, http://docs.kicad.org/doxygen/v6_road_map.html:
- Add library table 3D model support to footprint library file format.
- Create remapping utility to map from path look up to library table look up.
- Add user interface support accessing 3D models via library table.
A lot of interesting stuff there! It’s really looking positive for the future of KiCad.
I used to be conceited, but now I’m absolutely perfect 
I do it for every project with copy and paste withing the system file manager.
I think this thread has led to “how to automatically do something” and not to “if it is possible to do something”.
I assume you are talking about my plugin archive_project. If so, I’d appreciate if you’d raise an issue as I would gladly try to fix it (might take some time though).
Yes, it’s about your plugin. Tell me how/where to raise such an issue and I’ll do this. In short, though - the problem is/was that it cannot track the PATH variable different than the standard ones.
I tested the plugin an year ago on my older computer, in order to be exact I’ll have to install the script on my new one and give it a try again.
Oh, one more thing - it’s highly desirable to have a backup of the original PCB file in order something went not as supposed.
I could share my own script for doing this job but as I’ve already wrote it’s written in Perl and I don’t know if it will be of any help.
You’ll have to get a GitHub account and then you can raise an issue here. You should test the most recent version of the plugin and if (when) it fails please attach the .log file to the issue. The file should be in the same folder as is your project.
As for backing up the project before running the plugin I could not agree more and the plugin warns the user.
seams to me large 3d file formats are the issue. 3d models would be small and cacheable in text form if they where for example in openscad or similar descriptive format. the same 3d model could be used with varying textures, ie through hole resistors or those bands could be a fraction of a mil larger than the body and the objects a rendered in a different color. i wouldn’t mind seeing support for the openscad files instead of wrl files and rejecting 3d models that are licensed under anything other then open. i find it ridiculous that very basic 3d models of components are several hundred kilobytes to a couple of megabytes. most of the 3d models distributed with kicad can be represented with a couple of parametrized openscad models and could easily be generated from footprint description. vender specific variations would be just a few bytes such as height bevils, notches, etc but still parameters and unions based on existing parameterized modules. i’ve just downloaded once again the 3d models git and its 800mb. openscad would reduce that to under a few megabytes not including complex textures. i am wondering how many models were originally built using openscad and then exported to build the final 3d model.
Hi @gms welcome to this KiCad forum!
Happy to see some one come with this proposes.
Some of the KiCad 3D models were created by code and parametrization by @maui
Maybe some simpler composition of some base models could be created on the fly.
But this kind of changed, that are major change on KiCad base, would hardly be accepted.
It may be a very good idea but there are other considerations on this kind of projects: who will implemented it, it will need to be supported on all future KiCad versions, who will have knowledge to keep that feature working in future.
Also, for the openscad case, I believe it will need to add big libraries or dependencies to the project that is by it self a rise of discussions.
So instead of spend efforts to create a good solution, we pay it by consume bandwidth and storage space 
… but it may be cheaper and than other option.
Btw, the full VRML format, support some kind of basic parametric forms like cubes, spheres, cones… but they are not implemented on KiCad.
See also this approach I did for generate variation on resistors:
Transform { translation -0.17 0.10 0.125 scale 0.5 0.5 0.2 children [ Inline { url “…/8.wrl” } ] }
Transform { translation -0.05 0.10 0.125 scale 0.5 0.5 0.2 children [ Inline { url “…/6.wrl” } ] }
Transform { translation +0.08 0.10 0.125 scale 0.5 0.5 0.2 children [ Inline { url “…/0.wrl” } ] }
Inline { url “…/RESC1608X50_EIA0603_METRIC1608.wrl” }
This is already supported by KiCad on WRL 3D models.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.