Help understanding 3D Search Paths and Environment Variables

I’m currently using an environment variable to avoid hard coding the absolute path in the 3D model path for a footprint in my libraries. It looks like there might be an alternative to environment variables using the “3D Search Paths” box, but I can’t find any info about how this is intended to be used.

For example:

  • What is an “alias”?
  • Can/should an environment variable be used inside the “path” of an “alias”?
  • What should the “Path” be?
  • How do I use the “alias” once I’ve defined it?

This is a feature new to 5.1 so i asked on the mailing list when this got introduced. Never got a good explanation, so we opted to stay with the tried and tested version 4 way for the official library.

In other words if you ever find it out update us here.

IIRC it’s in flux and will be better defined in 6.0, although it of course works in some certain way now. I wouldn’t rely on it before that.

I did some experimentation and I think I figured out how the 3D Search Paths feature is supposed to work.

The 3D Search Paths allows you to define an “alias” which can be referenced in the 3D Model(s) paths definitions for a footprint.

However, the same thing can be achieved via environment variables, so it’s not clear to me why this was introduced as a separate feature (i.e. I can’t think of any benefit for “alias” vs. an environment variable).

On further thought, I think this could pave the way for the ability to make truly portable user libraries for footprints and 3D models.

Currently, the .kicad_pcb file uses a similar alias to refer to to the library that a footprint belongs to, e.g. Resistor_SMD:R_0201_0603Metric where Resistor_SMD is the library name defined in the fp-lib-table (either global or local).

What we’re really missing is a 3D-lib-table file that allows managing the 3D libraries in the same way that the symbols and footprints are managed with sym-lib-table and fp-lib-table. The “3D Search Paths” is effectively a global 3D-lib-table. If we had a local 3D-lib-table file that could live in the project directory, it would allow having truly portable projects that don’t have absolute paths or environment variables defined in the footprint’s “3D models” table.

People keep asking for relative paths to 3D models in footprints, but I think having a local 3D-lib-table file is actually the way to solve the portable library problem without having relative paths.

I added this as a feature request at

1 Like

@eelik thanks for the link, great to see that this is already on the list! :+1:

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.