I wrote a script for postprocessing pressure data on surfaces.
I noticed that when a geometry is plotted with opacity < 1 the SaveScreenshot command takes very long (60 seconds vs 1 second if I set opacity to 1).
my script loads a vtm that points to some vtp extracted in OpenFOAM. Then what follows is some filters to compute cell size, surface normals and merge of the dataset.
With translucent renders, we try to capture the translucency in the image (for PNG at least) by taking two renders, one with a white background and another with a black. There’s then some computation to determine what the translucency is for each V (from HSV) based on the difference between the two. If your scene takes a long time to render, that could be a contributing factor. Or that algorithm could need improvement (it was one of my first user-facing contributions to ParaView).
Hi, @ben.boeckel
what would you suggest to improve in the script? I do not understand how the savescreenshot command (not the Show command) could take this long. I do not see this large runtime if I save the view in the interactive GUI.
P.S. i checked the runtime of SaveScreenshot doing some profiling of the script
I think people are confusing different things here.
@ben.boeckel , what you’re referring to is saving PNG images with transparent background. That’s is different than simply saving images which include translucent geometry. If I am not mistaken, the latter is the case here.
@dax_00, are you using simply pvpython or is this using pvbatch and MPI to execute in parallel / distributed mode?
There might not much that can be done to speed up esp. since the rendering translucent geometry requires multiple passes and OSMesa may indeed be the bottleneck here. If you’re OSMesa build support swr using that as the GALLIUM_DRIVER may be worth a shot. SWR renderer often is much faster than the default software renderer.
Secondly, splitting among multiple ranks instead of 1 may be worth a shot too. For that, I’d recommend using the latest version as the data redistribution code was revamped in 5.9 and will definitely be better than earlier versions. However, there are multiple things that come into play here e.g. cost of compositiing images, data redistribution etc. So it’s not a clear cut solution.