Error: could not instantiate classes like vtkXMLPolyDataReader with the vtk.wasm module

Web
1

Hi,

I was working on a development project with react and typescript bundled with vite using vtk js for visualisation. However I had issues with it and since moved to handle the same with vtk-wasm instead.

I have set up the renderer following the guide here at Bundler Integration | VTK.wasm and below is the code I have with me right now.

  useEffect(() => {
    import("@kitware/vtk-wasm/vtk")
      .then(({ createNamespace }) => {
        return createNamespace(VTK_WASM_TARBALL_URL);
      })
      .then((vtkInstance) => {
        setVtk(vtkInstance);
        setViewPortLoading(false);
      })
      .catch((error) => {
        console.error("Failed to load VTK WASM:", error);

        setViewPortLoading(false);
      });
  }, []);

I am using the published version to setup my namespace https://gitlab.kitware.com/api/v4/projects/13/packages/generic/vtk-wasm32-emscripten/9.5.20251215/vtk-9.5.20251215-wasm32-emscripten.tar.gz

However, Now I am having an issue as I could not instantiate vtkXMLPolyDataReader and I have noticed the following error in my console.

vtkSession.cxx:97 ERR| Constructor not found for class name: vtkXMLPolyDataReader

Below is my code on how I initialize the class,

const reader = vtk.vtkXMLPolyDataReader();
const mapper = vtk.vtkPolyDataMapper();

Are the Reader classes not built with the published version of vtk-wasm? Should I use my own build version of vtk-wasm?

2

While we are actively working on enabling more classes of VTK inside our VTK.wasm bundle. The current bundle only focus on the Rendering part of VTK. This currently solve the local rendering capabilities of trame while giving us time to setup infrastructure and testing around that new capability.

As you’ve noticed, we are exposing a plain JavaScript API for controlling those VTK objects. This aim to offer a fully feature VTK in the browser, but to be truly complete, we need to enable all/more vtk modules within WASM. But to make it practical (not a single humungous file), we are looking into a “shared” build of VTK where each module will be its own wasm file that will then be loaded/downloaded based on the need.

To make that possible we are fixing things in CMake and working with the Emscripten community to enable shared build. If everything goes as according to plan (not always the case) we are hoping to make that available in the next major version of VTK (+6 months).

On top of that, to have a vtk module to work with our wasm infrastructure, you need that module to be serializable with all its public classes in it properly tagged. As far as I know, we haven’t look at the IO modules yet to enable such serialization.

So to summarize as of today, in order to achieve what you want to do, you will need:

  1. enable serialization on the vtk module you need to use on the JS side
  2. build a custom wasm bundle with all the modules you’ve added

Hope that helps,

Seb

@jaswantp and @Quinn_Powell feel free to expand/correct me.

1 Like
3

@Sebastien_Jourdain aptly descibed why this does not work. We hope to enable it (reader, and more classes in the “shared” WASM bundle) by end of March.

1 Like
4

Hi @Sebastien_Jourdain ,

Thanks for the reply with the current limitations regarding vtk-wasm.

Sorry for using the same discourse chat for my other question but I am trying to understand the capabilities and rendering constraints with VTK in browser.

For my application, I have moved to use Trame App in my python backend server with a Javascript client.

I have used the following examples to set up my application. Note that my target is to render large geometries (Polydata files of ~700 MB to 1 GB sometimes).

RemoteView:

I have followed the example here Remote View (Simple server) and have setup my renderer. From my understanding in Remote View the render window is hosted completely in the server and it sends the image data through a websocket to the client based on the interactions the server gets from client.

This was working very well for me with rendering being done in dGPU and I see no frame drops and I didn’t need to reduce the interactive quality even for larger geometries.

However when rendered with iGPU, I see some major frame drops even with a lower interactive quality. Native VTK has no troubles to render geometries of sizes i have mentioned even with iGPU with no frame drops. I understand I am running into the limitation because of the pipeline where the server has to get the result and then send the image data back to client. I am supposed to achieve performance that can be comparable to Native VTK.

Local View:

I have tried rendering with vtk-wasm with local view setup using trame again so that I could do the rendering directly in the client and I have followed this example here Trame WASM in Pure JS.

This setup was much better in the rendering quality but it is only for smaller geometries. Once I have large geometry the setup fails and the renderer crashes. I was not able to send the geometry rendering data to front end because of its huge size.

My question is, Am I doing something wrong somewhere? Remote View works so nice for me with a dGPU but I have performance constraints to meet with iGPU. Is vtk in broswer realistic to render polydata of huge sizes, like native VTK?

Irrespective of that I am very keen to see the developments with vtk in browser with WASM and Web-GPU. I am willing to contribute to it as well even if it is a small task like documentation.

5

Aside from network overhead for sending geometry, wasm should be able to render huge geometry. But you will have to use WASM 64 bits. While we are building 32 and 64 bits wasm bundles. We haven’t streamlined the 64 bits delivery/selection.

What do you mean by dGPU and iGPU? Remote rendering should work as well as with standard VTK.

Otherwise any help on the documentation or examples where you see gaps will be greatly appreciated.

6

Thanks for the reply!

I meant the discrete graphics processing unit like consumer grade GPUs like NVIDIA RTX and integrated graphics processing unit which comes with the CPU. With integrated graphics, I see the performance troubles with Trame where the standard VTK doesn’t struggle. By performance trouble I meant the frame drops in rendering even with lower interactive quality.

I will try out using WASM in 64 bits, Thanks!

7

The iGPU should work fine in trame unless you do it offscreen. As the offscreen mode will rely on EGL and only Nvidia implement such integration.