V0.19 DraftVectUtils.angle

[petit_chat_noir]

On function from DraftVectUtils :

def angle(u, v=Vector(1, 0, 0), normal=Vector(0, 0, 1)):
"""Return the angle in radians between the two vectors.

45° and 90° are inverted with 270° and 315°

45° result -0.785 radians
90° result -1.570 radians with Vector(0,10,0) provided

Code: Select all

OS: Debian GNU/Linux bullseye/sid (KDE//usr/share/xsessions/plasma)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.18479 (Git)
Build type: Release
Branch: master
Hash: 8f72e1fde67c738fbbcdea0f176733f68e838d3b
Python version: 3.7.5rc1
Qt version: 5.13.1
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: French/France (fr_FR)

[petit_chat_noir]

Ok So,
if I'am on XY plan (top view), then I use normal plan wich is along Z (0,0,1)
I have to to do angle = - angle to have a trigonometric way working ..... I think there's a problem on this function
exemple :

0° DraftVecUtils.angle((0,1,0),normal=(0,0,1)) return -0 ; it's ok
45° DraftVecUtils.angle((1,1,0),normal=(0,0,1)) return -0.78 ; it's should be 0.78
90° DraftVecUtils.angle((0,1,0),normal=(0,0,1)) return -1.57 ; it's should be 1.57
135°DraftVecUtils.angle((-1,1,0),normal=(0,0,1)) return -2.35 ; it's should be 2.35
180°DraftVecUtils.angle((-1,0,0),normal=(0,0,1)) return -3.14 ; it's should be 3.14
225°DraftVecUtils.angle((-1,-1,0),normal=(0,0,1)) return 2.35 ; wow ok it should be -2.35 or 3.92
270°DraftVecUtils.angle((0,-1,0),normal=(0,0,1)) return 1.57 ; it's should be -1.57 or 4.71

maybe normal vector transformation is not good, because if you turn it in Z- all is working....

[paullee]

I am not sure what @Yorik originally design.

I also add -ve to the result for consistency with what I understand is FC's convention : +ve for anti-clockwise

[vocx]

In mathematics a positive angle is normally counter-clockwise. I've noticed that in some Draft code the Y vector is inverted. I think this is done because in computer graphics the Y vector is defined positive when it points down, instead of up. But I think this is done in code that handles SVG shapes; I'm not sure if it's done everywhere. I'm not sure if this is related.

[yorik]

Indeed there are several conventions used in FreeCAD, depending on the area (SVG works indeed differently). However, indeed I think the DraftVecUtils angle sign is wrong... The problem is, it is used all over FreeCAD now, and possibly in many external workbenches too... We are up to big chaos if we change...

[vocx]

Indeed there are several conventions used in FreeCAD, depending on the area (SVG works indeed differently). However, indeed I think the DraftVecUtils angle sign is wrong... The problem is, it is used all over FreeCAD now, and possibly in many external workbenches too... We are up to big chaos if we change...

Just to confirm, this wasn't changed recently, right?

I was thinking that maybe some of the code from realthunder or wmayer modified something internal in the way the vectors are calculated or something like that. But if the behavior of DraftVecUtils.angle has always been like this, then there is no "problem" in fact.

Also, somebody asked this some weeks or months ago. Why does this exist at all? Maybe at the time these functions were written, the vectorial methods from C++ (Eigen3) weren't exposed, so doing mathematics in Python was the only way, or is there another reason?

[yorik]

Just to confirm, this wasn't changed recently, right?

No, it's so since the beginning, that's the problem

Also, somebody asked this some weeks or months ago. Why does this exist at all? Maybe at the time these functions were written, the vectorial methods from C++ (Eigen3) weren't exposed, so doing mathematics in Python was the only way, or is there another reason?

No it's exactly that... We should end transferring all the contents of DraftVecUtils to the Vector class itself at some point, then DraftVecUtils shouldn't need to exist anymore

[vocx]

No it's exactly that... We should end transferring all the contents of DraftVecUtils to the Vector class itself at some point, then DraftVecUtils shouldn't need to exist anymore

DraftVectUtils has a ton of functions, but most of them don't seem to be used a lot in Draft. If I were to guess I'd say most functions are already part of the Vector class.

Some references
FreeCAD vector math library - is that up to date?
Outdated Wiki? FreeCAD_vector_math_library
[SOLVED] BUG? - - - getAngle() return Negative Angle as Absolute Angle?
Dimensioning to point of intersection

[yorik]

Yes exactly.. In the past I have ported some to the Vector class already, and probably forgot to mark some as obsolete in DraftVecUtils...

[paullee]

I can't remember I had written that 2 posts if not vocx dig them out