I am not the only one.
The user never had the 3d models so your “fix” would not help at all.
When making a feature request lay out the usecase you want to have fixed instead of presenting a “solution”. This way devs can decide what is the best option to solve your problem instead of needing to first guess what problem you intent to solve.
2 Likes
So what? If I want to read the pcb file it would mean scrolling through tens of thousands of unwanted lines. Disk space or dowload speed aren’t the only things that matter.
What if I want to read a file made by someone else? For example to help someone in this forum who sends the file?
2 Likes
An year ago I proposed the same thing and after some struggling with people explaining me why this is a bad idea, the thread was locked by moderators with some vague explanation.
Now I see the same request and the same answers (probably by the same people). Wondering is it so hard to accept the other man’s POW neglecting your own ego?
Yes, (directly) embedding the 3D models into the PCB file will lead to very big files which will be harder for direct editing with text editor. That’s why in my thread I supposed two approaches:
-
With locally caching the 3D files in the project’s sub-folder - something which is supposed to be already addressed with a plugin. Unfortunately the plugin does not work as supposed in the cases when there are PATH variables other than standard ones (and actually this is my case - a my own repo with 3D files with a PATH variable to its location). That’s why I wrote my own soft which does the job for me (at least). Since it’s written in Perl and works as a standalone program it cannot take the PATH variables as the Python plugin script is supposed to do.
-
Some kind of database support (similar to some other EDA packages
) which will give us an enormous number of benefits (beside the ability to have only one 3D file for all footprints from the same type).
Similar problem with the vague request here: A database is a solution to a problem. Which problem? (Really a feature request should detail a currently not supported usecase. It should not jump directly to the solution you think would be best to support this usecase as you the user are most likely missing information to make the decision about which solution is the best option to support your usecase)
Even though it was me who used big files and editing with text editor as arguments, I also suggested better archiving, which would include “locally caching” in some form or another. But as far as I can remember I haven’t taken part of a previous discussion.
Also, I don’t have an ego. I’m just always right 
3 Likes
In general, better archiving (or making a project standalone) functionality is needed. For example, I should be able to set up the project so that I can take components from libraries outside, but when I go on designing schematic or board, KiCad would automatically copy the library components locally and use them instead of the common libraries. This should be transparent so that I wouldn’t have need to periodically remember to copy or archive components manually or to care about changing file paths or variables.
Basically this would be pretty much the same than caching, but not inside the board file or the schematic file.
There are other reason than just file size or human readibility to avoid caching in the design files. Because the files are human readable they are (at least theoretically speaking) good for version control. Having everything - especially in binary form - in one file is bad for version control. Even now KiCad could do better in that respect, but having 3D models cached in board files would ruin it.
I’m not opposed to offering options for users, but I’m afraid this option would eventually affect me even if I don’t want it myself. And better local caching or “archiving” would be a better and more generic solution to the problem (what problem, as Rene asked), anyways.
1 Like
Not really. archiving is something that happens on user command (for example triggered at the time instance one orders the board)
caching happens always in the background.
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.
2 Likes
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.
2 Likes
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).
2 Likes
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.
1 Like
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.
1 Like
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
I am very open to parametrization and procedural generation too
but from my experience I don’t see it desired to be integrated in a project like KiCad.
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:
It uses just 1 base model and variants of the numbers, then it uses an include external file capability of WRL.
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.
1 Like
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.