Mayavi: Ordem incorreta em objetos de primeiro plano (visibilidade de objeto incorreta)

Criado em 21 jun. 2018  ·  27Comentários  ·  Fonte: enthought/mayavi

Estou longe de ser proficiente com visualização em 3D e não tenho certeza se isso é um problema mayavi como tal (desculpas se eu latir para a árvore errada), mas observo o seguinte comportamento inesperado:

Ambiente:

conda, anaconda 3, instalou mayavi usando pip install mayavi vtk pyqt5 vez de conda (depois de encontrar um problema semelhante ao # 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()

As bolas coloridas devem circundar o tubo cinza, escondendo partes dele, abaixo.
Obtenho os comportamentos esperados com uma versão anterior do mayavi em um sistema operacional diferente - Windows (mayavi versão TBC, provavelmente 4.5)

incorrect_foreground

Comentários muito úteis

Tenho lutado com o mesmo problema (renderização de ordem de profundidade incorreta) usando Python3 nas últimas semanas e pensei em compartilhar minha experiência aqui também (em 15/04/2019).

Só para estarmos na mesma página, aqui estão as versões que estou vendo:

  • mayavi: 4.6.2
  • traços: 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 pode usar o kit de ferramentas 'wx' ou o kit de ferramentas 'qt4'. Com o kit de ferramentas 'qt4', existe a opção adicional de especificar a API QT; as opções são 'pyqt', 'pyqt5', 'pyside' e 'pyside2'. Eles são especificados com as variáveis ​​de ambiente ETS_TOOLKIT (defina-o como wx ou qt4) e QT_API (defina-o como pyqt, pyqt5, pyside ou pyside2; apenas aplicável se ETS_TOOLKIT estiver definido como qt4).

No Mint 18.3 (e provavelmente para qualquer variante do Ubuntu 16.04), o Python3 oficial é 3.5.2. Alguns módulos estão disponíveis com apt / dpkg, mas vários requerem o uso de pip para instalação. Não consegui instalar o wxPython para Python3. Usando Qt, os resultados variam:

  • ETS_TOOLKIT = qt4 e QT_API = pyqt: renderiza corretamente
  • ETS_TOOLKIT = qt4 e QT_API = pyqt5: renderiza com a ordem errada
  • ETS_TOOLKIT = qt4 e QT_API = pyside: renderiza corretamente
  • ETS_TOOLKIT = qt4 e QT_API = pyside2: renderiza com a ordem errada

Com o Mint 19.1 (e provavelmente todas as variantes do Ubuntu 18.04), os resultados são semelhantes. A versão Python3 é 3.6.7; todos os módulos são os mesmos de antes, exceto que aqui eu consegui instalar wxPython (4.0.1) com pip3. Neste caso, definir ETS_TOOLKIT = wx fornece a ordem de profundidade correta. Quanto ao kit de ferramentas qt4, os resultados foram iguais aos resultados do Mint 18.3 (ou seja, pyqt e pyside renderizados corretamente; pyqt5 e pyside2 não).

Tentei compilar o PySide2 a partir do código-fonte e consegui fazê-lo compilar; a renderização ainda está errada no entanto.

Também tentei usar o pyenv para testar diferentes versões do Python3 (em particular 3.5.2 e 3.7.3). Em ambos os casos, eu poderia instalar os módulos necessários por meio do pip3, exceto que o código oficial do PySide não suporta versões do Python superiores a 3.4. PySide2 está disponível, assim como PyQt5; nenhum deles funciona corretamente. Não consegui compilar o wxPython.

Neste ponto, gostaria de saber se não é um problema VTK, mas sim um problema QT (desisti de wxPython agora). Mas curiosamente, no meu laptop de trabalho (com Mint 18.3), com pyenv eu tinha o Python 3.7.3 em execução e, neste caso, a ordem de profundidade foi renderizada corretamente - com PyQt5 ou PySide2 (enquanto no meu laptop doméstico ambos QT_API forneceu a ordem de profundidade errada). Então, qual foi a diferença? Até onde eu posso dizer, a única diferença era o driver OpenGL / GLX: meus laptops domésticos rodam o driver SGI (conforme relatado por glxinfo), enquanto meu laptop de trabalho usa o driver NVIDIA.

Por fim, também tentei executar alguns testes com o VirtualBox (Mint 19.1 com xfce). Ainda estou tentando combinações diferentes, mas até agora os resultados são os mesmos. (O glxinfo relata o driver OpenGL / GLX como SGI).

Todos 27 comentários

Parece que estou tendo o mesmo problema com pontos plot3d colocados ao redor de um '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 pyqt / pyside, testando no Debian stretch com [email protected] e [email protected]

Este é um problema geral com VTK que aparece e foi visto antes em # 574 e # 491. Não tive tempo para explorar isso ou encontrar uma solução.

@ jmp75 eu tive o mesmo problema

@lhvalentini Eu tenho isso funcionando usando um Anaconda 2 (python 2.7.15) no Windows 10, com os pacotes mayavi 4.5.0 e vtk 6.3.0.

Gente, se esse é um problema de opacidade, é um problema diferente.

Eu tentei o código OPs e ele funciona corretamente para mim. Se este for um problema específico do sistema operacional, provavelmente é um problema com seus drivers, pois definitivamente parece certo para mim em minha máquina Mac OS com VTK 8.1.1 e Mayavi do master. Duvido que algo tenha mudado em Mayavi para consertar isso.

@prabhuramachandran Vou ver se consigo diagnosticar melhor para isolar a (a) causa raiz; de fato, mayavi como tal provavelmente não estará onde algo precisa ser consertado, mas relatarei neste tópico se eu puder apontar para algo útil.

Posso reproduzir o problema (usando o exemplo de bolas coloridas acima) no RHEL 7, PyQt5 e Mayavi 4.6.2. Consegui fazê-lo funcionar corretamente desinstalando o PyQt5 e instalando o wxPython. Infelizmente, preciso do PyQt5. Em uma das duas máquinas com as quais estou trabalhando, posso executá-lo no VirtualGL (ainda usando RHEL 7, PyQt5 e Mayavi 4.6.2) e o problema desaparece. No entanto, na outra máquina (a máquina de produção), o VirtualGL causa o travamento do Mayavi.

Alguma sugestão sobre como consertar isso ao usar PyQt5?

O fato de eu ter reproduzido o problema no PyQt5, mas não no wxPython, fornece alguma pista?

Tenho um problema semelhante no Linux Mint 18 de 64 bits (Anaconda, Python 3.6, Qt 5.6.2, pyqt 5.6.0, VTK 8.1.1, Mayavi 4.6.2, instalado de conda-forge).

Se eu apenas executar o vanilla mlab.test_points3d() a ordem do objeto estará incorreta:

test
test2
Tentei experimentar as configurações mencionadas scene.renderer.use_depth_peeling e f.scene.renderer.maximum_number_of_peels , mas sem sucesso.
Alguma ideia de qual poderia ser o motivo?

Uma atualização. Este problema se parece com um problema do Qt5 no Linux. Consigo ver isso nas minhas máquinas Ubuntu, mas não no OS X. Não tenho certeza sobre o Windows. Eu não vejo isso com um backend Qt4. Portanto, parece que a renderização fica complicada quando usamos Qt5 e o QVTKRenderWindowInteractor. Eu relatei esse problema para o pessoal do VTK também. Não tenho certeza de qual é o problema.

Mesmo problema aqui. Voltei para o Qt4 e tudo funciona bem.

Eu tenho esse problema no Linux com Qt4 (ativado com% gui qt4 do ipython). Embora talvez seja porque eu tenho Intel Graphics (algo relacionado já mencionado nos problemas conhecidos).

Tive que instalar o Qt4 também; de alguma forma, antes disso, apenas colocar "qt4" nas opções não gerou uma mensagem de erro, mas usei Qt5 em seu lugar.

ok, não percebi que o qt4 não estava instalado no meu terminal (na verdade, @ronceray , não produz um erro) ...

O PyQt 4.12.3 não foi executado, mas consegui fazê-lo funcionar com a versão 4.12.1 ..

Muito mais lento que o PyQt5, mas não tem esse problema de primeiro plano ... evita que eu configure outra placa de vídeo!

Eu atualizei do Fedora 27 -> Fedora 29 e instalei os drivers gráficos NVIDIA mais recentes . Depois disso, o mayavi executa conforme o esperado usando pyqt5.

Tenho lutado com o mesmo problema (renderização de ordem de profundidade incorreta) usando Python3 nas últimas semanas e pensei em compartilhar minha experiência aqui também (em 15/04/2019).

Só para estarmos na mesma página, aqui estão as versões que estou vendo:

  • mayavi: 4.6.2
  • traços: 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 pode usar o kit de ferramentas 'wx' ou o kit de ferramentas 'qt4'. Com o kit de ferramentas 'qt4', existe a opção adicional de especificar a API QT; as opções são 'pyqt', 'pyqt5', 'pyside' e 'pyside2'. Eles são especificados com as variáveis ​​de ambiente ETS_TOOLKIT (defina-o como wx ou qt4) e QT_API (defina-o como pyqt, pyqt5, pyside ou pyside2; apenas aplicável se ETS_TOOLKIT estiver definido como qt4).

No Mint 18.3 (e provavelmente para qualquer variante do Ubuntu 16.04), o Python3 oficial é 3.5.2. Alguns módulos estão disponíveis com apt / dpkg, mas vários requerem o uso de pip para instalação. Não consegui instalar o wxPython para Python3. Usando Qt, os resultados variam:

  • ETS_TOOLKIT = qt4 e QT_API = pyqt: renderiza corretamente
  • ETS_TOOLKIT = qt4 e QT_API = pyqt5: renderiza com a ordem errada
  • ETS_TOOLKIT = qt4 e QT_API = pyside: renderiza corretamente
  • ETS_TOOLKIT = qt4 e QT_API = pyside2: renderiza com a ordem errada

Com o Mint 19.1 (e provavelmente todas as variantes do Ubuntu 18.04), os resultados são semelhantes. A versão Python3 é 3.6.7; todos os módulos são os mesmos de antes, exceto que aqui eu consegui instalar wxPython (4.0.1) com pip3. Neste caso, definir ETS_TOOLKIT = wx fornece a ordem de profundidade correta. Quanto ao kit de ferramentas qt4, os resultados foram iguais aos resultados do Mint 18.3 (ou seja, pyqt e pyside renderizados corretamente; pyqt5 e pyside2 não).

Tentei compilar o PySide2 a partir do código-fonte e consegui fazê-lo compilar; a renderização ainda está errada no entanto.

Também tentei usar o pyenv para testar diferentes versões do Python3 (em particular 3.5.2 e 3.7.3). Em ambos os casos, eu poderia instalar os módulos necessários por meio do pip3, exceto que o código oficial do PySide não suporta versões do Python superiores a 3.4. PySide2 está disponível, assim como PyQt5; nenhum deles funciona corretamente. Não consegui compilar o wxPython.

Neste ponto, gostaria de saber se não é um problema VTK, mas sim um problema QT (desisti de wxPython agora). Mas curiosamente, no meu laptop de trabalho (com Mint 18.3), com pyenv eu tinha o Python 3.7.3 em execução e, neste caso, a ordem de profundidade foi renderizada corretamente - com PyQt5 ou PySide2 (enquanto no meu laptop doméstico ambos QT_API forneceu a ordem de profundidade errada). Então, qual foi a diferença? Até onde eu posso dizer, a única diferença era o driver OpenGL / GLX: meus laptops domésticos rodam o driver SGI (conforme relatado por glxinfo), enquanto meu laptop de trabalho usa o driver NVIDIA.

Por fim, também tentei executar alguns testes com o VirtualBox (Mint 19.1 com xfce). Ainda estou tentando combinações diferentes, mas até agora os resultados são os mesmos. (O glxinfo relata o driver OpenGL / GLX como SGI).

Este tópico no VTK ML parece mencionar o mesmo problema. Infelizmente, ficou sem resposta ...

Seguindo um palpite, tentei algo no meu laptop Debian que vale a pena relatar. Este é um laptop NVIDIA Optimus conforme descrito no wiki do Debian . Basicamente, existem duas placas gráficas nesses sistemas: NVIDIA e Intel.

Breve história: todas as outras coisas sendo iguais, o script de teste original que postei renderiza incorretamente na placa Intel, mas corretamente no hardware NVIDIA.

ambiente (pacotes 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 o wiki do Debian para saber como usar optirun . optirun python ~/src/tmp/qtbug.py funcionou corretamente. Para ilustrar a diferença com / sem optirun , usando o aplicativo de amostra:

glxgears -info retorna

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

enquanto optirun glxgears -info

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

Só para adicionar outra confirmação, aqui no Arch Linux em um Dell Precision 5520, vejo o problema rodando no chip intel, mas não com a placa nvidia via optirun . Isso ocorre com o Python 3.7, Qt5 e mayavi, todos instalados por meio dos repositórios oficiais do Arch.

Mesmo problema, rodar mayavi com backend PyQt5 resulta em ordem de renderização incorreta usando drivers Mesa / SGI no Debian Stretch, mas funciona com ETS_TOOLKIT=wx variável de ambiente definida.

Resolvi isso usando wxPython em vez de PyQt.

Este tópico foi inestimável para resolver o problema, muito obrigado pelos comentários.

Mesmo problema, não conseguia fazer funcionar com wx, então instalei python-pyqt4, defina ETS_TOOLKIT=qt4 e QT_API=pyqt e isso resolveu o problema.

Gostaria de adicionar outra confirmação para uma das configurações mencionadas acima. Estou trabalhando em uma máquina Linux com Ubuntu 18.04 como sistema operacional. Meu sistema possui uma placa de vídeo Intel. Estou usando o anaconda3 para animar o movimento de uma partícula carregada. O resultado final deve ser uma hélice com uma linha passando por seu centro. Para meu ambiente Python 3.6.8 com mayavi 4.6.2, vtk 8.1.2 e pyqt 5.9.2, recebo algo assim:
snapshot
Observe que a linha vermelha parece estar fora da hélice, o que está errado.

Para corrigir esse problema, criei um novo ambiente Python 3.5 no anaconda3 e instalei os pacotes na seguinte ordem:

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

e definir as variáveis ​​relevantes em meu shell usando
export ETS_TOOLKIT = qt4
exportar QT_API = pyqt

e executei meu código para obter o diagrama correto, conforme mostrado abaixo
snapshot_right .
Obrigado a todas as pessoas inteligentes acima que descobriram isso. Saúde!

Depois de reproduzir o problema (usando o exemplo de bolas coloridas acima) hoje cedo, consegui resolver o problema em um ambiente conda que continha:

1) Python 3.8.5
2) VTK 9.0.1 (instalado usando um arquivo whl)
3) pyqt5
4) Última versão 'Bleeding edge' do Mayavi (4.7.3.dev0).

Então, talvez o VTK 9 resolva esse problema?

Posso confirmar que o VTK 9.0.1 com pyqt5 e Mayavi 4.7.2 (de conda-forge) corrige esse problema.

Sim, posso confirmar que esse problema agora foi resolvido com o VTK-9.0.1 e o Mayavi mais recente, embora pareça que o VTK é onde a correção se originou. Eu testei em uma máquina Linux onde isso costumava falhar antes. Isso é ótimo. Obrigado por relatar isso.

Esta página foi útil?
0 / 5 - 0 avaliações

Questões relacionadas

ktavabi picture ktavabi  ·  15Comentários

yassersouri picture yassersouri  ·  5Comentários

dnacombo picture dnacombo  ·  7Comentários

aestrivex picture aestrivex  ·  9Comentários

Kekushke picture Kekushke  ·  9Comentários