VTK Remote Server with C++

Hello.

I’m currently developing a web platform utilizing a simple variation of “remote” VTK rendering for volume visualiziation/interaction (C#) with rather complex VTK algorithms (C++) to achieve the goals of my project. I incorporated a large number of different VTk concepts, filters, pipelines within C++ and execute those function through PInvoke from my C# webserver.

The current remote rendering prinicple relies on rendering offscreen images on the server (into JPEG format) and sending those base64 encoded images over websocket to the client eventually displaying them within a HTML element.

I want to port this principle to a more stable solution with a VTK web server and VTK js on the client for VTK interaction.

I’m kinda struggling to fetch all the information needed to deploy such a solution. i’m still wondering if it’s somehow possible to setup a VTK server with my current C++ implementation as the core module (slight changes in implementation will have to be made, but i dont want to rewrite all my C++ code).

I’ve read something about VTK as a server within python. But that means that I cannot use my C++ VTK code and that I would have to rewrite it with the VTK python bindings?

Can you give me any kind of information which would help me figuring out which kind of infrastructure/concept/solution i should focus on to achieve a remote VTK renderer with client side interaction, ideally keeping most of my C++ code as it is?

Not sure how intensive your rendering is, but I am using VTK C++ compiled to WASM which is running the rendering and interacting on the client side browser, which is working very well. I had a Windows executable version of my application utilizing the VTK C++ libraries and I was able to reuse 95% of that code to compile to WASM and run on the clients web browser. Check out this link:

https://gitlab.kitware.com/vtk/vtk/-/tree/master/Examples/Emscripten/Cxx

Thanks @Donny_Zimmerman for your answer.
So if I understand that correctly, your code is running solely on client side, with no remote rendering server?
My application is rendering rather big datasets (ranging from high-resolution cranial scans to full lower body CT scans). As I want to interact with the rendering from everyday devices (low-end desktops, Tablets, Smartphones) I’m not sure if I can run and execute all my rendering code from the client.

The way to go (I think) is to use some kind of VTK server (remote rendering) with VTK.js at client side visualizing and interacting with the render window. But I only found vtkWeb which uses python as a server. Is there a way to combine vtkPython with my C++ VTK implementation? I’ve looked through the python bindings and not all of the capabilities of VTK (that I am using right now) are wrapped with python so far - I kinda don’t want to miss the complexity/flexibility of C++ VTK :slight_smile:

Yes, my application runs fully on the client browser, including rendering and interaction. Unfortunately I won’t be able to help you with server side rendering questions. Your dataset may in fact be too intensive to render on the client side, but WASM is a somewhat compiled language so it runs quite a bit faster than javascript in a browser. My application renders and interacts just fine on a smartphone. It was fairly easy for me to set up the WASM compilation environment and get my code rendering by following the instructions in the previous link I provided. You may find that it renders your dataset at an acceptable rate. The examples in the following link are rendering on the client side using vtk.js, which is a javascript implementation of the VTK library. I chose to use the C++ implementation compiled to WASM instead of vtk.js because not all VTK functions are implemented in vtk.js yet and also the speed and code reuse.

The Python server should work well because all VTK classes are Python-wrapped and you can wrap your C++ classes as well. If your classes are VTK-based then you can use VTK’s Python wrapper.

If you are not comfortable using Python then you can try Paraview render server. Or put together a simple rendering server and communicate with it using json-rpc or zmq (or if frame rate is not critical, then even web requests).