search

Kitware / paraviewweb

Web framework for building interactive visualization relying on VTK or ParaView to produce visualization data
http://kitware.github.io/paraviewweb/
BSD 3-Clause "New" or "Revised" License
160 stars 50 forks source link

Local Rendering #471

Closed sanderegg closed 5 years ago

sanderegg commented 5 years ago

Dear developers,

I recently started playing with paraviewweb and the visualizer application using the provided docker images in kitware dockerhub. I tried the pvw-visualizer-osmesa-5.5.0 flavor on a windows 10 machine and also the pvw-visualizer-5.5.0 one on a ubuntu-based machine with NVidia GPU (with nvidia-docker engine installed). In both cases I could make them work by adding "ws://localhost:$SERVER_PORT" (SERVER_PORT being the 8081 port) to the docker run command (and --mesa-llvm for the windows case) and could nicely access the visualizer and load stuff.

My question comes to the "Remote Rendering" checkbox. As soon as I uncheck it I get an exception in the Chrome debugger and the whole scene disappears. Checking it again renders a blank screen. Only way is to refresh the page where I get again the initial state.

Is this supposed to work in any case, or does this work only with some kind of data? I initially thought it might be linked to my OSMesa version under Windows, which is why I tried on Linux, but I get the exact same issue... any hint there?

Thanks, Sylvain

jourdain commented 5 years ago

Hi Sylvain,

This feature is supported for any geometry rendering (no volume rendering as of now) but like you discovered, the docker images which use the actual ParaView release have an issue. This is due to the fact that we/I screw up 5.5 in the sense that code that were in ParaView/master did not make it into the release branch in time while the client moved forward. So Visualizer mostly work except for the local rendering switch...

All is good in Paraview/master but since we don't have a docker image for master and 5.6 is coming soon, we were just waiting for the next release phase. Normally we've updated the docker image so you could build your own and point to master instead of a specific release. For some time we had a tbb build issue for ParaView on master but I'm guessing it should be fix now.

Sorry for the inconvenience...

sanderegg commented 5 years ago

Hi Sebastien,

I'll try what you propose. Thanks very much for the quick answer.

sanderegg commented 5 years ago

Hi again, having some issues trying as I still get the same problem. It looks like the changes I did (see below) are the correct ones. I guess I'm missing some switch?

Here is what I did:

Thank you for your help!

jourdain commented 5 years ago

I think line 82 should be -Dparaview_SOURCE_SELECTION:STRING=master \

sanderegg commented 5 years ago

Dear Sebastien,

I tried both master and "master" but both fail at compile time. Looking at the cmakelist shows that only version number, "git" and "source" are available options... some other idea?

jourdain commented 5 years ago

@scottwittenburg any idea?

scottwittenburg commented 5 years ago

I've pushed new EGL-based images to dockerhub built from ParaView master today, they are tagged as follows:

kitware/paraviewweb:pv-master
kitware/paraviewweb:pvw-base-master
kitware/paraviewweb:pvw-visualizer-master

They can be downloaded here.

I've also created a PR (#475) to update the dockerfiles such that you should be able to specify which version of the superbuild and paraview to clone. I'm building the pv-osmesa-master image now, and assuming it finishes successfully, I'll push those images to dockerhub tomorrow.

sanderegg commented 5 years ago

Ok so I copy pasted the changes you did in the PR (#475 ) but still get the same issue. Built the docker image successfully, then built the paraviewweb docker image using the BASE_IMAGE argument, and the same with the visualizer docker image.

I am running all this under Windows 10, using the latest stable docker engine. I don't have a linux workstation right now to check if this could be related. Should the OSMesa version also be able to allow client-side rendering?

jourdain commented 5 years ago

Yes the os-mesa should be able to do local rendering. Did you make sure to load the latest client by clearing any cache and forcing the reload?

jourdain commented 5 years ago

Although looking at the error it seems the error is on the Python/Server side...

sanderegg commented 5 years ago

yes with the debugger open, I also have the disable cache checked.

jourdain commented 5 years ago

Did you run the correct one with all the arguments?

docker run -v D:\3Dtestdata:/data -p 0.0.0.0:8081:80 -ti pvw-visualizer-mesa-master "ws://localhost:8081" --mesa-llvm

or just

docker run -p 8081:80 -ti pvw-visualizer-master "ws://localhost:8081"

sanderegg commented 5 years ago

yep definitely...

sanderegg commented 5 years ago

Also @scottwittenburg , can you tell me when you have your mesa version on the kitware dockerhub?

scottwittenburg commented 5 years ago

Ok @sanderegg, you should be able to grab those osmesa docker images from our dockerhub now:

pv-osmesa-master
pvw-base-osmesa-master
pvw-visualizer-osmesa-master

We are aware of an issue switching to local rendering with an empty scene, if you are using that osmesa image. That will be fixed on the client side at some point, hopefully soon, and when the new client is included in the ParaView superbuild, we will build and push new images.

sanderegg commented 5 years ago

Hey @scottwittenburg, it looks like your version is functional, contrary to mine. So it looks like my execution of the dockerfile is faulty. Did you change anything else than the #475 to generate these images?

very cool, thank you guys this rocks!

jourdain commented 5 years ago

We cheated and did a small patch. But if you were building it this morning it should work.

Also I'm going to update Visualizer in the ParaView bundle to better handle a couple of OSMesa specific behavior we noticed when looking at your issue.

Thanks!

jourdain commented 5 years ago

@scottwittenburg is going to build and push a new master version for both EGL/OSMesa which brings the latest Visualizer 3.1.6. With that version, several fix happened for the local rendering part. Moreover you can choose to use local rendering automatically without requiring the user to toggle it in the settings. To do so you can do it in the URL by adding ?renderer=local or in the main html file in the connect line.

[...]
Visualizer.connectWithArgsAsConfig({ application: 'visualizer', renderer: 'local' });
[...]
sanderegg commented 5 years ago

Thanks for the fix! I directly used your images for the time being. Really cool!

What were the fixes for the local rendering? Are these also rendering fixes?

I found some issues with the slicer, which seems to draw some things incorrectly. Should I file another issue for this or is it known?

jourdain commented 5 years ago

Please add another issue.

For the changes here is the list:

sanderegg commented 5 years ago

Ok I'll do that. Thx a lot. I think I can close this issue.