Include tolerances on geometry helper functions

In my code, I use the viktor.Geometry.point_is_on_bounded_line()
I have a point, and loop through some lines to see if the point is on the line, simple.
Noiw, the function kept returning False eventhough I knew the point was on the line.

Snippet of my code:

    # Loop through lines in wireframe and check if point is on line
    for staaf in wireframe.Staven:
        p1: Point = wireframe.Knopen[staaf.Knoop1]
        p2: Point = wireframe.Knopen[staaf.Knoop2]
        line = Line(p1, p2)
        print(f"if point: {checkpoint}")
        print(f"is on line from start: {line.start_point}")
        print(f"is on line to end: {line.end_point}")
        print(f"result is: {point_is_on_bounded_line(checkpoint, line, False)}")
        
        if point_is_on_bounded_line(checkpoint, line, False):
            print(f"FOUND THE LINE!")

The loop that should return true prints this info:
if point: Point(1.153e+01, 1.868e+01, 0.000e+00)
is on line from start: Point(1.153e+01, 1.935e+01, 0.000e+00)
is on line to end: Point(1.153e+01, 1.852e+01, 0.000e+00)
result is: False

Note that it is a vertical line with x = 1.153e+01
The Y of the line sits between 1.852e+01 and 1.935e+01 so the value of the point 1.868e+01 falls nicely between the ends.

I also used the function for these values, testing them hardcoded, and that does return true:

print(f"literal input: {point_is_on_bounded_line(Point(11.53, 18.85), Line(Point(11.53, 19.35), Point(11.53, 18.52)))}")

So, either it is linked to this 3d Space error (Viktor.geometry.point_on_bounded_line not correct in 3D space, but this bug is old and reported to be fixed). And the z-dimensions are 0. Or it is due to the mathematical notation. But I’m not sure if that is just how the Point prints its float, or that that it actually supports a different notation.

Using SDK 14.2, Connector v5.21.0 and CLI v0.30.6

I did manage to find the fix, it was a very stupid thing i overlooked, decimals.
The extrapoint X-value was 11.529 where the line was on 11.5289119 etc.

Lets rephrase my question, is there a way allow a small tolleration?

Hi Johan,

I looked into it quite a bit at the time, so here is my take on it:

The old bug was only because 3D space wasn’t supported, but I suspect this could well be a problem with numerical precision. I assume that with “mathmatical notation” you actually mean “scientific notation”?

A quick check would be (in this case) to check (in code) print(p1.x==p2.x) if that is not the case than you have the culprit.

In this particular function I would actually expect a “precision” parameter, because comparing floats (especially in 3d space) will results in problems like this, when switching to a different environment (say from Windows to Linux) the behavior may change again. So always write unittest to catch these issues!

At the time I implemented my own function for this check, which takes numerical precision into account (and is a parameter of the function).

Hope this helps,
Wichard

1 Like

Yes, this precision parameter would be a very sensible addition to this function.
Can anyone from Viktor shine their light on the matter?

Hi Johan, I think being able to tweak the tolerances makes perfect sense. This probably holds for a lot of other helper functions in the geometry module.

I see @khameeteman also already added it in our internal issue tracker. I’ll also switch this topic to a Feature Request so that people can submit their votes on it :wink:

*also changed the title to reflect the feature a bit better