Hey, we recently upgraded our vtk version from 26.8.0 to 27.4.0 to start using the new vtkImageResliceMapper. However some of our clients are experiencing issues with shader compilation. We haven’t however been able to reproduce the issue ourselves. Here are the logs one persent sent us:
He’s using:
| Edition | Windows 11 Pro |
|---|---|
| Version | 22H2 |
| OS build | 22621.1702 |
I was wondering if you have an idea on how to fix this?
It seems like the browser crashed with a webgl context lost error. Can you provide the size and type of data being loaded? Is it too big to fit in GPU memory?
We load stls files that can max around ~50MB (in total max about 400MB) and dicoms files that can be up to 800MB (the dicom is only loaded in 2D views).
However the size of the files didn’t use to be a problem. It also seems to happen on latpops with 16GB of ram
@nomis6432 The new vtkImageResliceMapper uploads the whole dataset into GPU memory for reslicing. So, if you have multiple views showing slices, each view is uploading the whole volume to the GPU. That’s the downside to better performance. We are working on adding support for sharing graphics resources across different viewports which would ensure that if multiple viewports are looking at the same dataset, it will only be uploaded once to the GPU.
@sankhesh How does this happen in the vtkImageMapper? does this also store the whole dataset in GPU memory or not? Our problems started when we used the vtkImageResliceMapper, so is they way they work that different?
The image mapper does the slicing on the CPU and hence doesn’t upload the whole volume to the GPU.
@sankhesh Follow-up question on this issue: I have now removed the imageResliceMapper, but I still get the errors related to the vtkPolyDataVS.glsl shader. When this error occurs, our 3D view of the meshes is broken. Did any part of this code got updated recently so that it utilises the GPU?
@Tim_De_Bauw I don’t recall any recent changes that affect GPU memory usage with the polydata mapper. That might be unrelated.
