Does the rendering happen at user end? Scability issue?

[liangwang0734]

Dear ParaviewWeb community,

I'm looking for a way to host 2d and 3d cfd simulation datasets and allow users to visualize them within the web browser. Scalability is an issue so I wonder if the 2d/3d rendering occur at user end? Will it be suitable for multiple users to access our database simultaneously? Is it possible to do slicing and clipping, striding etc (my quick check of the examples did not show clear instructions).

I also came across other projects like plotly and bokeh. It seems to Paraveeweb is the only one that has good 3d large data visualization capability thus very useful for cfd. This is great work.

Best, Liang

[jourdain]

ParaViewWeb usually rely on a ParaView process running on the server side to do data processing (slicing, clipping, contours...) and sometime rendering so only images are sent to the client in an interactive manner. The ParaView process can also just focus on data processing and send the geometry to the client so the client can render it in his browser with vtk.js.

They are several options available that may be relevant to what you are trying to do, but each of those option have some limitation in a way or another. Here are a couple of option with their pros and cons.

At the end, the type of data and what you want to share will dictate which direction you may want to take.

ParaViewWeb (Data processing + rendering)

Pros:

• Can do everything that ParaView can do (Processing and rendering)
• The client does not need to download the data.

Cons:

• The infrastructure is more complex and costly (need GPU)
• Harder to scale to a large set of concurrent users

ParaViewWeb (Data processing + send geometry)

Pros:

• Can do everything that ParaView can do (Processing)
• The client does not need to download the full data.

Cons:

• The infrastructure is more complex and somewhat costly (no need of GPU)
• Harder to scale to a large set of concurrent users
• The client needs to download the geometry which can be big sometime

vtk.js

Pros:

• No server side infrastructure
• Scalable in the sense that the rendering is happening on the client side

Cons:

• Almost no filtering currently exist on the client side. Although VTK/C++ can be compiled into WebAssembly and be used in the web to perform those type of operation, their performance are not that great.
• The client need to download the data which can be big.

ArcticViewer / Cinema

Pros:

• No server side infrastructure
• Scalable in the sense that the rendering is happening on the client side
• The amount of data to transfer to the client is smaller than the 3D one.

Cons:

• The interaction and set of processing available is limited to what has been precomputed.
• The total amount of data could be bigger than the original one

[liangwang0734]

Dear jourdain,

Thank you for your great summary.

It seems that ArcticViewer/Cinema is a good fit, since my we only need basic, perhaps pre-processed views (surface/iso-volume/streamline/slice/line). In deed, I considered direct webgl output from ParaView, but found it impossible to interactively enable/disable/combine different filters in the browser.

PS: On the data size issue, I remember Bokeh has a feature to allow downloading according to sampling resolution. But that is perhaps still not an ideal solution for large 3d data serving?

[jourdain]

You can look at some scripts here to export geometry: https://github.com/Kitware/arctic-viewer/blob/master/scripts/examples/paraview/samples/VTKGeometry-can.py

Otherwise you can export 2D pictures with different camera angle which still allow you to move around the object in some way: https://github.com/Kitware/arctic-viewer/blob/master/scripts/examples/paraview/samples/camera-spherical.py

In general that project lack some good guidance or documentation and require some good understanding of ParaView scripting. But if that make sense to you, we can help via a support contract or else.

[tp-cz]

Hi, the summary is perfect. Is there any simple example showing how to setup the "data modelling + rendering" model and the "data modelling + send geometry" alternative, e.g. a simple example of rendering a cube by both of the models?

[jourdain]

This will be a naive example but in some way, that show the concept but in order to properly skip any render call on the server side more work will be needed.

Server side:

• Remote rendering
• Local Rendering

Client side

• Switch between local/remote rendering
• Renderer code

[jourdain]

Here is the main example

[tp-cz]

Thank you very much. I will test it. Nevertheless, if I understand it correctly, VtkRenderer is used for remote (server-side) rendering (i.e., server renders complete image and sends it to browser) whereas VtkGeometryRenderer is dedicated to the local (browser) rendering (i.e., only geometry is computed by server and sent to browser which renders complete object). In order to allow both approaches, I have to call functions self.registerVtkWebProtocol(pv_protocols.ParaViewWebPublishImageDelivery(decode=False)) and self.registerVtkWebProtocol(pv_protocols.ParaViewWebLocalRendering()). Does it mean, that if I call both functions, clients can dynamically decide if they want to use local rendering by using VtkGeometryRenderer, or remote rendering by using VtkRenderer? Thank you.

[jourdain]

Yes the client can switch between them. You can try that with ParaView Visualizer since it is easy to run and toggle between those modes.

[tp-cz]

Great. Thank you.

[misterjoa]

Hello everyone !

Thank you for this interesting discussion. We currently implementing 3D vizualisation in the browser and evaluating paraview and sibling technologies in order to do this.

I have a few questions for you @jourdain

There are a lot of toolkits currently out there by kitware to do this and I could not find a comparison table for all of those toolkits vs. criterions like

• is the technology going to be maintained in the long run
• current state of each tech (alpha/beta/prod)

As an example I understand that artic-viewer is not maintained

Also I'd like to know, how could your decision matrix be updated vs. current landscape of technologies ? (https://github.com/Kitware/paraviewweb/issues/452#issuecomment-387762392)

I don't know if this is the ideal place for such a discussion, if I'm mistaken please direct me to the correct place !

Thank you very much !

[jourdain]

Hi @misterjoa,

The summary provided at the top is still valid at the high level. The technology stack underneath has strengthen to be simpler. Unfortunately we don't have a good story/awareness around it.

Basically the backbone of all of that rely on the following stack that will be maintained and evolved:

vtk.js > wslink > trame

Where VTK / ParaView Web is nothing more than vtk.js + wslink + server(VTK/PV).

Trame is the new kid on that stack and offer everything that VTK / PV Web has to offer via a simpler, ubiquitous and scalable solution. Basically it allow you to just write the server side of a PVW application and get a full one (server+client) without writing JS/HTML/CSS.

Then if you want to work on the web side of things we have some adapter to vtk.js for React and Vue. The Vue one is more advanced as it support all the server need with local and remote rendering. But the React one could also expand and support that side too with some reasonable effort.

I think further discussion should transition to trame discussion as trame really aim to be at the top of that stack.

HTH

Seb