Warnings when rendering on a server not running x server

[James Penn]

🐛 Bug Report

(This can wait until after xmas! 🎅)

Data renders incorrectly on a jupyter notebook when run from a headless server.

Warnings are displayed that PyVista may segfault, and data appears to render incorrectly in threejs viewer.

This system does not appear to be running an xserver.
PyVista will likely segfault when rendering.

Try starting a virtual frame buffer with xvfb, or using
  ``pyvista.start_xvfb()``

  warnings.warn('\n'

I cannot use the provided suggested code as I do not have sudo rights to install additional packages

Input:

pyvista.start_xvfb()

Output:

---------------------------------------------------------------------------
OSError                                   Traceback (most recent call last)
/var/tmp/ipykernel_96063/1929267992.py in <module>
----> 1 pyvista.start_xvfb()

~/.conda/envs/geovista-dev/lib/python3.10/site-packages/pyvista/utilities/xvfb.py in start_xvfb(wait, window_size)
     45 
     46     if os.system('which Xvfb > /dev/null'):
---> 47         raise OSError(XVFB_INSTALL_NOTES)
     48 
     49     # use current default window size

OSError: Please install Xvfb with:

Debian
$ sudo apt install libgl1-mesa-glx xvfb

CentOS / RHL
$ sudo yum install libgl1-mesa-glx xvfb

How To Reproduce

Steps to reproduce the behaviour:

1. Run ipython notebook server on a headless linux machine
2. Run the attached notebook Geovista-Render.zip.

The screenshots below are what is shown in the three.js panel in the browser window in the notebook.

Screenshots

geovista-render.mp4

[James Penn]

I'm not sure if the rendering inconsistency is my fault? I am now running in a x window terminal which stops the warning from being shown in the notebook. However the strange rendering is still occurring.

I am running the example from examples/example_from_2d__orca.py pretty much as-is. The only addition is:

import pyvista
pyvista.global_theme.jupyter_backend = 'pythreejs'

to support output in the web browser.

[James Penn]

OK, based on sprint demo 24 I found with this change it renders correctly. not sure why or what the numbers in the Sphere mean though!

#plotter.add_base_layer(color="grey")
base_layer = pyvista.Sphere(radius=0.99, theta_resolution=360, phi_resolution=180)
plotter.add_mesh(base_layer)

[James Penn]

So I think the incorrect rendering is not related to the xserver warning, there are two different things going on here.

But the xserver warning is still a thing. If I don't set

import pyvista
pyvista.global_theme.jupyter_backend = 'pythreejs'

then the ipython kernel segfaults when trying to plot.

[Bill Little]

The rendering artifact may be due to the base layer being too close to the polydata surface for the specific notebook render that you've chosen. I've seen that before and is easily fixable... indeed,

#plotter.add_base_layer(color="grey")
base_layer = pyvista.Sphere(radius=0.99, theta_resolution=360, phi_resolution=180)
plotter.add_mesh(base_layer)

is the temporary fix hack that I recommended to @pp-mo

[Bill Little]

@jamesp I've pushed a tweak (5ecd6af) that should resolve the rendering issue that you're seeing with pythreejs.

When rendering in the browser you should always configure the rendering backend with either the jupyter_backend kwarg to the plotter show method, or a one-time configuration with the pyvista.set_jupyter_backend("pythreejs") function. See the pyvista docs for further details.

Does this resolve your rendering issue?

[Bill Little]

If it's a common issue that users might hit when plotting in a browser and they're using a geovista geoplotter, then we could easily ensure that the pyvista backend is set to a sensible default, if it hasn't already been done by overriding the show method

[Bill Little]

Also, note that the pyvista.global_theme.jupyter_backend defaults to ipyvtklink.

If you're running on a headless server, then you need to ensure that ipyvtklink is pre-installed e.g., conda install -c conda-forge ipyvtklink for it to work... this might be the original source of your issues, see the pyvista docs,

You've only circumvented this by explicitly using pythreejs, which I'm guessing is installed implicitly as part of the geovista requirements?, whereas ipyvtklink (which is more stable and feature complete over pythreejs btw) isn't

[Bill Little]

Note that, there is also the geovista convenience function goevista.common.set_jupyter_backend which will set the rendering backend by default to pythreejs (or whatever backend you provide) given that it can detect an active IPython kernel.