Looking back and now forward thinking…
I think it might be a good idea to have the option to import the 3D model information into any user custom edited Footprint.
And, to be able to “rescue” that specific model back into a current KiCad library.
What makes you think it might not be a good idea?
vs.
…
1 Like
I can think of two snags:
- file size
- distribution of a project due to copyright, many models are only licensed to the original downloader
In my experience most of the models outside KiCad’s own library have restrictive licences or aren’t actually licenced at all, just provided (so implicitly licenced with “all rights reserved”).
I would rather see KiCad’s archiving capabilities enhanced, so that I could with one button click to make a project standalone, with local (copied) footprint, symbol and 3D libraries (and so that board etc. files would automatically point to those new libraries). I don’t see why 3d data - which is large, as davidsrsb said - should be embedded into the board file or into the footprints. Embedding into footprints would logically mean embedding into board files, because footprints are embedded.
4 Likes
Which means it would always be attached to the project, even if the library/path changes.
As far as I understand, PcbNew already only uses one(1) Footprint for each type of Footprint. If there are twenty(20) capacitors on the board; only one Footprint is fully defined. If my understanding is incorrect, it could be implemented this way to keep the file size to a minimum.
“Might” in this context means “possibly”, so there is some doubt. My question was, what are the doubts Sprig has?
1 Like
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?
2 Likes
Remember when somebody was generating THT resistors with correct colour bands.
Every passive value would need a unique 3D model
2 Likes
No. My objection is me being required to RE-Download the exact same files for every slight change in a KiCad build version.
For my situation, Hard-Drive space is cheap, but Online Data is not.
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.
6 Likes
A typical audio MP3 can easily be 3+MB in size. A FLAC of a vinyl at 192K data rate can be 800MB in size.
@eelik I would never suggest that you be forced to make your file sizes any larger.
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.