On the master build, 5.5.2-626-g13f66fff1 (created using a superbuild-git master and the paraview-git master) both OSPRay and EyeDomeLighting will work properly with a single task. With any more than one task, much of the OSPRay data are missing and there is no shading in the EyeDomeLightingView. A comparison of the single- and multiple-task images are inserted below. (The data and state file used to make these images have been uploaded to Andy Bauer.)
@Dave_DeMarle is OSPRay supported on multiple server ranks yet? I didn’t think it was.
According to this Kitware Source article, EyeDomeLighting should work fine with parallel rendering. However, it looks like the lighting shaders are not being applied. @Joachim_Pouderoux and @mwestphal are you the Kitware experts on this (it was a project for/from EDF)?
Only partially.
- With the default “looks a lot like GL/Rasterization” it works fine.
- When you turn on extra effects (ambient occlusion, shadows, materials with reflective and refractive materials) there are rendering artifacts because secondary rays always miss non-local data. ( I have to look closely but this doesn’t look like what is happening in the Bucky’s bug report images.)
- There is an OSPRay specific mode where you spawn one ParaView and N OSPay-server processes to speed up the rendering process. There are no artifacts in this case, but you are limited to problem sizes where the geometry is small enough that OSPRay can copy it to all nodes.
Keeping fingers crosses, we might get funding to address case 2 next year.
Could you give a scenario to reproduce the issue with the EyeDomeLighting view?
I tested it successfully with a 4 nodes parallel server and remote rendering of a Sphere and a Wavelet.
However, it looks like the EyeDomeLighting pass is not applied when rendering is done locally when connected to a server.
@ka5855 Andy is not working at Kitware anymore. Could you please share your dataset again with me so I can give a try?