3D models are models of a package - footprints are a 2D model of that same package. Schematic symbols are rather separate in comparison.
This is true and should also be addressed in my opinion (but how to address it is fairly different). One approach to this (taken by Altium and probably some others) is to support a type of library format that contains both symbols and footprints linked together.
I appreciate the difference, and I should have stated that. Thanks for pointing this out. I like the 2D/3D view. The symbol is obviously an abstraction of physical part. And the symbol can also have other data (distributor part number, internal inventory number, …), which might not be sharable.
But if you are sharing a symbol you have to save it to dedicated library and share a footprint and 3D model. And person on receiving side has to put them all into his/hers own libraries. So just for sharing assets, I don’t see gaining much, but I agree, pulling footprint into the library and then editing it in order to point to right 3D model seems funny. There should be no need for edit.
But the downside is significant as editing a 3D model contained within the footprint will be PITA. You’ll have to extract it first, edit it and package it back. I don’t imagine KiCad having native MCAD capabilities to edit 3D model within the footprint.
For sharing projects I don’t see much difference if the 3D models are cached in footprints which are cached in layout file or if the 3D models are cached in dedicated subfolder within the project folder.
Also diffing layout files will become somewhat more intensive if 3D models are part of layout file.
I am just trying to get my point of view across and I hope you don’t mind as I cross post them to GitLab issue.
The other issue (packed vs unpacked libraries) is relevant for this: on a similar note, it should be quick and easy to pack and unpack 3D models from footprint libraries. That way, in the main KiCad library repositories, they can remain separate for easy editing, and get packed together as a CI step to produce a final library that is distributed with KiCad. Of course, all of this will be optional and having separate 3D models will remain possible for those who want to do it that way.
KiCad has taken the philosophy that a board file should be “standalone” enough to open and view the design as the designer intended (not necessarily edit or do all operations, but at least view). So, the fact that this is not possible with 3D models is kind of a big omission. We worked to fix this for schematics in V6, so you don’t need to pass around a cache library file anymore. I’m just saying we should continue the logical extension of that to 3D models.
If you really care about this, then don’t use the feature. Personally I think textual diffing of layout files is a silly thing to optimize for: I plan on making use of compressed layout files as soon as that feature is ready, which will also break text diffing. We need a good graphical diff tool for KiCad files, for sure.
Of course I don’t mind! But, keep in mind that everything I’m proposing is optional – nobody is going to force you to embed 3D models if you don’t want to.
The feature I work on will support installing plugins and libraries from 3rd party repositories and even more things in the future (templates, color themes etc). The spec will be published with the first merge request which I hope to send out within a week.
It was not my choice to keep it private and while I disagree with the practice I am honoring kicad dev’s request.
An intermediate fix / hack is to write an install script that copies both the footprints and the 3D models and the paths, either by modifying the environment variables or by setting the paths to the 3D models in each footprint.
An even simpler way would be to use
$(KIPRJMOD)
which always points to the root of the current project, and add a relative path from there, and a text file with instructions of where to place the library relative to a project.
archive_project plugin solves this issue. It collects all symbols, footprints and 3d models into the project directory and fixes all paths so that they are relative to project root. Makes the project completely self contained and portable.
A work around that might start to help as implementation spreads is if the devs provided us with path names for us to put our user objects in. Specifically for this if KiCad was packaged to provide a ${KIUSR3DMOD} path name or ${DIS_IS_DA_PLACE_FOR_YUSES_TREE-DEE_MODELS} path name (sorry, bad parody of a dumb mobster accent). Then when I create a footprint with a pointer to a 3D model in the path that is pointed to by the provided KiCad user 3D model space, then it should hopefully work in my buddy Jaime’s install because she also uses the provided KiCad 3D model space path name. As it is now, everyone needs to come up with their own path names for user generated content meaning that the chances that 3 different people will choose the same path name is highly unlikely.
Yes and no. Let’s take an example of a family of footprints of quantity X where the only difference is the geometry of the pads for different solderability standards (and even hand-soldering with even larger pads/annular rings). Each of those different footprints would use the same 3D model, but if the 3D model was baked into the footprint that would mean X copies of the exact same 3D model. This reasoning is exactly the one given for keeping symbols and footprints separate. BTW, I agree with this reasoning so I’m not trying to say it is wrong, rather why not set up a library system like the symbols and footprints for 3D models?
Being able to include a 3D model in a footprint does not preclude also being able to point to a model located in a different footprint instead of actually including the data twice.
Yeah, that’ll teach me to respond to an earlier post without reading the thread fully. Otherwise I wouldn’t have missed your statement:
Thanks for stating this explicitly. It is highly likely that you conveyed this intention between the lines (or earlier in the thread), but I did not get it.
To shed a bit of light on why I considered this problematic is that some of my designs consist of multiple boards. And when working on one board, other boards and important mechanical items (busbars, power modules, …) are represented by a footprint of a connector that connects to other board(s). And that footprint has a 3D model containing all of the items. Thus I can quickly properly place parts on board using 3D viewer to check for mechanical layout. This is obviously highly iterative process as it is common that I find it makes more sense to move something on other boards. And when I do this, I have to generate 3D model again. Obviously my wrong assumption that the all 3D model will be packaged introduced additional steps to my workflow.
Please do. The V6 schematics is a real blessing. I work at university and I collaborate on a lot of PCB designs. This is also the reason why I’ve written my action plugin. We just have a difference of opinions how to solve this, and as long as packaging 3D models inside footprints is optional I don’t mind.
I should have used more words. I don’t diff textually. There are currently a couple of solution for graphical diffing. And I use them from time to time. I suspect that these solutions will have to account for packaged footprint which might/will slow them down. But the more I think about it the more I come to similar conclusion. Optimizing for this is certainly an optimization done way to early.
Hello everyone, first post of an amateur/hobbyist user. Actually I created this account just to be able to support @craftyjon after seeing his feature request and the discussion under it. I wanted such a feature as soon as I started using KiCad.
I am a simple hobby-level-but-maybe-semi-professional-in-future user. I always found pulling symbols, footprints and 3D models from separate places with tons of clicks really ridiculous. Don’t take me wrong: I think KiCad is one of the best open source projects and I have learned how to layout a PCB with it. Great work, seriously.
I would love to have a single file, drag&drop it into eeschema, and to design my PCB without playing with all those paths, libraries etc. There are workarounds as stated above, but they are workarounds and are convoluted. Why would a simple user (not you) mess with menus/paths, or even download/setup some plugin instead of “having” the model as part of the project in a blink. I don’t want to scroll through all the paths (official, digikey, etc) just to reach the part I have designed. I want “copy&paste” (or push/commit) sharing to github while keeping my local library synchronized.
Contrary to everyone stressing about file size, I would take this deal even if it makes file size double/triple/quadruple. Space/bandwidth is cheap enough for small/hobby projects. I won’t upload 1000+ “parts” to github just for a project, I promise. I, though, may make my parts library open for those even noober/lazier users than me, who can drag&drop and start using them. As long as it is optional, I don’t see the reason for opposition.
I am simple, and kindly asking for a simple way to manage my projects.
So I just want to ask what would be the reaction of the “bosses” (steering committee?) around here if someone comes up with a solution that does more or less what Jon says? Would it be swept under carpet, left alone to rot as an external patch, or would it be merged? If former, when would it be merged? As soon as it is completed-ish/tested, or at KiCad v7? I’m not declaring I will do it. I am just testing the waters here.
Thanks for reading.
I guess I’m one of the members of the steering committee 
Everything we’re talking about would be for KiCad V7 or beyond; V6 is in feature freeze.
The next steps for this are that the development team needs to have a discussion (likely after V6 is released) about all the possible improvements to 3D model handling that have been requested or proposed, and decide on a plan of action. Even if everyone agrees that we should support embedded models, we may also want to do some of the other things that people have requested to make the handling of models easier for users who don’t want embedded models (such as supporting relative paths and/or 3D model library tables, etc).
That would make it indeed trivial.
In reality the difference can be several orders of magnitude.
A quick compare, Footprints in /usr/share/kicad/modules/Package_SO.pretty are mostly smaller then 4kiB while the correspoinding 3D sort of average out at 150KiB
With some footprints it’s even more extreme. Footprints for connectors can be very simple, while the 3D models can be several MiB.
Fair enough.
Since release policy link from wiki is not available, can I ask when will v7 come? Or when/how do you guys decide “this is v6”. If this is anything like C++ standardization, it will take some time
Yeah, those would be some good steps towards this direction I guess. Thanks for hearing out.
Since there was just a thread on this: Yet another release date 6.x question
There are still a lot of issues open: https://gitlab.com/kicad/code/kicad/-/milestones/8
After V6 is released we will be able to make a reasonable plan for V7, and a timeline will come from the plan.
I am not sure if I did convey my feelings the right way. Sorry in advance if I misunderstood you.
I would take this deal (having all three files -symbol, footprint, 3d model- in a single file) even if that makes me deal with said single file of 10x the file size of a -hypothetical- folder containing these three files. I wrote that to underline that I don’t care about file sizes via exaggeration. I probably failed.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.