Mayavi: Falsche Reihenfolge bei Vordergrundobjekten (falsche Objektsichtbarkeit)

Ich scheine das gleiche Problem mit plot3d-Punkten zu haben, die um eine "Kugel" herum angeordnet sind:

    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 für pyqt/pyside-Backend, Testen auf Debian-Stretch mit [email protected] und [email protected]

Dies ist ein allgemeines Problem mit VTK, das bereits in #574 und #491 aufgetreten ist. Ich hatte nicht die Zeit, dies zu untersuchen oder eine Lösung zu finden.

@jmp75 Ich hatte das gleiche Problem.

@lhvalentini Ich habe dies mit einem Anaconda 2 (Python 2.7.15) unter Windows 10 mit den Paketen mayavi 4.5.0 und vtk 6.3.0.

Leute, wenn dies ein Problem mit der Deckkraft ist, ist das ein anderes Problem.

Ich habe den OPs-Code ausprobiert und er funktioniert bei mir richtig. Wenn dies ein betriebssystemspezifisches Problem ist, liegt es wahrscheinlich an Ihren Treibern, da es auf meinem Mac OS-Computer mit VTK 8.1.1 und Mayavi vom Master definitiv richtig für mich aussieht. Ich bezweifle, dass sich in Mayavi etwas geändert hat, um dies zu beheben.

@prabhuramachandran Ich werde sehen, ob ich weiter diagnostizieren kann, um die (a) Ursache zu isolieren; in der Tat ist mayavi als solches wahrscheinlich nicht dort, wo etwas repariert werden muss, wenn überhaupt, aber ich werde in diesem Thread berichten, wenn ich auf etwas Hilfreiches hinweisen kann.

Ich kann das Problem (mit dem obigen Beispiel mit farbigen Kugeln) auf RHEL 7, PyQt5 und Mayavi 4.6.2 reproduzieren. Ich habe es geschafft, dass es richtig funktioniert, indem ich PyQt5 deinstalliert und wxPython installiert habe. Leider brauche ich PyQt5. Auf einer der beiden Maschinen, mit denen ich arbeite, kann ich sie unter VirtualGL ausführen (immer noch mit RHEL 7, PyQt5 und Mayavi 4.6.2), und das Problem verschwindet. Auf der anderen Maschine (der Produktionsmaschine) führt VirtualGL jedoch zum Absturz von Mayavi.

Irgendwelche Vorschläge zur Behebung dieses Problems bei der Verwendung von PyQt5?

Gibt die Tatsache, dass ich das Problem in PyQt5 reproduziert habe, aber nicht in wxPython, irgendwelche Hinweise?

Ich habe ein ähnliches Problem unter Linux Mint 18, 64-Bit (Anaconda, Python 3.6, Qt 5.6.2, pyqt 5.6.0, VTK 8.1.1, Mayavi 4.6.2, installiert von Conda-Forge).

Wenn ich nur die Vanille mlab.test_points3d() ausführe, ist die Objektreihenfolge falsch:

Ich habe versucht, mit den oben genannten Einstellungen scene.renderer.use_depth_peeling und f.scene.renderer.maximum_number_of_peels zu experimentieren, jedoch ohne Erfolg.
Irgendwelche Ideen, was der Grund sein könnte?

Ein Update. Dieses Problem sieht aus wie ein Qt5-Problem unter Linux. Ich kann dies auf meinen Ubuntu-Rechnern sehen, aber nicht auf OS X. Bei Windows bin ich mir nicht sicher. Ich sehe es nicht mit einem Qt4-Backend. Es sieht also so aus, als ob das Rendern irgendwie durcheinander ist, wenn wir Qt5 und den QVTKRenderWindowInteractor verwenden. Ich habe dieses Problem auch den VTK-Leuten gemeldet. Bin mir nicht sicher was das Problem ist.

Selbes Problem hier. Ich bin zu Qt4 zurückgekehrt und alles funktioniert gut.

Ich habe dieses Problem unter Linux mit Qt4 (aktiviert mit ipythons %gui qt4). Obwohl es vielleicht daran liegt, dass ich Intel Graphics habe (was bereits in den bekannten Problemen erwähnt wurde).

Ich musste auch Qt4 installieren; Irgendwie hat das bloße Einfügen von "qt4" in die Optionen vorher keine Fehlermeldung ergeben, sondern stattdessen Qt5 verwendet.

ok, ich wusste nicht, dass qt4 auf meiner Seite nicht installiert war (in der Tat, @ronceray , es gibt keinen Fehler) ...

PyQt 4.12.3 lief nicht, aber ich konnte es mit Version 4.12.1 zum Laufen bringen.

Viel langsamer als PyQt5, aber es hat nicht dieses Vordergrundproblem ... erspart mir das Einrichten einer anderen Grafikkarte!

Ich habe von Fedora 27 -> Fedora 29 aktualisiert und die neuesten NVIDIA-Grafiktreiber installiert . Danach funktioniert mayavi mit pyqt5 wie erwartet.

Ich habe in den letzten Wochen mit dem gleichen Problem (falsches Rendern der Tiefenreihenfolge) mit Python3 zu kämpfen und dachte, ich würde meine Erfahrungen auch hier teilen (Stand 2019-04-15).

Damit wir auf der gleichen Seite sind, hier sind die Versionen, die ich mir ansehe:

• mayavi: 4.6.2
• Eigenschaften: 5.0.0
• Eigenschaften: 6.0.0
• vtk: 8.1.2
• vorsehen: 4.7.1
• pyface: 6.0.0
• PyQt5: 5.12.1
• PyQt4: 4.11.4 (_von dpkg_)
• PySide: 1.2.2 (_von dpkg_)
• PySide2: 5.12.2

Mayavi/VTK/Traits können entweder das 'wx'-Toolkit oder das 'qt4'-Toolkit verwenden. Mit dem 'qt4'-Toolkit besteht die weitere Möglichkeit, die QT-API anzugeben; die Auswahlmöglichkeiten sind 'pyqt', 'pyqt5', 'pyside' und 'pyside2'. Diese werden mit den Umgebungsvariablen ETS_TOOLKIT (setze es auf wx oder qt4) und QT_API (setze es auf pyqt, pyqt5, pyside oder pyside2; nur anwendbar, wenn ETS_TOOLKIT auf qt4 gesetzt ist) angegeben.

Unter Mint 18.3 (und wahrscheinlich für jede Ubuntu 16.04-Variante) ist das offizielle Python3 3.5.2. Einige Module sind mit apt/dpkg verfügbar, aber einige erfordern die Verwendung von pip zur Installation. Ich konnte wxPython nicht für Python3 installieren. Bei Verwendung von Qt variieren die Ergebnisse:

• ETS_TOOLKIT=qt4 und QT_API=pyqt : Rendert korrekt
• ETS_TOOLKIT=qt4 und QT_API=pyqt5 : rendert mit falscher Reihenfolge
• ETS_TOOLKIT=qt4 und QT_API=pyside : Rendert korrekt
• ETS_TOOLKIT=qt4 und QT_API=pyside2: rendert mit falscher Reihenfolge

Bei Mint 19.1 (und wahrscheinlich allen Ubuntu 18.04-Varianten) sind die Ergebnisse ähnlich. Die Python3-Version ist 3.6.7; alle Module sind die gleichen wie zuvor, nur dass ich hier wxPython (4.0.1) mit pip3 installieren konnte. In diesem Fall ergibt die Einstellung ETS_TOOLKIT=wx die richtige Tiefenreihenfolge. Beim qt4-Toolkit waren die Ergebnisse die gleichen wie bei den Mint 18.3-Ergebnissen (dh pyqt und pyside wurden korrekt gerendert, pyqt5 und pyside2 nicht).

Ich habe versucht, PySide2 aus dem Quellcode zu kompilieren und konnte es zum Kompilieren bringen. das Rendering ist jedoch immer noch falsch.

Ich habe auch versucht, mit pyenv verschiedene Versionen von Python3 zu testen (insbesondere 3.5.2 und 3.7.3). In beiden Fällen konnte ich die erforderlichen Module über pip3 installieren, außer dass der offizielle PySide-Code keine Python-Versionen höher als 3.4 unterstützt. PySide2 ist ebenso verfügbar wie PyQt5; beides funktioniert nicht richtig. Ich konnte wxPython nicht zum Kompilieren bringen.

An dieser Stelle frage ich mich, ob es sich nicht um ein VTK-Problem handelt, sondern eher um ein QT-Problem (ich habe wxPython jetzt aufgegeben). Aber seltsamerweise auf meiner Arbeit Laptop (mit Minze 18.3), mit pyenv hatte ich Python 3.7.3 läuft, und in diesem Fall wurde die Tiefe , um richtig gemacht - mit beide PyQt5 oder PySide2 (während auf meinem Heim - Laptop beide der QT_API hat die falsche Tiefenreihenfolge angegeben). Was war also der Unterschied? Soweit ich das beurteilen kann, war der einzige Unterschied der OpenGL/GLX-Treiber: Auf meinen Heim-Laptops läuft der SGI-Treiber (wie von glxinfo berichtet), während mein Arbeits-Laptop den NVIDIA-Treiber verwendet.

Schließlich habe ich auch versucht, ein paar Tests mit VirtualBox (Mint 19.1 mit xfce) durchzuführen. Ich probiere immer noch verschiedene Kombinationen aus, aber bis jetzt sind die Ergebnisse die gleichen. (Die glxinfo meldet den OpenGL/GLX-Treiber als SGI).

Dieser Thread zu VTK ML scheint das gleiche Problem zu erwähnen. Leider blieb es unbeantwortet...

Aus einer Ahnung heraus habe ich auf meinem Debian-Laptop etwas ausprobiert, das es wert ist, berichtet zu werden. Dies ist ein NVIDIA Optimus-Laptop, wie im Debian-Wiki beschrieben . Grundsätzlich gibt es auf diesen Systemen zwei Grafikkarten: NVIDIA und Intel.

Kurzgeschichte: Wenn alle anderen Dinge gleich sind, rendert das ursprüngliche Testskript, das ich gepostet habe, falsch auf der Intel-Karte, aber korrekt auf der NVIDIA-Hardware.

Umgebung (relevante Pakete):

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

Informationen zur Verwendung von optirun Sie im Debian-Wiki . optirun python ~/src/tmp/qtbug.py hat richtig funktioniert. Um den Unterschied mit/ohne optirun zu veranschaulichen, verwenden Sie die Beispiel-App:

glxgears -info zurück

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

während optirun glxgears -info

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

Nur um eine weitere Bestätigung hinzuzufügen, hier auf Arch Linux auf einem Dell Precision 5520 sehe ich, dass das Problem auf dem Intel-Chip läuft, aber nicht mit der nvidia-Karte über optirun . Dies ist mit Python 3.7, Qt5 und mayavi, die alle über die offiziellen Repositorys von Arch installiert sind.

Das gleiche Problem, das Ausführen von mayavi mit PyQt5-Backend führt zu einer falschen Renderreihenfolge mit Mesa/SGI-Treibern auf Debian Stretch, aber es funktioniert mit der Umgebungsvariablen ETS_TOOLKIT=wx .

Ich habe dies gelöst, indem ich wxPython anstelle von PyQt verwendet habe.

Dieser Thread war einfach von unschätzbarem Wert bei der Lösung des Problems, vielen Dank für die Kommentare.

Das gleiche Problem, konnte es nicht mit wx zum Laufen bringen, also installierte python-pyqt4, setze ETS_TOOLKIT=qt4 und QT_API=pyqt und das hat es gelöst.

Ich möchte eine weitere Bestätigung für eine der oben genannten Konfigurationen hinzufügen. Ich arbeite an einem Linux-Rechner mit Ubuntu 18.04 als Betriebssystem. Mein System hat eine Intel Grafikkarte. Ich verwende Anaconda3, um die Bewegung eines geladenen Teilchens zu animieren. Das Endergebnis sollte eine Helix mit einer Linie sein, die durch ihre Mitte geht. Für meine Python 3.6.8-Umgebung mit mayavi 4.6.2, vtk 8.1.2 und pyqt 5.9.2 erhalte ich etwa Folgendes:

Beachten Sie, dass die rote Linie außerhalb der Helix zu liegen scheint, was falsch ist.

Um dieses Problem zu beheben, habe ich in anaconda3 eine neue Python 3.5-Umgebung erstellt und Pakete in der folgenden Reihenfolge installiert:

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

und setze die relevanten Variablen in meiner Shell mit
ETS_TOOLKIT=qt4 exportieren
export QT_API=pyqt

und führte meinen Code aus, um das richtige Diagramm wie unten gezeigt zu erhalten
.
Danke an all die schlauen Leute oben, die es herausgefunden haben. Danke schön!

Nachdem ich das Problem (mit dem obigen Beispiel mit farbigen Kugeln) heute reproduziert hatte, konnte ich das Problem in einer Conda-Umgebung lösen, die Folgendes enthielt:

1) Python 3.8.5
2) VTK 9.0.1 (installiert über eine WHL-Datei)
3) pyqt5
4) Neueste 'Bleeding Edge'-Version von Mayavi (4.7.3.dev0).

Vielleicht behebt VTK 9 dieses Problem?

Ich kann bestätigen, dass VTK 9.0.1 mit pyqt5 und Mayavi 4.7.2 (von conda-forge) dieses Problem behebt.

Ja, ich kann bestätigen, dass dieses Problem jetzt mit VTK-9.0.1 und dem neuesten Mayavi behoben ist, obwohl es so aussieht, als ob der Fix von VTK stammt. Ich habe auf einem Linux-Rechner getestet, wo dies früher fehlgeschlagen ist. Das ist toll. Danke, dass du es gemeldet hast.