I am running Ubuntu 16.04 on a 64 bit system. I was until now using the stable release of KiCAD, but decided to have a go at trying new features with the Nightly build. The stable release was showing PCB 3D renders just fine (Pcbnew->3D Viewer). Yesterday after switching to the Nightly repo, the models were lost: I’m seeing a flat PCB with traces, silkscreen etc.
Also, the “Add 3D Shape Libraries Wizard” is showing that the program cant access /usr/share/kicad/modules/packages3d/ directory:“It is not possible to write in the selected directory. Please choose another one.” (I ran KiCAD as sudo and downloaded designated packages from the KiCAD GitHub repository, but it did not help (still no components)).
I’ve searched around and found that some Windows users have just had to write in a correct path to KISYMOD3D. All the folder addresses in my case are correct (KISYMOD3D path is /usr/share/kicad/modules/packages3d/).
Also, did you check the footprints (one that worked before) in the fp editor (properties) and there check the 3d shape settings?
You should be able to load a footprint in there directly (no path fumbling needed) to find out what works and what doesn’t.
Once you recognize a pattern, apply it to the environment variable/etc…
You’d need to check out the source and apply the patch to that, then compile it.
Or you wait until the patch has been applied to the source on github/etc., download the result of that and compile it.
Essentially, the source is built up by patches. This is just another one.
For 32 bit OS-es command will be different of course.
I think that instead of patching the source, creating the needed symbolic link can be done from postinstall scripts for a given package type (deb, rpm, etc.).
This is OK as a temporary fix (though many system admins will give you the evil eye). The (permanent?) fix is already in the patch which was linked, now it’s just a matter of waiting until one of the devs with commit access finds time to apply the patch, run a test build, and commit the patch.
I suppose the patch is already applied because an hour ago I updated kicad, removed the symbolic link I did in order to view 3D models and they still are visible
Thank you everyone for this info!
it seems that this problem still persists though (or maybe it is a new one?)
i checked that the patch really is applied, i double checked that i have the 3d files and that they contain the models (freecad can open them), and that my KISYS3DMOD points to the right location.
the weird thing though is when i try to assign a 3dmodel to a footprint (‘e’ on footprint -> tab ‘3D Settings’ -> ‘Add 3D Shape’) the preview stays black. whatever file i select. i can click inside and drag, and the coordinate vectors in the bottom left corner turn as they would noramlly, but the rest stays black. (see the example pic)
but when i open a pcb and 3d-view it, it renders just fine (except for the missing 3d models…)
any ideas what i could be doing wrong?
i’m on the latest nightly:
i’m using arch linux, so i can’t use those builds, and i gladly believe it’s working just fine for others.
did a complete rebuild (of oce as well), my problem still persists.
if anyone wants to still take a stab at this, i’m all ears, otherwise i guess i’ll just have to switch back to stable whenever i want 3d files of a complete board exported.
What I do know about the Ubuntu version, is that the viewer fails to display the 3d model and no error message if the file is not actually there at the location. This is a bug in my opinion.
I suspect that the silent fail will also happen if the viewer does not display .wrl
It turns out the problem i had was that kicad was looking for the plugin files in the wrong place.
i ran cmake with the options
-DCMAKE_INSTALL_PREFIX=/usr
-DCMAKE_INSTALL_LIBDIR=/usr/lib
(as in the arch linux AUR package for kicad-git)
which makes kicad look for the plugin files in /usr/usr/lib
that’s why the preview stayed black as well.
if you have built with Debug support, run ’ WXTRACE=3D_PLUGIN_MANAGER kicad ’ to find out where it looks for the plugins, then put them there to find
sounds like a bug though. it shouldn’t append LIBDIR to PREFIX i think?
if anyone should still stumble upon this, the AUR package just got an update with a fix for this problem
using -DCMAKE_INSTALL_LIBDIR=lib
makes all the troubles go away.
This OS system differences to install plugins are still “work in progress”. I don’t know who is working on a solution for this differences. Maybe @cbernardo can clarify this questions and point this issue to someone in the development team?
