Hi all, I'm not sure whether this Intel problem comes from OCC or pythonOCC. I suspect a part of the initialization code of pythonOCC 0.4 (file Display3d.cpp) to be not really optimized. After diving into the Salome source code, I recently committed changes to this file ( http://code.google.com/p/pythonocc/source/diff?spec=svn1055&r=1039&format=side&path=/trunk/src/wrapper/Visualization/Display3d.cpp&old_path=/trunk/src/wrapper/Visualization/Display3d.cpp&old=1025) and moved the lights initialization (and made them optional) to the OCCViewer.py script ( http://code.google.com/p/pythonocc/source/diff?spec=svn1055&r=1039&format=side&path=/trunk/src/addons/Display/OCCViewer.py&old_path=/trunk/src/addons/Display/OCCViewer.py&old=909 ).
I guess it may fix this issue but it has to be tested on Linux platforms with Intel graphic driver. Best Regards, Thomas 2010/7/9 M. Nawijn <naw...@gmail.com> > Hello All, > > I have had some problems previously with getting the graphics working > properly (with > NVidia card), > one of the reasons was that after a package update, some of the symbolic > links > that link to the proper libGL* classes were set wrong. > > Before diving into the problem, can you confirm that the glxgears > utility found on most > of the linux systems is running without problems? If not, it is not > directly an OCC problem. > > Regards, > > Marco > > On Thu, Jul 8, 2010 at 3:28 PM, Oliver Borm <oli.b...@web.de> wrote: > > Just checked the OCC forum, but the only comment für WinXP was to use > > the mesa libraries. Unfortunately I'm using these libraries already with > > Intel graphic cards under kubuntu. Checked the linked libs of > > libTKOpenGl-6.3.0.so (as I thought this is the one which makes trouble - > > am I right?) > > > > ~$ ldd /usr/lib/libTKOpenGl-6.3.0.so > > linux-gate.so.1 => (0x00f4c000) > > libTKService-6.3.0.so => /usr/lib/libTKService-6.3.0.so(0x003d2000) > > libTKernel-6.3.0.so => /usr/lib/libTKernel-6.3.0.so (0x0058a000) > > libTKV3d-6.3.0.so => /usr/lib/libTKV3d-6.3.0.so (0x00afa000) > > libXt.so.6 => /usr/lib/libXt.so.6 (0x00110000) > > libX11.so.6 => /usr/lib/libX11.so.6 (0x00163000) > > libGLU.so.1 => /usr/lib/libGLU.so.1 (0x00280000) > > libGL.so.1 => /usr/lib/mesa/libGL.so.1 (0x00327000) > > libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0x002f1000) > > libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x007c5000) > > libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0x0038c000) > > libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x00f4d000) > > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x003b2000) > > libTKMath-6.3.0.so => /usr/lib/libTKMath-6.3.0.so (0x11fcd000) > > libXmu.so.6 => /usr/lib/libXmu.so.6 (0x008bb000) > > libXext.so.6 => /usr/lib/libXext.so.6 (0x00ee0000) > > libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0x00a28000) > > libTKG3d-6.3.0.so => /usr/lib/libTKG3d-6.3.0.so (0x041c7000) > > libTKTopAlgo-6.3.0.so => /usr/lib/libTKTopAlgo-6.3.0.so(0x083fe000) > > libTKGeomBase-6.3.0.so => /usr/lib/libTKGeomBase-6.3.0.so > > (0x17b10000) > > libTKMesh-6.3.0.so => /usr/lib/libTKMesh-6.3.0.so (0x00a2c000) > > libTKGeomAlgo-6.3.0.so => /usr/lib/libTKGeomAlgo-6.3.0.so > > (0x09050000) > > libTKHLR-6.3.0.so => /usr/lib/libTKHLR-6.3.0.so (0x0fa09000) > > libTKBRep-6.3.0.so => /usr/lib/libTKBRep-6.3.0.so (0x03432000) > > libTKG2d-6.3.0.so => /usr/lib/libTKG2d-6.3.0.so (0x009ae000) > > libTKV2d-6.3.0.so => /usr/lib/libTKV2d-6.3.0.so (0x0244f000) > > libSM.so.6 => /usr/lib/libSM.so.6 (0x008d2000) > > libICE.so.6 => /usr/lib/libICE.so.6 (0x008db000) > > libxcb.so.1 => /usr/lib/libxcb.so.1 (0x008f4000) > > libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0x0090e000) > > libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0x00914000) > > libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x00918000) > > libdrm.so.2 => /lib/libdrm.so.2 (0x0091e000) > > /lib/ld-linux.so.2 (0x0030a000) > > libuuid.so.1 => /lib/libuuid.so.1 (0x00929000) > > libXau.so.6 => /usr/lib/libXau.so.6 (0x0092e000) > > libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00a1a000) > > librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0x00f1c000) > > > > And the interesting part is: > > > > /usr/lib/dri/i965_dri.so this is the lib which seg faults and part of > > libgl1-mesa-dri > > /usr/lib/mesa/libGL.so.1 used lib is part of libgl1-mesa-glx > > /usr/lib/libGLU.so.1 used lib is part of libglu1-mesa > > > > Well if it is a OCC problem, does anybody has a small and simple test > > binary or know where to get one? > > > > Best, > > Oliver > > > > > > Am 08.07.2010 14:17, schrieb Jelle Feringa: > >> Interesting indeed. > >> I think this is a OCC, not so much =Python=OCC problem. > >> Have you checked the OCC forum? > >> > >> -jelle > >> > >> On Jul 8, 2010, at 2:13 PM, Marcos wrote: > >> > >> > > > > > > > > _______________________________________________ > > Pythonocc-users mailing list > > Pythonocc-users@gna.org > > https://mail.gna.org/listinfo/pythonocc-users > > > > _______________________________________________ > Pythonocc-users mailing list > Pythonocc-users@gna.org > https://mail.gna.org/listinfo/pythonocc-users >
_______________________________________________ Pythonocc-users mailing list Pythonocc-users@gna.org https://mail.gna.org/listinfo/pythonocc-users
