[ Fixed by marioalexis ] Draft Workingplane: projectPoint issue

[Roy_043]

While testing Draft_Snap_Dimensions I notice some very strange results if WP is Auto and the Front view is activated.

I think the issue is related to the projectPoint method:

Code: Select all

import FreeCAD as App
import FreeCADGui as Gui
import WorkingPlane

Gui.activeDocument().activeView().viewFront()
plane = WorkingPlane.plane()
plane.setup()

print(plane.projectPoint(App.Vector(300,0,300)))
print(plane.projectPoint(App.Vector(299.9999999999995,1.788139449843132e-04,299.9999999999995)))
print(plane.projectPoint(App.Vector(299.9999999999995,1.788139449843132e-05,299.9999999999995)))
print(plane.projectPoint(App.Vector(299.9999999999995,1.788139449843132e-06,299.9999999999995)))

Code: Select all

Vector (299.99999999999955, 1.788139449843129e-05, 299.999999999999)
Vector (299.99999999999903, 1.7881394498431244e-05, 299.9999999999982)
Vector (299.99999999999903, 0.00016204581124782942, 2718.6774151542527)
Vector (299.99999999999903, 1.7881394498431274e-05, 299.9999999999987)

Notice the Z coordinate of the 3rd vector.

Code: Select all

OS: Windows 8.1 (6.3)
Word size of FreeCAD: 64-bit
Version: 0.20.25065 (Git)
Build type: Release
Branch: master
Hash: 4de2ad46b2b9c78ac2721a0dbea7c19306261095
Python version: 3.8.10
Qt version: 5.12.9
Coin version: 4.0.0
OCC version: 7.5.2
Locale: Dutch/Netherlands (nl_NL)

[thomas-neemann]

I can not create the problem, can you describe exactly what you do?


OS: Ubuntu 20.04.1 LTS (XFCE/xubuntu)
Word size of FreeCAD: 64-bit
Version: 0.20.25176 (Git) AppImage
Build type: Release
Branch: master
Hash: 909dfa7036f9fd36bbd3acee2a5dee161d2819fb
Python version: 3.9.5
Qt version: 5.12.9
Coin version: 4.0.0
OCC version: 7.5.2
Locale: German/Germany (de_DE)

[Roy_043]

1. Startup WB is Draft (but that is probably not relevant).
2. Default WP is None/Auto.
3. Grid is 300x300.
4. Start FC.
5. Call Std_New.
6. Call Std_ViewFront.
7. Switch on Draft_Snap_Dimensions.
8. Call Draft_Line.
9. For the 1st point snap to the grid at 300,0,300
10. Move the pointer around.
11. Result: the snap dimensions jump all over the place.

Note that the problem does not occur if you change the WP to Front with Draft_SelectPlane.

[thomas-neemann]

yes I can confirm that, for front and rear.

it works in realthunder.

1.jpg (38.8 KiB) Viewed 2825 times

OS: Ubuntu 20.04.1 LTS (XFCE/xubuntu)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 2021.528.24301 +3572 (Git) AppImage
Build type: Release
Branch: LinkStage3
Hash: 1578dc89cb181b96e75d9fb128d82b0ec1460291
Python version: 3.8.10
Qt version: 5.12.9
Coin version: 4.0.1
OCC version: 7.4.0
Locale: German/Germany (de_DE)

[Roy_043]

Thanks for confirming. My guess is that there is a relation with the Coin version.

[thomas-neemann]

at least the coin version of realthunder is newer

[Roy_043]

Looking at the projectPoint function in WorkingPlane.py the cause of the problem is obvious. The function completely ignores the inaccuracies related to floating point calculations.

Docstring:

Code: Select all

        """Project a point onto the plane, by default orthogonally.

        Parameters
        ----------
        p : Base::Vector3
            The point to project.
        direction : Base::Vector3, optional
            The unit vector that indicates the direction of projection.

            It defaults to `None`, which then uses the `plane.axis` (normal)
            value, meaning that the point is projected perpendicularly
            to the plane.

        Returns
        -------
        Base::Vector3
            The projected vector, scaled to the appropriate distance.
        """

Original function:

Code: Select all

    def projectPoint(self, p, direction=None):
        if not direction:
            direction = self.axis
        lp = self.getLocalCoords(p)
        gp = self.getGlobalCoords(Vector(lp.x, lp.y, 0))
        a = direction.getAngle(gp.sub(p))
        if a > math.pi/2:
            direction = direction.negative()
            a = math.pi - a
        ld = self.getLocalRot(direction)
        gd = self.getGlobalRot(Vector(ld.x, ld.y, 0))
        hyp = abs(math.tan(a) * lp.z)
        return gp.add(DraftVecUtils.scaleTo(gd, hyp))

Improved function:

Code: Select all

    def projectPoint(self, p, direction=None):
        lp = self.getLocalCoords(p)
        gp = self.getGlobalCoords(Vector(lp.x, lp.y, 0))
        if p.isEqual(gp, 1e-8):
            return p
        if not direction:
            return gp
        if direction.isEqual(self.axis, 1e-8):
            return gp
        a = direction.getAngle(gp.sub(p))
        if a > math.pi/2:
            direction = direction.negative()
            a = math.pi - a
        ld = self.getLocalRot(direction)
        gd = self.getGlobalRot(Vector(ld.x, ld.y, 0))
        hyp = abs(math.tan(a) * lp.z)
        return gp.add(DraftVecUtils.scaleTo(gd, hyp))

[marioalexis]

You are right.
The precision value could be based on utils.precision() instead of hardcoded.

[Roy_043]

The precision value could be based on utils.precision() instead of hardcoded.

IMO the core functionality of the program/WB should not depend on user preferences. IMO the Draft precision should become obsolete. But maybe a default tolerance can be defined in some function?

[marioalexis]

@Roy_043 leaving aside the issue of Draft precision, this version for the projectPoint method is more simple and with less computation.

Code: Select all

def projectPoint(self, p, direction=None):
    if direction is None:
        direction = self.axis            
    proj = p - (p - self.position).dot(self.axis)/(direction.dot(self.axis))*direction
    return proj