Your understanding is incorrect. There is a copy of the footprint in the pcb file for every instance.
The obvious drawback is file size, and it’s kinda ironic people who have complained about download times are not suggesting a way to vastly increase file sizes…
I think embedding large data blobs like 3d models is a non-starter unless some sort of caching/compression is also implemented at the same time.
It might be obvious, but what are the perceived benefits of embedding the 3d models, and could that be solved in a different way?
KiCad files are human readable. That would suffer tremendously if 3D models were embedded into embedded footprints. (I have actually successfully read and edited board files in a text editor.)
A far-fetched example would be a simple board consisting of one 2x40 pin pin header. The board file would be 222 lines/12KB. The STEP file is about 2.5MB/60000 lines; wrl file 440KB/10000 lines. I just can’t see justification for embedding them.
As I said, it would be better if the project could be made completely standalone easily. Then it could be handled as one archive.
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.
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?
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.
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.
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.
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).
) 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).