'pyvista-plot' directive for embedded-interactive viewers doesn't work for MultiBlock Objects

[Evan Rose]

Describe the bug, what's wrong, and what you expected.

I recently tested your sphinx-build process with the goal of using embedded-interactive viewers on the web, as is done in PyVista's documentation. This process went smoothly and your examples worked from this repo. However, when creating my own example that used a combination of a single PolyData object and another MultiBlock object, I found that only the PolyData object was actually rendered. I assumed this was a mistake on my side, but after checking PyVista's Documentation for greater insight on MultiBlocks, it seems the error is persisting on your end as well. If you visit this section of PyVista's documentation, and click interactive_scene on any of the examples, you'll see what I'm talking about.

Thanks for your help and time as always.

Steps to reproduce the bug.

data = [
    pv.Sphere(center=(2, 0, 0)),
    pv.Cube(center=(0, 2, 0)),
    pv.Cone(),
]
blocks = pv.MultiBlock(data)
blocks.plot()

Used in tandem with PyVistas pyvista-plot directive. See this section of PyVista's Documentation and try to interactively render one of the code examples.

System Information

This is demonstrated on version 0.43 of PyVista's Documentation (https://docs.pyvista.org/version/stable/api/core/_autosummary/pyvista.multiblock).

--------------------------------------------------------------------------------
  Date: Wed Mar 20 20:47:07 2024 UTC

                  OS : Linux
              CPU(s) : 20
             Machine : x86_64
        Architecture : 64bit
                 RAM : 125.8 GiB
         Environment : IPython
         File system : ext4
          GPU Vendor : Mesa/X.org
        GPU Renderer : llvmpipe (LLVM 15.0.6, 256 bits)
         GPU Version : 4.5 (Core Profile) Mesa 22.3.2
    MathText Support : True

  Python 3.10.13 (main, Sep 11 2023, 13:44:35) [GCC 11.2.0]

             pyvista : 0.43.4
                 vtk : 9.3.0
               numpy : 1.26.4
          matplotlib : 3.8.3
              scooby : 0.9.2
               pooch : 1.8.1
              pillow : 10.2.0
             IPython : 8.22.2
          ipywidgets : 8.1.2
               scipy : 1.11.4
               trame : 3.5.3
        trame_client : 2.16.3
        trame_server : 2.17.2
           trame_vtk : 2.8.5
       trame_vuetify : 2.4.3
jupyter_server_proxy : 4.1.2
        nest_asyncio : 1.6.0

  Intel(R) oneAPI Math Kernel Library Version 2023.1-Product Build 20230303
  for Intel(R) 64 architecture applications
--------------------------------------------------------------------------------

Screenshots

Screen.Recording.2024-03-20.at.2.44.47.PM.mov

[MatthewFlamm]

This looks like a duplicate of #5361 although this one more linearly describes the problem.

[Evan Rose]

@MatthewFlamm sorry for missing that issue you mentioned. Another important part of this I forgot to add is that the MultiBlock Object[s] is actually rendered correctly when I build and host my documentation locally. It's with the remote build/hosting that the MultiBlock object[s] isn't rendered at all. I'll attach two screen captures which show what I'm talking about. I built the documentation with the same example for both local and remote.

I also was able to remotely render the PolyData + MultiBlock objects fine using Trame, and they rendered appropriately using a custom embedded viewer I made which stemmed off of VTK's OfflineLocalView Example.

Here is the pyvista-plot directive used locally in the docs I built:

Screen.Recording.2024-03-21.at.9.27.36.AM.mov

And here is the same process done, only it's been hosted/rendered remotely.

Screen.Recording.2024-03-21.at.9.32.49.AM.mov

[Sebastien Jourdain (Kitware)]

I think I know why...

Sorry to go into the details, but the remote setup use vtk-osmesa while the local one (working) is using regular vtk.
When the scene get serialized, we have a mapping between the server objects and the vtk-js ones. And I think the issue is that we are missing a mapping when the class is from osmesa vs xlib.

So to fix that issue we will need to properly register that missing class here, but for that we would need to get the name of the missing serializable class. Which you might be able to get it you do the following locally to run with osmesa

pip uninstall vtk
pip install vtk-osmesa --extra-index-url https://wheels.vtk.org

I think by default, you should see some log either on the python side or on the client side.
If it is on the client side, you might be able to know which class name is the culprit right away without any new testing.

HTH

[Christos Tsolakis]

I think I know why...

Sorry to go into the details, but the remote setup use vtk-osmesa while the local one (working) is using regular vtk. When the scene get serialized, we have a mapping between the server objects and the vtk-js ones. And I think the issue is that we are missing a mapping when the class is from osmesa vs xlib.

So to fix that issue we will need to properly register that missing class here, but for that we would need to get the name of the missing serializable class. Which you might be able to get it you do the following locally to run with osmesa

pip uninstall vtk
pip install vtk-osmesa --extra-index-url https://wheels.vtk.org

I think by default, you should see some log either on the python side or on the client side. If it is on the client side, you might be able to know which class name is the culprit right away without any new testing.

HTH

The instructions were spot on and extremely helpful! A fix for trame-vtk here