[TTK 1.2 + Paraview 5.11.1] Infinite density in CSP computed for the tooth dataset

[thegame61916]

Describe the bug
The density range is [0, infinity] in the CSP computed for the tooth dataset with TTK 1.2. It works perfectly fine with TTK 0.9.8. Here is the dataset file.

To Reproduce
The mentioned data file has two fields. Load it in Paraview with TTK 1.2. Apply the continuous scatterplot filter. Select the two fields and generate the CSP. Observe the density range in the information tab.

Expected behavior
The density range should be finite.

System (please complete the following information):

• OS: ubuntu 22.04

[julien-tierny]

I confirm I can reproduce the issue on this dataset.
That piece of code hasn't changed much in a long time.
The latest edit was made in PR #920. It may have introduced this issue.
@atalon-lip6 could you have a quick look into this please?

[Lgt2x]

I may have introduced a bug through #920 , I'll test whenever I have the chance. Thanks for reporting this

[julien-tierny]

Thanks a lot for this feedback @Lgt2x
You may want to check out this thread on the ttk mailing list (which includes hints at code changes): https://groups.google.com/g/ttk-users/c/Hn2_I5QBK2E

[Dosmi]

Hi,
Looking at the sourcecode (https://topology-tool-kit.github.io/doc/html/ContinuousScatterPlot_8h_source.html) the infinity comes from:
if(isLimit) density = std::numeric_limits<decltype(density)>::max();,
where isLimit is set to true when the triangle area is 0.0.

I suspect the bug might be centered around the four function calls of Geometry::computeTriangleArea(...);

I did a quick check, as I see that the computation of triangle indices have been updated in the newer code (https://github.com/topology-tool-kit/ttk/pull/920/files - lines 270-288).

FYI @Lgt2x - TTK 1.1.0 used the Geometry::isPointInTriangle tests, whereas TTK 1.2.0 switched to zCrossProductsSigns.
If I cut the 'classification' code from TTK 1.1.0 (that used the Geometry::isPointInTriangle) to TTK 1.2.0 (replacing the newer zCrossProductsSigns), it works fine. The bug seems to be isolated from how the zCrossProductsSigns are computed.

[Lgt2x]

I took a quick look, you're right, zCrossProductsSigns computations have problems (it could be the 0 case). I don't have much time to dig further into it, but I can submit a PR to partially revert #920 if that's ok

[julien-tierny]

a partial revert of #920 would be very helpful already.
thanks a lot @Lgt2x