3D models discussion

@Rene_Poschl thank you very much for the detailed explanation. I hadn’t considered that the models were script generated and the existing inter-dependencies of 3D model naming and scripts for auto-generation of models - I now see why you need to have separate files for identical 3D models.

Also, you made a really good point about needing to have the ability in the future to add more detailed models if it so was required - continous improvement.

I now understand the direction of the 3D libraries much better and will proceed accordingly and see what I can do to adapt the 3d model scripts. Side point: at the moment I can’t get the 3D model scripts to work on my machine - I’ll make a separate topic about this.

Thanks again for taking the time to explain all this and look forwards to helping out where I can!

Edit: added link to separate topic

1 Like

Being able to parse the size parameter from the FP generator would be a huge improvement (has been on my todo list for way too long, but I don’t have much Kicad time nowadays).
@Qbort please let me know if I can assist you with anything

I just realised I haven’t replied to this main thread: just to update everyone that I am working on this. At the moment I have found there are issues running the scripts: some only run in FreeCad 0.17, some only run in FreeCad 0.18. This is due to python3/2 compatibility and a few other minor bugs.

I’ve created merge request with the fixes (still WIP): https://github.com/easyw/kicad-3d-models-in-freecad/pull/374


If you are in a hurry Py2 scripts can be converted by using 2to3, and if you wish to go the other way, you can use pasteurizer.


Scripts that need Python 2 need to be updated, FreeCad 0.17 is obsolete.
Hopefully 0.19 won’t introduce more incompatibility


there are still distribution using FC0.17, so when possible I tend to let both py2 and py3 compatibility available

There are a bunch of scripts and many of them are still untouched since the very start (using FC0.15)… nerveless the main incompatibilities are python related, and are already patched in some of the 3D model builder simply allowing both py versions

I won’t trust this approach… this will migrate from py2 to py3 without allowing the back compatibility

Ideally you’re not meant to go backwards. If you have users relying on Py2, then you’ll have to make the difficult decision to either abandon them or maintain two versions. That’s why it’s important that Kicad makes an unequivocal decision to go forwards.

Ideally you’re not meant to go backwards. If you have users relying on Py2, then you’ll have to make the difficult decision to either abandon them or maintain two versions.

My 3D repos started with py2 and FC 0.15… since 2015 we have gradually moved to FC0.16,0.17,0.18 and now 0.19 but still most of the scripts can just run fine in older FC releases and with simple py check code it is possible to let the tools to be fully usable with both of the py versions. I don’t see why we cannot keep this approach that need few simple line of code in the scripts.
You don’t need to have two versions but just keep in mind when you code to check py compatibility.

1 Like

I think the approach is up to the author. But I also think the large software applications have dragged their heels even though EoL of Py2 was announced long ago.

even if I agree py2 is dead, as I said:

Thanks, I’ll have a look. I would never trust what an automatic conversion tool does blindly, but I can see the result and fix any other issues manually.

@maui I am testing code in FC0.17 and FC0.18 to ensure backward compatibility.

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