Using NaN values came up in another topic, which shows that there are people in the VTK community who assume it is OK to use NaN values, while I would assume that having NaN values may lead to problems and should be avoided.
It seems that at least some classes tolerate NaN values in some input data. But of course it is impossible to guarantee that all classes work correctly in presence of NaN values, because writing such code would require special developer skills and extra development time, and performance could suffer due to all the necessary extra checks.
What is the status of NaN value support in VTK? Can NaN values be used in inputs unless stated otherwise; or NaN values must not be used unless stated otherwise? Or is there a rule like NaN values are expected to be supported in file I/O and in mappers but not guaranteed to work anywhere else?
NaN are supported in VTK. Any filters that fails to process NaN correctly should be fixed to support it.
If you find any, please open an issue.
That being said, a NaN is still a NaN and working with NaN can have consequences. Eg, a chart with lots of NaNs will contains lots of missing plot lines.
Thank you, it is useful to know that NaNs are expected to be fully supported everywhere. It would be useful to add this to the VTK API reference, along with information of how VTK generally interprets NaN values when found in point coordinates, normals, point/cell arrays, image values, etc.
By searching in the code for presence of nan and isnan in implementation and tests, it seems that NaN is handled in IO classes, charting, lookup table related features, some basic statistics, and thresholding. This is a tiny portion of VTK, but probably covers the most common use cases. I would expect that most filters would behave quite randomly in presence of NaN values in input mesh point positions or in processed arrays, but so far we have stayed away from using NaN values, so I don’t have any problems to report.
I don’t see how even simple filters like vtkWarpScalar or vtkWarpVector would properly handle NaNs. I expect that the great majority of filters would not handle NaN properly, especially if you assume that vtkPointSet classes, which have explicit vtkPoint representations, might have a NaN point coordinate values. I’d appreciate someone explaining this to me - maybe I am missing something ???
Any filters that fails to process NaN correctly should be fixed to support it.
Again, unless I am missing something, you’re signing up for a lot of work and potentially a lot of mucked up code I suggest that a simpler fix might be to create a filter that checks for NaN (in the field data / point data / cell data / point coordinates), with the option to replace NaN with a specified value if encountered. Potentially modifying hundreds of filters gives me the willies
NaN as point or cell scalars I think is the most common case (and the most likely to work as expected). I suspect a fair bit of filters that use the generic copy FieldData stuff will work with them and then in rendering/coloring we definitely have a fair bit of code to properly handle them. Nowhere near 100% (just because there are lots of possibilities) but the NaN values as Point/Cell scalars on polydata is probably the best supported case.
NaN as points or cells coordinates do not make sense. Just remove the points or the cells in that case.
As @ken-martin stated, I’m talking about PointData and CellData that can have missing data. Missing data should use NaN and should be supported as best as they can be. If they are not, it should be considered an issue. There is already a few issues about that in VTK and ParaView bug trackers.
I suggest that a simpler fix might be to create a filter that checks for NaN (in the field data / point data / cell data / point coordinates), with the option to replace NaN with a specified value if encountered. Potentially modifying hundreds of filters gives me the willies 