reading ascii stl files with QVTK

Support
#1

Hello,
I am trying to make a script work on ubuntu 18.04, with python 3.6, vtk 9.0.0 and Pyside2.

vtkSTLReader can read both binary and ascii files when used with a vtkRenderWindowInteractor . But, when I use a QVTKRenderWindowInteractor , it can only read binary stl files, it makes an error when reading a ascii file.

Unfortunatly I am not allowed to upload files here. But the script and the stl files are avalaible here : https://gitlab.kitware.com/vtk/vtk/-/issues/17939

If you have any idea why, I’d appriciate your help :wink:

#2

vtkSTLReader works the same way, regardless how its output is used (if it is rendered at all or if it is used with a particular render window interactor class).

If you do see a difference only because you use Qt or not then it might be because some global application settings are changed. For example, if you use non-ASCII characters in the STL filename or content then you may get different results depending on the application’s code page.

#3

Thank you Andras, you pointed me in the right direction.
It was not non-ascii characters, it was the decimal character. I am french and we use the coma as a decimal marker rather than a dot. (An american would write 0.1 and a french 0,1)

When I was using QTVK the stlReader somehow was expecting the french format for decimals instead of the usual one (I tested replacing all dots by comas in the file and it can now be read). So I ll try to find a way for QTVK to not inherit regional settings.

It could be good maybe to change the stlReader in future versions to not be affected by this.

#4

Thanks for the update, I’ve filed a bug report: https://gitlab.kitware.com/vtk/vtk/-/issues/17951

#5

Not a vtk issue imo.

#6

VTK’s STL reader/writer does not work correctly when used in an application configured with a non-US locale. This has come up a many times before, just google for vtk decimal comma. This can be quite easily fixed in VTK and really hard to work around at application level.

#7

VTK is respecting the locale asked by the application. See the link in the issue.

#8

OK, let’s continue the discussion in the bugtracker.