Yes, seems so! There already is a patch for the bug. Albeit I feel a bit overwhelmed: how do I apply a .patch file to KiCAD? https://launchpadlibrarian.net/315963155/3D_plugin_multiarch_bug1682812_20170417.patch
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.
2 Likes
As a quick and dirty hack until the suggested patch is applied to the nightly builds I can suggest the following solution:
T510 ~ # ln -s /usr/lib/x86_64-linux-gnu/kicad /usr/lib/kicad
It works for me!!!
Info about kicad and my system:
Application: kicad
Version: no-vcs-found-1a75d99~58~ubuntu14.04.1, release build
Libraries: wxWidgets 3.0.2
libcurl/7.35.0 OpenSSL/1.0.1f zlib/1.2.8 libidn/1.28 librtmp/2.3
Platform: Linux 3.19.0-32-generic x86_64, 64 bit, Little endian, wxGTK
- Build Info -
wxWidgets: 3.0.2 (wchar_t,wx containers,compatible with 2.8)
Boost: 1.54.0
Curl: 7.35.0
KiCad - Compiler: GCC 4.8.4 with C++ ABI 1002
Settings: USE_WX_GRAPHICS_CONTEXT=OFF
USE_WX_OVERLAY=OFF
KICAD_SCRIPTING=ON
KICAD_SCRIPTING_MODULES=ON
KICAD_SCRIPTING_WXPYTHON=ON
KICAD_SCRIPTING_ACTION_MENU=ON
BUILD_GITHUB_PLUGIN=ON
KICAD_USE_OCE=ON
1 Like
Yes, the direcotry link works! I’m on a T410.
Program info:
Application: kicad
Version: no-vcs-found-1a75d99~58~ubuntu16.04.1, release build
Libraries: wxWidgets 3.0.2
libcurl/7.47.0 OpenSSL/1.0.2g zlib/1.2.8 libidn/1.32 librtmp/2.3
Platform: Linux 4.4.0-72-generic x86_64, 64 bit, Little endian, wxGTK
- Build Info -
wxWidgets: 3.0.2 (wchar_t,wx containers,compatible with 2.8)
Boost: 1.58.0
Curl: 7.47.0
KiCad - Compiler: GCC 5.4.0 with C++ ABI 1009
Settings: USE_WX_GRAPHICS_CONTEXT=OFF
USE_WX_OVERLAY=OFF
KICAD_SCRIPTING=ON
KICAD_SCRIPTING_MODULES=ON
KICAD_SCRIPTING_WXPYTHON=ON
KICAD_SCRIPTING_ACTION_MENU=ON
BUILD_GITHUB_PLUGIN=ON
KICAD_USE_OCE=ON
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.
2 Likes
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 
2 Likes
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:
Application: kicad
Version: (2017-07-06 revision 885a4c1bc)-makepkg, debug build
Libraries: wxWidgets 3.0.3
libcurl/7.54.1 OpenSSL/1.1.0f zlib/1.2.11 libpsl/0.17.0 (+libicu/59.1) libssh2/1.8.0 nghttp2/1.23.1
Platform: Linux 4.12.0-ARCH+ x86_64, 64 bit, Little endian, wxGTK
- Build Info -
wxWidgets: 3.0.3 (wchar_t,wx containers,compatible with 2.8)
Boost: 1.64.0
Curl: 7.54.1
KiCad - Compiler: GCC 7.1.1 with C++ ABI 1011
Settings: USE_WX_GRAPHICS_CONTEXT=OFF
USE_WX_OVERLAY=OFF
KICAD_SCRIPTING=OFF
KICAD_SCRIPTING_MODULES=OFF
KICAD_SCRIPTING_WXPYTHON=OFF
KICAD_SCRIPTING_ACTION_MENU=OFF
BUILD_GITHUB_PLUGIN=ON
KICAD_USE_OCE=ON
i’d appreciate any pointers
*example pic:
Working fine in Ubuntu 64 Nightly, PPA build
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.
I have the same problem. Only certain types of files will show on the preview window.
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?
2 Likes
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.
3 Likes
The real is problem is that the 3D viewer does not warn that it cannot find the plugins and fails silently
1 Like
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?
I’ll look into it. I thought the code also attempted to find a path relative to the executable, so /usr/bin/pcbnew should have produced a search path /usr/lib/kicad …
the relative path it is looking in is /usr/bin/…/plugins/3d
I had a look at the code; the problem you originally had was that an absolute path was given for the lib directory. This was a case which was missed in the code. I’ll see if I can find time to write the few lines of code to check if CMAKE_INSTALL_LIBDIR is an absolute path and to use that path if it is absolute. I think that should be OK in most cases; the exception where it would fail is when the absolute path given is for a staging directory, but in that case I don’t know of any mechanism which would help.
1 Like