Warnings when rendering on a server not running x server
jamesp opened this issue Β· comments
π 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:
- Run ipython notebook server on a headless linux machine
- 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
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.
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)
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.
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
@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?
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
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
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.