Best way to share Footprints with 3D model

Software
#1

Hey there,

while it was quite comfortable to share “normal” footprints without 3D-models or with 3D models from the standard 3D lib (${KISYS3DMOD}) by just sharing the kicad_mod file(s) I don’t get the best way to do this with a custom 3D model.

I would like to have a zip-file with kicad_mod files ans the 3d modell, so the user can unpack it to his desired folder and then simply add the lib by “add library”. But in this case the 3D models cannot be found by kicad.
Isn’t there a way to reference the wrl/stp relative to the kicad_mod file?
using ./3D/model.wrl or 3D/model.wrl does not work.

Let the user copy the 3D files to ${KISYS3DMOD} doesn’t sound so good to me either.

Any other ideas / best practices ?

#2

There is no clean way.

  1. Use a name such as ${MY_3D_MODELS}/libname in the footprint
  2. The user must copy the 3d models to ${MY_3D_MODELS}/libname
  3. When a user adds the library, they must also define MY_3D_MODELS in KiCad

It would be really nice to have a clean way to install third-party content in KiCad, but it is not a priority for the developers.

#3

I feared this… Thanks for your hint with a custom ENV…
I think I’ll do that.

#4

https://gitlab.com/kicad/code/kicad/-/issues/2242 is an ff-exception i.e. coming for v6.

#5

Nice, but it does not mention footprints or 3d models. ff-exception does not mean it will be in v6, only that it may be. It’s also a wishlist, lowest priority. The draft spec is private, so difficult to comment.

I think my opinion stands, an easier way to install third party footprints doesn’t seem to be on any developers radar.

#6

@qu1ck has been aware of your previous work and mine and our discussions. It would be of course nice to have more transparency in the process.

#7

I have all my digits crossed hoping for a successful resolution :smiley:

#8

Just because we’re not working on it right now doesn’t mean it hasn’t been discussed or considered. We know this is problem. In my opinion, the right way to solve it is to allow storing 3D models inside footprints (and since footprints are stored inside the board file, this will also mean that you can distribute a kicad_pcb and expect the 3D models to work on any computer (and be the same as the designer intended)

1 Like
#9

I never claimed that, I just said it is not a high priority.

Obviously, I can only form opinions based on public knowledge, therefore you can’t say my opinion is wrong based on secret knowledge. If information becomes available, then I can form a different opinion.

I guess I need to use the disclaimer IMOAAFAIPK, but it should go without saying.

Well you see that is what worries me about secret discussions. Your proposal is a workaround for a specific problem, but doesn’t solve the general issue of installable third party content.

So based on your new information, I am now even less inclined to think developers see the issue as a priority.

#10

It’s not a workaround, it’s the right thing to do to make 3D models “first class citizens” which they aren’t today. This thread was originally asking about distributing 3D models with footprints. It would be trivial to do this if they were together in one file.

Sure, there is also discussion of “content management” plug-ins and all that, but nothing about those proposals would fix the underlying problem that 3D models are (at present) not tied to footprints or board files, so it’s harder than it should be to distribute them and to ensure that they don’t change unexpectedly.

#11

It is not really the distribution, that is quite simple - just zip it together.
The problem is, while “installing” them, that it is not possible to reference the model from the footprint in a general way (that works on every computer) without the need to setup additional ENV or copy them around.

There would be a quite simple (yet not perfect) fix for the problem: allow to reference the model relative to the footprints path. Then you could store the model flat with the kicad_mod files or put them in a subdir.

#12

That is only a “half fix” for half the problem.

We want designs to be portable between computers so that people can publish their boards and schematics and others can open them exactly as the designer created. This requires that all the information necessary to display a design has to be included in the distribution. With 3D models not being part of footprints, this is not possible, and leads to some problematic situations.

For example, designer A designs a board, uses a footprint that references a 3D model, and then publishes that board.

Designer B downloads that board a few years later. The board opens, and looks correct, but the problem is that the 3D models Designer B is seeing are from a different library version than the ones Designer A was using! It’s entirely possible that the model for a footprint was changed to correct a mistake, but Designer A was designing around that mistake. When you open a board, it uses the footprints saved in the board (not the ones in your library) but because no 3D models are embedded, it can only use the 3D models you happen to have, whether or not they were the ones originally used in the design! This lack of control is an issue.

So yes, we could make changes to make packaging 3D models next to footprint libraries easier, but that wouldn’t fix the underlying issue I describe and so I don’t think it would be prioritized.

1 Like
#13

There was no intention to make things secret. Things just come up in conversation and since they obviously aren’t going to make it into 6.0, making them more formal took the back burner.

I created some relevant issues to track these conversations publicly:

There is also an existing request for relative path support, which has some gotchas to figure out if it is to be implemented:

#14

That depends on what you see as “the problem”. I understand the problem you described with the models not beeing embedded.

But that ist not the problem that I have - I have the problem that there is no comfortable way of installing third-party footprints with 3D models.

These two problems are related and there may exist a technical solution that fixes both of them, but that doesn’t mean it is just a half fix.

#15

I understand your point of view on that. My point of view is that we should prioritize solving the problems I mentioned over solving the one you mentioned. This might seem a little arbitrary, but my reasoning for this is that our available development resources are limited, and as more people try to make use of 3D models in their designs, it becomes more and more urgent for us to solve the underlying issue I mentioned to avoid huge headaches for people.

#16

Wouldn’t this have the negative effect of making the board files very big? depending on the size of the 3d models ?

#17

Yes. As mentioned in the issue, one way to offset this is to use compression (which is already in progress) – both compression of the entire board, and using compressed and optimized STEP models, for example. But it is a tradeoff, and so it will be optional.

(in my personal opinion, it’s usually worth it: storage is cheap, and loading a single large file that has all the models will be faster than loading each model from a library)

#18

ranking of issues in projects is surely on of the hardest jobs. You can’t look in your “customers” head, and sometimes even your customers don’t know what they really want.
I’m quite new to KiCad and EDA in general, I just do it is a hobbyist, I’m in software to bring home the beacon. A great tool, by the way, I like it very much. Thanks to all contributers!

What I want to point out:
As a rough guess as a professional software engineer, without knowing anything about the architecture of this tool, to enable relative paths for referencing 3d model seems to be like 5% of the effort for your “Great Leap Forward”.
I’ve seen so many times developers chasing the perfect solution and forgetting about good solutions.
I really don’t want to play agile buzzword bingo now, so I shut up.
Take my opinon as one opinion out of your customers, I can only speak for myself and I really have no clue what others may think about this.
And anyway, thats the freedom of developers doing it “for free”: they can choose whatever they like most :wink: and that is absolutely fine.

#19

Unfortunately for historical reasons the architecture of the 3D model searching and loading system is kind of more complicated than it should be and makes the simple ask of “support relative paths!” more complicated than it should be. I’m not saying we shouldn’t (or won’t) do it anyway! But yeah, this bug would have been fixed a long time ago if it were trivial.

#20

This seems wrong to me. As the footprints are not stored within the symbols, I don’t see a good reason why 3D models should be stored within footprints.

When looking at the whole project, symbols are cached within the schematic files and footprints are cached with the layout file. The references to original symbols and footprints are still contained. If one shares a project the project can be opened by anyone. But if the one who opens a project has the same libraries he can also update symbols/footprints from the libraries. So for the purposes of sharing a project, I’d prefer to have a cache folder for 3D model. And if KiCad would not find the originals, it would look into cache folder. I don’t know the internals of step file format, but if it hierarchical one could have only one .step file for the PCB which would contain all the 3D models used, then we would have nice symmetry.

When sharing just one asset (symbol, footprint or 3D model), we have to be aware that currently sharing a symbol with defined footprint is equally problematic as sharing a footprint. and I don’t see a solution here.

BTW, for easier sharing of the project one might use my Archive project action plugin. Currently supports 5.1.x branch and kinda solves the issue of sharing projects (3D models and symbols).