Incorrect visualization of `vtkLongArray` cell scalars when using vtk.js local rendering

[user27182]

Describe the bug

Using trame-vtk with vtkLongArray cell scalars results in incorrect visualization of the data. Using vtkTypeInt64Array instead produces the correct result.

In VTK 9.6.2, the conversion between NumPy and VTK array dtypes was incorrect, resulting in long being converted to int64. This was fixed in VTK 9.7.0 with https://gitlab.kitware.com/vtk/vtk/-/merge_requests/13430.

Consequently, downstream users like PyVista which use vtk_to_numpy and numpy_to_vtk are now seeing this bug surface in VTK 9.7, since the numpy conversion would previously "mask" the bug by changing the dtype from long (broken) to int64 (working), whereas now the NumPy conversion is correct and we go from long (broken) back to long (still broken). See pyvista/pyvista#8810 (comment)

I created a matrix using the reproducer below to show how the different arrays and how the use of a NumPy round-trip conversion affects the output. The table shows the apparent regression with vtkLongArray previously working in 9.6.2 with a NumPy round-trip, which breaks with vtk 9.7.

This issue with vtkLongArray is only visible when using trame-vtk. The correct output is observed in all cases when using vtk outside of a trame app.

Args	vtk-9.6.2	vtk-9.7.0rc2
vtkLongArray
vtkLongArray --numpy-roundtrip
vtkTypeInt64Array
vtkTypeInt64Array --numpy-roundtrip

To Reproduce

Download the script dtype_bug.py. Create a new env and install deps:

pip install trame trame-vuetify trame-vtk vtk

Run the script with the args listed in the table above to generate the outputs, along with a port, e.g.

python ./dtype_bug.py vtkLongArray --port 1234
python ./dtype_bug.py vtkLongArray --numpy-roundtrip --port 1234
python ./dtype_bug.py vtkTypeInt64Array --port 1234
python ./dtype_bug.py vtkTypeInt64Array --numpy-roundtrip --port 1234

Platform:

Device:

• Desktop
• Mobile

OS:

• Windows
• MacOS
• Linux
• Android
• iOS

Browsers Affected:

• Chrome
• Firefox
• Microsoft Edge
• Safari
• Opera
• Brave
• IE 11

[jourdain]

Thanks for the report! I'm hoping to maybe look at it sometime next week.

[jourdain]

Looking at the sample code, this use case is with local rendering using vtk.js.
Ideally, I would like to start enabling vtk-wasm for local rendering which should solve most if not all issue related to vtk.js limitation.

But in this case it is more of a Web limitation in the TypedArray... I'm not sure what would be the path forward on that specific issue.

[user27182]

I see, that makes sense. If needed, downstream users could probably monkey-patch the new mappings from numpy array types to VTK array types inside of numpy_support.py to restore the old (wrong) behavior... will wait to see if there's a proper fix here first.

[jourdain]

I've integrated your validation example here and also added a --wasm option to test also the wasm rendering output.

Since there is no perfect solution (due to JS lacking Int64), I performed a data conversion to Int32 server side within the trame-vtk==2.11.14 release.

I let you test and see what you think and if it is ok to close this issue or not?

BTW, the rendering of the colors/light is weird between the various array types...

[user27182]

Thanks, I pushed version updates to pyvista/pyvista#8819 to test trame-vtk==2.11.14. The cell scalars issue seems to be fixed, but there are many new errors with some images producing blank result, e.g.

See the image regression report here, there are now ~300 errors reported with vtksz files specifically:
https://6a63a555a69438104215e4c0--pyvista-doctest-images.netlify.app

Compared to ~30 with trame-vtk==2.11.13:
https://6a5ee09cddccd2039dccb7f3--pyvista-doctest-images.netlify.app

[jourdain]

Ok looking into it.

[jourdain]

Any easy way for me to test those locally? I have an idea of the cause of the problem, but I want to validate it before triggering yet another release.

[user27182]

not really easy because it requires the full docs build and patching the tox config to install the deps you want... but typically use tox run -e docs-build for building docs, then tox run -e docs-test for testing afterwards. You can usually use --override testenv.deps+= to add additional deps but I just tried and it doesn't work for installing from a git commit.

So it seems you need to add the install in tox config commands_pre, e.g.

commands_pre =
    uv pip install "git+https://github.com/Kitware/trame-vtk.git@094ee32ff306005f744b5d5d0f3f114a30a7038e"

If you give me specific commits to install from whatever packages you want to test I can push them to pyvista/pyvista#8819 directly and let our CI test it out

[user27182]

Takes about 30 minutes to run too... not ideal for iterative debugging. The alternative is to try to create a minimal reproducer, but I tried doing something like this (based on the observation that this example was one of the blank images):

from pyvista import examples
import pyvista as pv
mesh = examples.download_bunny()
out = mesh.partition(4, as_composite=True)
pl = pv.Plotter()
pl.add_mesh(out)
pl.export_html('test.html')

But it didn't work, the output html wasn't blank, so does not reproduce....

[jourdain]

Ok thanks, I'll create a branch to test/validate then. Thanks again for your guidance.

I tried to clone pyvista and setup a venv to run it, but I always get a ModuleNotFoundError: No module named 'tox_uv'.

[jourdain]

That would be the one to test Kitware/trame-vtk#123

[user27182]

Thanks I pushed 000de9c, tracking build status here
https://github.com/pyvista/pyvista/actions/runs/30126676041

EDIT: And it's tracking the branch directly, so if you make any more pushes we can just retry the job to pull in the updates