KiCad 7 3D models of a KICad 6 imported file

I don’t know if I’m missing something so I post it here.

When you have a KiCad v6 PCB file all standard footprints has 3D models pointing to ${KICAD6_3DMODEL_DIR}…

When this file is imported by KiCad v7 the 3D models paths are left unchanged.

If you now try to use the 3D View no model is visible. This is because all of them uses KICAD6_3DMODEL_DIR, which isn’t defined by v7.

If you now update all the footprints from the standard libs the models still point to KICAD6_3DMODEL_DIR, and this variable isn’t defined in the paths, only its KICAD7_ counterpart.

I downloaded the .deb from the PPA and checked that all 3D models use KICAD6_3DMODEL_DIR.

At the same time the fp-lib-table uses KICAD7_FOOTPRINT_DIR.

What’s wrong? Why isn’t KICAD6_3DMODEL_DIR defined by KiCad 7 when this seems to be needed in order to use KiCad 7 footprints?

1 Like

You can define this environment variable yourself in Project Manager / Preferences / Configure Paths, and then click the plus sign next to the garbage bin in the lower left corner.
image

Did you update them from the V6 libraries, or from the V7 libraries? KiCad does not change this on itself. If you want to update a project, you have to change the library links in the schematic symbols. You can do this with Schematic Editor / Tools / Edit Symbol Library Links.

When a project is nearing completion, my preferred method was to export the footprints and schematic symbols to a project specific library and make them independent from the KiCad libraries. I’m not sure whether I will continue doing this though. Ever since V6 all relevant info is embedded in the project files themselves, and updates of schematic symbols and footprints are optional.

I’ve seen this too. I just manually changed missing models, but your right there should be a better way. What about updating the KICAD6_3DMODEL_DIR in the configure paths to point to the 7 libs?

image

Hi @paulvdh !

I know how to define environment variables. My points: Is this normal? Every single user migrating from v6 must define an environment variable? Shouldn’t this be part of the import process?

About the footprint refresh: If the project is loaded with v7 you’ll get the footprints updated from v7 libs, not v6. Unless you explicitly define it otherwise in the fp-lib-table. This is because the default global fp-lib-table included with v7 points to v7 libs. It isn’t related to the schematic, this is because libs are referred by their alias, and the fp-lib-table solves what the alias means.

What about updating the KICAD6_3DMODEL_DIR in the configure paths to point to the 7 libs?

Yes, I thought KiCad v7 footprints pointed to v7 3D models.

Yes, I consider it normal. If you want to refactor old projects to a new KiCad version you have to do maintenance on the project. If you find your 3D objects precious, then make them a part of your project, and back them up with the rest with your project to keep the project intact.

The other way around would mean that KiCad’s libraries could not be updated. There simply can be no progress without change, and you have to adapt to keep up with that.

Some other things are also changing. In V5 and before the clearance of zones from the edge was handled by setting the “line thickness” of lines on Edge.Cuts. In V6 it changed to a setting in the zone, and now it has become of the board setup. Handling of net ties has changed and will change again in the future.

The KiCad developers do take compatibility serious. “They” have promised that KiCad will always be able to read files with older versions of KiCad. I am not certain how far they want to go in that a project converted from an old KiCad version to a new KiCad version will still be ready to send to a PCB factory without further maintenance.

KiCad is getting a lot more sophisticated. In V5 all graphics on a copper layer was ignored by DRC, and now KiCad does detect DRC violations from graphics on copper.


But do keep in mind I am also just a KiCad user and have very little influence in which KiCad is going. I can post on this forum and make feature requests on gitlab, just like anyone else and that is about it.

Strange. I too see that the 3D model paths in the footprint files use ${KICAD6_3DMODEL_DIR}. However I can display 3D models correctly.

So internally KiCad7’s code must map KICAD6_3DMODEL_DIR to /usr/share/kicad/3dmodels So I don’t know why you cannot see the 3D model.

I think this is a bug.

I agree with you in that projects should be “self-contained”, you should copy all footprints and their 3D models to your project. This also allows customization of small details. But people doesn’t do it.

I don’t agree here. KiCad could do it much better.

I noticed this, and I think this is poorly handled by v7. Setting it to 1 µm is quite silly. Scanning the zones to look for it is a far better solution. And KiCad could even warn you if it finds that zones disagree in this setting.

May be you are right, but I think they are really far from achieving the goal.

I agree that pretend to make it ready for manufacture is impossible.

Also keep in mind KiCad is an Open Source project, and as such it has both the advantages and limitations of an Open Source project. The advantages are probably clear (Free to use, see and modify source code, etc) but the limitations are also clear to see. All developers are free to work on the parts of KiCad they deem interesting. No one can order them what to do The total amount of developer hours is limited.

In the years I’m following KiCad, it is doing extremely well. Some things are going very slowly (The Issue for Net Ties has been open for 4 years for example) but other things are going quite fast. And sure, there are loose ends, and things that could be improved, but that goes back to the limited available hours, and the free will of the developers.

If you have a lot of old projects to migrate, and also want to work on new projects, then writing a script that can swap the library tables and environment variables may be a way to go. There are also already scripts written by third parties to backup projects and make them “standalone” and therefore independent of installed libraries.

Back to the original question…

That seems logical to me.

When you did this update, did you update them from KiCad V6 libraries or from the V7 libraries?

If I wanted to update a V6 project to V7 with the intention of making it a “native V7” project (and consider this more important than consistency with the old version) I would start by creating a .pdf file of the schematic to keep as a reference. Then I would change the links in the schematic symbols to point to the KiCad V7 libraries and then update the PCB with the native V7 footprints. this very likely also swaps the links to the 3D models to the V7 versions.

v7!

This looks like multiple bugs together. Not just one.

  1. v7 libs package pointing to a v6 path
  2. Some error in what is called in the code because the KiCad was designed so support the old names:
            // Replace unmatched older variables with current 3d model locations
            // If the user has the older model location defined, that will be matched
            // first above.  But if they do not, this will ensure that their board still
            // displays correctly
            else if( strVarName.Contains( "KISYS3DMOD") || strVarName.Matches( "KICAD*_3DMODEL_DIR" ) )
            {
                for( auto& var : ENV_VAR::GetPredefinedEnvVars() )
                {
                    if( var.Matches( "KICAD*_3DMODEL_DIR" ) )
                    {
                        const auto value = ENV_VAR::GetEnvVar<wxString>( var );

                        if( !value )
                            continue;

                        strResult += *value;
                        expanded = true;
                        break;
                    }
                }
            }

I’m trying to fix other problems, so I won’t investigate why isn’t working.

And I’m not worried about me, I can write scripts to workaround KiCad errors. I’m worried about the users of my tools (KiBot, KiAuto, etc.)

1 Like

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