Mayavi: Orden incorrecto en los objetos de primer plano (visibilidad de objeto incorrecta)

Creado en 21 jun. 2018  ·  27Comentarios  ·  Fuente: enthought/mayavi

Estoy lejos de ser competente con la visualización 3D y no estoy seguro de que este sea un problema mayavi como tal (disculpas si ladro al árbol equivocado), pero observo el siguiente comportamiento inesperado:

Medio ambiente:

conda, anaconda 3, instaló mayavi usando pip install mayavi vtk pyqt5 lugar de conda (después de tropezar con un problema similar al # 652)

Debian 4.9.88-1+deb9u1 (2018-05-07) x86_64 GNU/Linux
Name: mayavi
Version: 4.6.0
Name: vtk
Version: 8.1.0
Location: /home/xxxyyy/anaconda3/envs/ELA/lib/python3.6/site-packages

Repro

# example from https://stackoverflow.com/a/10740780
from mayavi import mlab
import numpy as np

# Generate some random hypocenters
x, y, z, mag = np.random.random((4, 500))

# Make a curved well bore...
wellx, welly, wellz = 3 * [np.linspace(0, 1.5, 10)]
wellz =  wellz**2

# Plot the hypocenters, colored and scaled by magnitude
mlab.points3d(x, y, z, mag)

# Plot the wellbore
mlab.plot3d(wellx, welly, wellz, tube_radius=0.1)

mlab.show()

Las bolas de colores deben rodear la tubería gris, ocultando partes de ella, debajo.
Obtengo los comportamientos esperados con una versión anterior de mayavi en un sistema operativo diferente: Windows (versión de mayavi TBC, probablemente 4.5)

incorrect_foreground

Comentario más útil

He estado luchando con el mismo problema (renderizado de orden de profundidad incorrecto) usando Python3 durante las últimas semanas, y pensé en compartir mi experiencia aquí también (a partir de 2019-04-15).

Para que estemos en la misma página, aquí están las versiones que estoy viendo:

  • mayavi: 4.6.2
  • rasgos: 5.0.0
  • traitsui: 6.0.0
  • vtk: 8.1.2
  • prever: 4.7.1
  • pyface: 6.0.0
  • PyQt5: 5.12.1
  • PyQt4: 4.11.4 (_de dpkg_)
  • PySide: 1.2.2 (_de dpkg_)
  • PySide2: 5.12.2

Mayavi / VTK / traits puede usar el kit de herramientas 'wx' o el kit de herramientas 'qt4'. Con el kit de herramientas 'qt4', existe la opción adicional de especificar la API de QT; las opciones son 'pyqt', 'pyqt5', 'pyside' y 'pyside2'. Estos se especifican con las variables de entorno ETS_TOOLKIT (configúrelo en wx o qt4) y QT_API (configúrelo en pyqt, pyqt5, pyside o pyside2; solo se aplica si ETS_TOOLKIT está configurado como qt4).

Bajo Mint 18.3 (y probablemente para cualquier variante de Ubuntu 16.04), el Python3 oficial es 3.5.2. Algunos módulos están disponibles con apt / dpkg, pero varios requieren el uso de pip para su instalación. No pude instalar wxPython para Python3. Usando Qt, los resultados varían:

  • ETS_TOOLKIT = qt4 y QT_API = pyqt: se renderiza correctamente
  • ETS_TOOLKIT = qt4 y QT_API = pyqt5: renderizaciones con orden incorrecto
  • ETS_TOOLKIT = qt4 y QT_API = pyside: se renderiza correctamente
  • ETS_TOOLKIT = qt4 y QT_API = pyside2: renderizaciones con orden incorrecto

Con Mint 19.1 (y probablemente todas las variantes de Ubuntu 18.04) los resultados son similares. La versión de Python3 es 3.6.7; todos los módulos son los mismos que antes, excepto que aquí pude instalar wxPython (4.0.1) con pip3. En este caso, la configuración de ETS_TOOLKIT = wx proporciona el orden de profundidad correcto. En cuanto al kit de herramientas qt4, los resultados fueron los mismos que los de Mint 18.3 (es decir, pyqt y pyside se renderizaron correctamente; pyqt5 y pyside2 no).

Intenté compilar PySide2 desde la fuente y pude compilarlo; Sin embargo, la representación sigue siendo incorrecta.

También intenté usar pyenv para probar diferentes versiones de Python3 (en particular 3.5.2 y 3.7.3). En ambos casos, pude instalar los módulos necesarios a través de pip3, excepto que el código oficial de PySide no es compatible con versiones de Python superiores a 3.4. PySide2 está disponible, al igual que PyQt5; ninguno de estos funciona correctamente. No pude compilar wxPython.

En este punto, me pregunto si no es un problema de VTK, sino más bien un problema de QT (ahora me he rendido con wxPython). Pero curiosamente, en mi computadora portátil de trabajo (con Mint 18.3), con pyenv tenía Python 3.7.3 ejecutándose y, en este caso, el orden de profundidad se representó correctamente, ya sea con PyQt5 o PySide2 (mientras que en mi computadora portátil doméstica tanto QT_API dio el orden de profundidad incorrecto). Entonces, ¿cuál fue la diferencia? Por lo que puedo decir, la única diferencia fue el controlador OpenGL / GLX: las computadoras portátiles de mi hogar ejecutan el controlador SGI (según lo informado por glxinfo), mientras que mi computadora portátil de trabajo usa el controlador NVIDIA.

Finalmente, también intenté ejecutar un par de pruebas con VirtualBox (Mint 19.1 con xfce). Todavía estoy probando diferentes combinaciones, pero hasta ahora los resultados son los mismos. (El glxinfo informa que el controlador OpenGL / GLX es SGI).

Todos 27 comentarios

Parece que tengo el mismo problema con los puntos plot3d colocados alrededor de un 'globo':

    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 para backend de pyqt / pyside, probando en Debian stretch con [email protected] y [email protected]

Este es un problema general con VTK que parece y se ha visto antes en # 574 y # 491. No he tenido tiempo de explorar esto o encontrar una solución.

@ jmp75 tuve el mismo problema ... ¿podría confirmar qué versión de mayavi funcionó?

@lhvalentini Tengo esto funcionando usando un Anaconda 2 (python 2.7.15) en Windows 10, con los paquetes mayavi 4.5.0 y vtk 6.3.0.

Amigos, si esto es un problema de opacidad, es un problema diferente.

Probé el código de OP y funciona correctamente para mí. Si este es un problema específico del sistema operativo, probablemente sea un problema con sus controladores, ya que definitivamente me parece adecuado en mi máquina Mac OS con VTK 8.1.1 y Mayavi del maestro. Dudo que haya cambiado algo en Mayavi para solucionar este problema.

@prabhuramachandran Veré si puedo diagnosticar más para aislar la (a) causa raíz; de hecho, es probable que mayavi como tal no esté donde algo deba arreglarse, si es que lo hay, pero informaré en este hilo si puedo señalar algo útil.

Puedo reproducir el problema (usando el ejemplo de bolas de colores anterior) en RHEL 7, PyQt5 y Mayavi 4.6.2. He podido hacer que funcione correctamente desinstalando PyQt5 e instalando wxPython. Desafortunadamente, necesito PyQt5. En una de las dos máquinas con las que estoy trabajando, puedo ejecutarlo en VirtualGL (todavía usando RHEL 7, PyQt5 y Mayavi 4.6.2), y el problema desaparece. Sin embargo, en la otra máquina (la máquina de producción) VirtualGL hace que Mayavi se bloquee.

¿Alguna sugerencia sobre cómo solucionar este problema al usar PyQt5?

¿El hecho de que reproduje el problema en PyQt5 pero no en wxPython proporciona alguna pista?

Tengo un problema similar en 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, instalado desde conda-forge).

Si solo ejecuto la vainilla mlab.test_points3d() el orden del objeto es incorrecto:

test
test2
Traté de experimentar con las configuraciones antes mencionadas scene.renderer.use_depth_peeling y f.scene.renderer.maximum_number_of_peels , pero sin éxito.
¿Alguna idea de cuál podría ser la razón?

Una actualización. Este problema parece un problema de Qt5 en Linux. Puedo ver esto en mis máquinas ubuntu pero no en OS X. No estoy seguro de Windows. No lo veo con un backend Qt4. Por lo tanto, parece que el renderizado se estropea de alguna manera cuando usamos Qt5 y QVTKRenderWindowInteractor. También he informado de este problema a la gente de VTK. No estoy seguro de cuál es el problema.

El mismo problema aqui. Volví a Qt4 y todo funciona bien.

Tengo este problema en Linux con Qt4 (activado con% gui qt4 de ipython). Aunque quizás sea porque tengo Intel Graphics (algo relacionado ya mencionado en los problemas conocidos).

También tuve que instalar Qt4; de alguna manera antes de que simplemente poner "qt4" en las opciones no arrojaba un mensaje de error, sino que usaba Qt5 en su lugar.

ok, no me di cuenta de que qt4 no estaba instalado en mi extremo (de hecho, @ronceray , no produce un error) ...

PyQt 4.12.3 no se ejecutó, pero pude hacerlo funcionar con la versión 4.12.1 ..

Mucho más rezagado que PyQt5, pero no tiene este problema de primer plano ... ¡me evita configurar otra tarjeta gráfica!

Actualicé Fedora 27 -> Fedora 29 e instalé los últimos controladores de gráficos NVIDIA . Después de esto, mayavi funciona como se esperaba usando pyqt5.

He estado luchando con el mismo problema (renderizado de orden de profundidad incorrecto) usando Python3 durante las últimas semanas, y pensé en compartir mi experiencia aquí también (a partir de 2019-04-15).

Para que estemos en la misma página, aquí están las versiones que estoy viendo:

  • mayavi: 4.6.2
  • rasgos: 5.0.0
  • traitsui: 6.0.0
  • vtk: 8.1.2
  • prever: 4.7.1
  • pyface: 6.0.0
  • PyQt5: 5.12.1
  • PyQt4: 4.11.4 (_de dpkg_)
  • PySide: 1.2.2 (_de dpkg_)
  • PySide2: 5.12.2

Mayavi / VTK / traits puede usar el kit de herramientas 'wx' o el kit de herramientas 'qt4'. Con el kit de herramientas 'qt4', existe la opción adicional de especificar la API de QT; las opciones son 'pyqt', 'pyqt5', 'pyside' y 'pyside2'. Estos se especifican con las variables de entorno ETS_TOOLKIT (configúrelo en wx o qt4) y QT_API (configúrelo en pyqt, pyqt5, pyside o pyside2; solo se aplica si ETS_TOOLKIT está configurado como qt4).

Bajo Mint 18.3 (y probablemente para cualquier variante de Ubuntu 16.04), el Python3 oficial es 3.5.2. Algunos módulos están disponibles con apt / dpkg, pero varios requieren el uso de pip para su instalación. No pude instalar wxPython para Python3. Usando Qt, los resultados varían:

  • ETS_TOOLKIT = qt4 y QT_API = pyqt: se renderiza correctamente
  • ETS_TOOLKIT = qt4 y QT_API = pyqt5: renderizaciones con orden incorrecto
  • ETS_TOOLKIT = qt4 y QT_API = pyside: se renderiza correctamente
  • ETS_TOOLKIT = qt4 y QT_API = pyside2: renderizaciones con orden incorrecto

Con Mint 19.1 (y probablemente todas las variantes de Ubuntu 18.04) los resultados son similares. La versión de Python3 es 3.6.7; todos los módulos son los mismos que antes, excepto que aquí pude instalar wxPython (4.0.1) con pip3. En este caso, la configuración de ETS_TOOLKIT = wx proporciona el orden de profundidad correcto. En cuanto al kit de herramientas qt4, los resultados fueron los mismos que los de Mint 18.3 (es decir, pyqt y pyside se renderizaron correctamente; pyqt5 y pyside2 no).

Intenté compilar PySide2 desde la fuente y pude compilarlo; Sin embargo, la representación sigue siendo incorrecta.

También intenté usar pyenv para probar diferentes versiones de Python3 (en particular 3.5.2 y 3.7.3). En ambos casos, pude instalar los módulos necesarios a través de pip3, excepto que el código oficial de PySide no es compatible con versiones de Python superiores a 3.4. PySide2 está disponible, al igual que PyQt5; ninguno de estos funciona correctamente. No pude compilar wxPython.

En este punto, me pregunto si no es un problema de VTK, sino más bien un problema de QT (ahora me he rendido con wxPython). Pero curiosamente, en mi computadora portátil de trabajo (con Mint 18.3), con pyenv tenía Python 3.7.3 ejecutándose y, en este caso, el orden de profundidad se representó correctamente, ya sea con PyQt5 o PySide2 (mientras que en mi computadora portátil doméstica tanto QT_API dio el orden de profundidad incorrecto). Entonces, ¿cuál fue la diferencia? Por lo que puedo decir, la única diferencia fue el controlador OpenGL / GLX: las computadoras portátiles de mi hogar ejecutan el controlador SGI (según lo informado por glxinfo), mientras que mi computadora portátil de trabajo usa el controlador NVIDIA.

Finalmente, también intenté ejecutar un par de pruebas con VirtualBox (Mint 19.1 con xfce). Todavía estoy probando diferentes combinaciones, pero hasta ahora los resultados son los mismos. (El glxinfo informa que el controlador OpenGL / GLX es SGI).

Este hilo en VTK ML parece mencionar el mismo problema. Desafortunadamente, quedó sin respuesta ...

Por una corazonada, probé algo en mi computadora portátil Debian que valía la pena informar. Esta es una computadora portátil NVIDIA Optimus como se describe en la wiki de Debian . Básicamente, hay dos tarjetas gráficas en estos sistemas: NVIDIA e Intel.

Breve historia: en igualdad de condiciones, el script de prueba original que publiqué se renderiza incorrectamente en la tarjeta Intel pero correctamente en el hardware NVIDIA.

medio ambiente (paquetes relevantes):

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

Consulte la wiki de Debian para optirun . optirun python ~/src/tmp/qtbug.py funcionó correctamente. Para ilustrar la diferencia con / sin optirun , usando la aplicación de muestra:

glxgears -info devoluciones

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

mientras que optirun glxgears -info

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

Solo para agregar otra confirmación, aquí en Arch Linux en una Dell Precision 5520, veo el problema ejecutándose en el chip Intel, pero no con la tarjeta nvidia a través de optirun . Esto es con Python 3.7, Qt5 y mayavi, todos instalados a través de los repositorios oficiales de Arch.

El mismo problema, ejecutar mayavi con el backend PyQt5 da como resultado un orden de representación incorrecto al usar controladores Mesa / SGI en Debian Stretch, pero funciona con el conjunto de variables de entorno ETS_TOOLKIT=wx .

Resolví esto usando wxPython en lugar de PyQt.

Este hilo fue invaluable para resolver el problema, muchas gracias por los comentarios.

El mismo problema, no pude hacerlo funcionar con wx, así que instaló python-pyqt4, configure ETS_TOOLKIT=qt4 y QT_API=pyqt y esto lo ha resuelto.

Me gustaría agregar otra confirmación para una de las configuraciones mencionadas anteriormente. Estoy trabajando en una máquina Linux con Ubuntu 18.04 como sistema operativo. Mi sistema tiene una tarjeta gráfica Intel. Estoy usando anaconda3 para animar el movimiento de una partícula cargada. El resultado final debería ser una hélice con una línea que atraviese su centro. Para mi entorno Python 3.6.8 con mayavi 4.6.2, vtk 8.1.2 y pyqt 5.9.2, obtengo algo como esto:
snapshot
Tenga en cuenta que la línea roja parece estar fuera de la hélice, lo cual es incorrecto.

Para solucionar este problema, creé un nuevo entorno Python 3.5 en anaconda3 e instalé paquetes en el siguiente orden:

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

y establezca las variables relevantes en mi shell usando
exportar ETS_TOOLKIT = qt4
exportar QT_API = pyqt

y ejecuté mi código para obtener el diagrama correcto como se muestra a continuación
snapshot_right .
Gracias a todas las personas inteligentes de arriba que lo descubrieron. ¡Salud!

Después de reproducir el problema (usando el ejemplo de bolas de colores anterior) hoy, pude resolver el problema en un entorno de conda que contenía:

1) Python 3.8.5
2) VTK 9.0.1 (instalado usando un archivo whl)
3) pyqt5
4) Última versión 'Bleeding edge' de Mayavi (4.7.3.dev0).

Entonces, ¿quizás VTK 9 solucione este problema?

Puedo confirmar que VTK 9.0.1 con pyqt5 y Mayavi 4.7.2 (de conda-forge) soluciona este problema.

Sí, de hecho, puedo confirmar que este problema ahora está resuelto con VTK-9.0.1 y el último Mayavi, aunque parece que VTK es donde se originó la solución. Probé en una máquina Linux donde esto solía fallar antes. Esto es genial. Gracias por informarlo.

¿Fue útil esta página
0 / 5 - 0 calificaciones

Temas relacionados

relyativist picture relyativist  ·  16Comentarios

PennyQ picture PennyQ  ·  4Comentarios

rahulporuri picture rahulporuri  ·  3Comentarios

indranilsinharoy picture indranilsinharoy  ·  9Comentarios

rambalachandran picture rambalachandran  ·  9Comentarios