Caveat - Please interpret anything presented as fact as "as far as I can tell"
On loading a .kicad_pcb file into freeCad, the parsing of file names for 3D models associated with footprints doesn't always yield sensible results, or results that match KiCad's behaviour
In the attached file there's a board with 6 LEDs, all with variations on the same 3d model, either .wrl or .stp. Note that isn't .step
In the KiCad 3D viewer, all 6 diodes appear correctly, if you load the board into freeCad only 2/6 appear.
The relative file paths beginning ./ load into step up, but both use the .stp model. (Removing the .stp causes neither to show)
For other files, or for relative files that can't be found, and absolute file paths, the loader seems to:
strip any leading /
strip the extension
prepend $KIS3DMOD
add extension .step
The dialogue only informs the user on the modified try. If I set the file path in KiCad to
./relative/FileThat/DoesntExist.stp or ./relative/FileThat/DoesntExist.wrl
returns
...missing module(s)
Drive:/files/to/$KIS3DMOD/AbosultePath/toProject/./relative/FileThat/DoesntExist.step cannot be found
This is confusing, as it makes the user think that the environment isn't set up properly, when in fact the file isn't present, so the loader checks elsewhere, and the subtle extension change is easy to miss.
or using
Drive:/Absolute/FileThat/DoesExist.stp
returns
...missing module(s)
Drive:/files/to/$KIS3DMOD/Drive:/Absolute/FileThat/DoesExist.step
and I'm not 100% sure how to force an absolute file path yet.
You can play around with the files and get various nonsensical paths. With this board, I never seem to get more than two "missing models" even though I'm using 6 different file extensions/paths. This would suggest to me that the importer is marking them as bad and skipping future references, even though the file extensions, and therefore files themselves, are different. This could mean an erroneous .wrl causes valid .steps not to be imported.
I've also seen when using $ALT3DMOD or $KIS3DMOD the extension isn't preserved, hence .stp files will not load from these locations. Resulting in the message
...missing module(s)
Drive:/path/to/$ALT3DMOD/fileThatDoesExist.step
when the file does exist, but as .stp or .wrl
If you build a kicad board with a SOT-23 footprint as it comes from the library, the footprint 3d model is
${KISYS3DMOD}/TO_SOT_Packages_SMD.3dshapes/SOT-23.wrl
but also you'll find in that folder
${KISYS3DMOD}/TO_SOT_Packages_SMD.3dshapes/SOT-23.step
exists and if you remove/rename it the package won't appear in freeCad Even if the .wrl is unchanged.
This is particularly confusing, as some Kicad parts have both, and some don't resulting in some parts loading just fine, with others not and no obvious difference. For example
Socket_Strip_Straight_1x14_Pitch2.54mm doesn't have the appropriate .step so doesn't load
I'd suggest the behaviour should be
- any file path options that work in KiCad should worth with KicadStepup
-- hence if the file begins with a / or // or .// and so on, the file should be treated as relative
-- if there is an environment variable is present that should be prepended
-- else it should be treated as absolute as passed as is
- the exact extension should be preserved (ie .step / .stp .wrl / .vrml ) in all events.
I'm not actually sure if step Up is able to import .wrl files in this case (I know there are some options in exporting boards), if it's not designed to work with .wrl then it should inform the user that it can't import them. I don't think loading a corresponding .step file with the same name (if present) is a good idea. Giving an "I can't import .wrl" message gives the user the choice to change to a suitable file, importing a different file to the one the user inputs could result in old/different/bad models being used.
StepOrStp.zip