Mayavi: Ordre incorrect dans les objets de premier plan (mauvaise visibilité de l'objet)

Je semble avoir le même problème avec les points plot3d placés autour d'un "globe":

    sphere = mlab.points3d(0, 0, 0, scale_mode='none',
                           scale_factor=2,
                           # color=(0.67, 0.77, 0.93),
                           color=ocean_blue,
                           resolution=50,
                           opacity=.85,
                           name='Earth')
    #
    # These parameters, as well as the color, where tweaked through the GUI,
    # with the record mode to produce lines of code usable in a script.
    sphere.actor.property.specular = 0.45
    sphere.actor.property.specular_power = 5
    # Backface culling is necessary for more a beautiful transparent
    # rendering.
    sphere.actor.property.backface_culling = True

+1 pour le backend pyqt/pyside, test sur Debian stretch avec [email protected] et [email protected]

Il s'agit d'un problème général avec VTK, il apparaît et a déjà été vu dans les numéros 574 et 491. Je n'ai pas eu le temps d'explorer cela ou de trouver une solution.

@ jmp75 j'ai eu le même problème

@lhvalentini Cela fonctionne avec un Anaconda 2 (python 2.7.15) sur Windows 10, avec les packages mayavi 4.5.0 et vtk 6.3.0.

Mes amis, s'il s'agit d'un problème d'opacité, c'est un problème différent.

J'ai essayé le code OPs et cela fonctionne correctement pour moi. S'il s'agit d'un problème spécifique au système d'exploitation, il s'agit probablement d'un problème avec vos pilotes, car il me convient parfaitement sur ma machine Mac OS avec VTK 8.1.1 et Mayavi de master. Je doute que quelque chose ait changé dans Mayavi pour résoudre ce problème.

@prabhuramachandran Je vais voir si je peux diagnostiquer davantage pour isoler la (a) cause première ; en effet, il est peu probable que mayavi en tant que tel soit l'endroit où quelque chose doit être corrigé, mais il sera signalé dans ce fil si je peux indiquer quelque chose d'utile.

Je peux reproduire le problème (en utilisant l'exemple de boules colorées ci-dessus) sur RHEL 7, PyQt5 et Mayavi 4.6.2. J'ai pu le faire fonctionner correctement en désinstallant PyQt5 et en installant wxPython. Malheureusement, j'ai besoin de PyQt5. Sur l'une des deux machines avec lesquelles je travaille, je peux l'exécuter sous VirtualGL (en utilisant toujours RHEL 7, PyQt5 et Mayavi 4.6.2), et le problème disparaît. Cependant, sur l'autre machine (la machine de production), VirtualGL fait planter Mayavi.

Des suggestions sur la façon de résoudre ce problème lors de l'utilisation de PyQt5 ?

Le fait que j'aie reproduit le problème dans PyQt5 mais pas dans wxPython fournit-il des indices ?

J'ai un problème similaire sur Linux Mint 18, 64 bits (Anaconda, Python 3.6, Qt 5.6.2, pyqt 5.6.0, VTK 8.1.1, Mayavi 4.6.2, installé depuis conda-forge).

Si je viens de lancer la vanille mlab.test_points3d() l'ordre des objets est incorrect :

J'ai essayé d'expérimenter avec les paramètres susmentionnés scene.renderer.use_depth_peeling et f.scene.renderer.maximum_number_of_peels , mais sans succès.
Des idées quelle pourrait être la raison?

Une mise à jour. Ce problème ressemble à un problème Qt5 sous Linux. Je peux voir cela sur mes machines Ubuntu mais pas sur OS X. Je ne suis pas sûr de Windows. Je ne le vois pas avec un backend Qt4. Il semble donc que le rendu soit perturbé lorsque nous utilisons Qt5 et QVTKRenderWindowInteractor. J'ai également signalé ce problème en amont aux gens de VTK. Je ne sais pas quel est le problème.

Même problème ici. Je suis revenu à Qt4 et tout fonctionne bien.

J'ai ce problème sous Linux avec Qt4 (activé avec %gui qt4 d'ipython). Bien que ce soit peut-être parce que j'ai Intel Graphics (quelque chose de lié déjà mentionné dans les problèmes connus).

J'ai également dû installer Qt4 ; avant cela, le simple fait de mettre "qt4" dans les options ne produisait pas de message d'erreur, mais utilisait Qt5 à la place.

ok je n'avais pas réalisé que qt4 n'était pas installé de mon côté (en effet, @ronceray , cela ne

PyQt 4.12.3 n'a pas fonctionné, mais j'ai pu le faire fonctionner avec la version 4.12.1.

Beaucoup plus tardif que PyQt5, mais il n'a pas ce problème de premier plan... m'évite de configurer une autre carte graphique !

J'ai mis à niveau de Fedora 27 -> Fedora 29 et installé les derniers pilotes graphiques NVIDIA . Après cela, mayavi fonctionne comme prévu en utilisant pyqt5.

J'ai été aux prises avec le même problème (rendu d'ordre de profondeur incorrect) en utilisant Python3 au cours des dernières semaines, et j'ai pensé partager mon expérience ici également (au 15-04-2019).

Juste pour que nous soyons sur la même page, voici les versions que je regarde :

• mayavi: 4.6.2
• traits : 5.0.0
• traitsui: 6.0.0
• vtk : 8.1.2
• prévoir : 4.7.1
• pyface: 6.0.0
• PyQt5 : 5.12.1
• PyQt4 : 4.11.4 (_de dpkg_)
• PySide : 1.2.2 (_depuis dpkg_)
• PySide2 : 5.12.2

Mayavi/VTK/traits peut utiliser la boîte à outils « wx » ou la boîte à outils « qt4 ». Avec la boîte à outils 'qt4', il existe l'option supplémentaire de spécifier l'API QT ; les choix sont 'pyqt', 'pyqt5', 'pyside' et 'pyside2'. Ceux-ci sont spécifiés avec les variables d'environnement ETS_TOOLKIT (définissez-le sur wx ou qt4) et QT_API (définissez-le sur pyqt, pyqt5, pyside ou pyside2 ; applicable uniquement si ETS_TOOLKIT est défini sur qt4).

Sous Mint 18.3 (et probablement pour toute variante d'Ubuntu 16.04), le Python3 officiel est 3.5.2. Certains modules sont disponibles avec apt/dpkg, mais plusieurs nécessitent l'utilisation de pip pour l'installation. Je n'ai pas pu installer wxPython pour Python3. En utilisant Qt, les résultats varient :

• ETS_TOOLKIT=qt4 et QT_API=pyqt : rend correctement
• ETS_TOOLKIT=qt4 et QT_API=pyqt5 : rendus avec un mauvais ordre
• ETS_TOOLKIT=qt4 et QT_API=pyside : rend correctement
• ETS_TOOLKIT=qt4 et QT_API=pyside2 : rendus avec un mauvais ordre

Avec Mint 19.1 (et probablement toutes les variantes d'Ubuntu 18.04), les résultats sont similaires. La version Python3 est la 3.6.7 ; tous les modules sont les mêmes qu'avant, sauf qu'ici j'ai pu installer wxPython (4.0.1) avec pip3. Dans ce cas, le réglage ETS_TOOLKIT=wx donne l'ordre de profondeur correct. Quant à la boîte à outils qt4, les résultats étaient les mêmes que ceux de Mint 18.3 (c'est-à-dire que pyqt et pyside s'affichaient correctement ; pyqt5 et pyside2 ne l'étaient pas).

J'ai essayé de compiler PySide2 à partir des sources et j'ai pu le faire compiler ; le rendu est toujours faux cependant.

J'ai également essayé d'utiliser pyenv pour tester différentes versions de Python3 (en particulier 3.5.2 et 3.7.3). Dans les deux cas, j'ai pu installer les modules nécessaires via pip3, sauf que le code officiel PySide ne prend pas en charge les versions Python supérieures à 3.4. PySide2 est disponible, tout comme PyQt5 ; ni l'un ni l'autre ne fonctionne correctement. Je n'ai pas pu compiler wxPython.

À ce stade, je me demande s'il ne s'agit pas d'un problème VTK, mais plutôt d'un problème QT (j'ai abandonné wxPython maintenant). Mais curieusement, sur mon ordinateur portable de travail (avec Mint 18.3), avec pyenv, j'avais Python 3.7.3 en cours d'exécution, et dans ce cas, l'ordre de profondeur a été rendu correctement - avec PyQt5 ou PySide2 (alors que sur mon ordinateur portable personnel, les deux QT_API a donné le mauvais ordre de profondeur). Alors, quelle était la différence ? Pour autant que je sache, la seule différence était le pilote OpenGL/GLX : mes ordinateurs portables personnels exécutent le pilote SGI (comme indiqué par glxinfo), tandis que mon ordinateur portable professionnel utilise le pilote NVIDIA.

Enfin, j'ai également essayé d'exécuter quelques tests avec VirtualBox (Mint 19.1 avec xfce). J'essaie toujours différentes combinaisons, mais jusqu'à présent, les résultats sont les mêmes. (Le glxinfo signale le pilote OpenGL/GLX comme SGI).

Ce fil sur VTK ML semble mentionner le même problème. Malheureusement, il est resté sans réponse...

Sur un pressentiment, j'ai essayé quelque chose sur mon ordinateur portable Debian qui mérite d'être signalé. Il s'agit d'un ordinateur portable NVIDIA Optimus tel que décrit dans le wiki Debian . Fondamentalement, il y a deux cartes graphiques sur ces systèmes : NVIDIA et Intel.

Petite histoire : toutes choses étant égales par ailleurs, le script de test original que j'ai posté rend incorrectement sur la carte Intel mais correctement sur le matériel NVIDIA.

environnement (packages concernés) :

envisage                  4.7.2                    pypi_0    pypi
mayavi                    4.6.2                    pypi_0    pypi
pyface                    6.0.0                    pypi_0    pypi
pygments                  2.3.1                    pypi_0    pypi
pyqt5                     5.12.2                   pypi_0    pypi
pyqt5-sip                 4.19.17                  pypi_0    pypi
python                    3.6.8                h0371630_0  
traits                    5.1.1                    pypi_0    pypi
traitsui                  6.0.0                    pypi_0    pypi
vtk                       8.1.2                    pypi_0    pypi

Consultez le wiki Debian pour savoir comment utiliser optirun . optirun python ~/src/tmp/qtbug.py fonctionné correctement. Pour illustrer la différence avec/sans optirun , en utilisant l'exemple d'application :

glxgears -info retourne

GL_RENDERER   = Mesa DRI Intel(R) HD Graphics 630 (Kaby Lake GT2) 
GL_VERSION    = 3.0 Mesa 18.3.4
GL_VENDOR     = Intel Open Source Technology Center

alors que optirun glxgears -info

GL_RENDERER   = Quadro M1200/PCIe/SSE2
GL_VERSION    = 4.6.0 NVIDIA 418.56
GL_VENDOR     = NVIDIA Corporation

Juste pour ajouter une autre confirmation, ici sur Arch Linux sur un Dell Precision 5520, je vois le problème fonctionner sur la puce intel, mais pas avec la carte nvidia via optirun . C'est avec Python 3.7, Qt5 et mayavi tous installés via les dépôts officiels d'Arch.

Même problème, l'exécution de mayavi avec le backend PyQt5 entraîne un ordre de rendu incorrect à l'aide des pilotes Mesa/SGI sur Debian Stretch, mais cela fonctionne avec l'ensemble de variables d'environnement ETS_TOOLKIT=wx .

J'ai résolu ce problème en utilisant wxPython au lieu de PyQt.

Ce fil était tout simplement inestimable pour résoudre le problème, merci beaucoup pour les commentaires.

Même problème, impossible de le faire fonctionner avec wx, donc installé python-pyqt4, définissez ETS_TOOLKIT=qt4 et QT_API=pyqt et cela l'a résolu.

Je voudrais ajouter une autre confirmation pour l'une des configurations mentionnées ci-dessus. Je travaille sur une machine Linux avec Ubuntu 18.04 comme système d'exploitation. Mon système a une carte graphique Intel. J'utilise anaconda3 pour animer le mouvement d'une particule chargée. Le résultat final devrait être une hélice avec une ligne passant par son centre. Pour mon environnement Python 3.6.8 avec mayavi 4.6.2, vtk 8.1.2 et pyqt 5.9.2, j'obtiens quelque chose comme ceci :

Notez que la ligne rouge semble être à l'extérieur de l'hélice, ce qui est faux.

Pour résoudre ce problème, j'ai créé un nouvel environnement Python 3.5 dans anaconda3 et installé les packages dans l'ordre suivant :

pyqt 4.11.4 de conda-forge
vtk 8.1.2 de pypi
mayavi 4.6.2 de conda-forge

et définissez les variables pertinentes dans mon shell en utilisant
exporter ETS_TOOLKIT=qt4
exporter QT_API=pyqt

et exécuté mon code pour obtenir le diagramme correct comme indiqué ci-dessous
.
Merci à toutes les personnes intelligentes ci-dessus qui ont compris. À votre santé!

Après avoir reproduit le problème (en utilisant l'exemple de boules colorées ci-dessus) plus tôt dans la journée, j'ai pu résoudre le problème dans un environnement conda contenant :

1) Python 3.8.5
2) VTK 9.0.1 (installé à l'aide d'un fichier whl)
3) pyqt5
4) Dernière version 'Bleeding edge' de Mayavi (4.7.3.dev0).

Alors peut-être que VTK 9 résout ce problème ?

Je peux confirmer que VTK 9.0.1 avec pyqt5 et Mayavi 4.7.2 (de conda-forge) résout ce problème.

Oui en effet, je peux confirmer que ce problème est maintenant résolu avec VTK-9.0.1 et le dernier Mayavi, bien qu'il semble que VTK soit l'origine du correctif. J'ai testé sur une machine Linux où cela échouait auparavant. C'est bien. Merci de l'avoir signalé.