Different floating point results between cq-editor and cadquery master

[bernhard-42]

I have played with Bernd's example and suddenly ran into the same issue like marcus7070 in
#252 (comment)

Digging deeper I found a strange difference in how cadquery from the latest cq-editor and cadquery master reacts.

environment 1 (cq-editor):

conda create -n cq-editor python=3.7
conda activate cq-editor
conda install -c cadquery -c conda-forge cq-editor

environment 2 (cadquery master):

conda create -n cq-cl-master python=3.7
conda activate cq-cl-master
conda install -c conda-forge -c cadquery cadquery=2
git clone https://github.com/CadQuery/cadquery.git
cd cadquery/
pip install .

The example:

import cadquery as cq

x1 = (cq
    .Workplane("front")
    .circle(30)
    .workplane(offset=50)
    .center(15, 0)
    .rect(20, 20)
    .loft(combine=True)
)

x2 = (x1
    .faces(">Z")
    .workplane()
    .rect(9, 200)
    .cutBlind(-40)
)

x3 = (x2
    .faces(">Z[-2]")
    .workplane()
)

x4 = (x3
    .transformed(rotate=(0, -90, 0)).workplane()
)

x5 = (x4
    .center(10, 0)
    .circle(4)           
    .cutThruAll(clean=False)
)

In the screenshot below, the left side is environment 1, right side environment 2 (both on Ubuntu 18.04)

Why are the coordinates of x4 for the both environments so different? Btw. this leads to the offset observed by Marcus

Another point I don't understand, why does the x and y component of the origin change from x2 to x3? Since cutBlind cuts vertically and the center is not changed, I would have expected that x and y of the center are unchanged.

[bernhard-42]

I found out that up to commit b19b8ff it worked, with commit e9924ba the new/wrong behaviour appeared

@Peque Any idea how your fix impacts this example?

@adam-urbanczyk @jmwright Could you maybe explain the second question? What am I missing that explains the change in x and y?

[marcus7070]

Interesting interaction between the offset of a plane's origin and Workplane.transformed(rotate=(90, 0, 0):

import cadquery as cq

for offset in [0, 1, 10]:
    part = cq.Workplane("XY", origin=(offset, 0, 0)).transformed(rotate=(90, 0, 0))
    print(f"offset = {offset}, plane.zDir = {part.plane.zDir}")

results in:

offset = 0, plane.zDir = Vector: (0.0, -1.0, 1.1102230246251565e-16)
offset = 1, plane.zDir = Vector: (0.0, -0.9998476951563913, -0.017452406437283408)
offset = 10, plane.zDir = Vector: (0.0, -0.9848077530122081, -0.17364817766693033)

I'm kind of surprised this hasn't broken any tests, since that error is above the tolerance used when selecting faces parallel or perpendicular to a direction.

[adam-urbanczyk]

It looks like a duplicate of #254

[marcus7070]

Sorry @adam-urbanczyk, I don't understand. #254 is about mixing up rotation axes. No matter what axis I rotate about 90 degrees, I should only wind up with plane.zDir.z as one of -1.0, 0.0, 1.0 (within a tolerance), right?

Or are you suggesting #254 is actually partially caused by this?

[bernhard-42]

For the x and y variable of the center I fell into the CoM trap. I was expecting a result as with centerOption="ProjectedOrigin" (and I know, there is an ongoing discussion around it)

However, this does not explain the skew of transformed. Starting from a face that is parallel to the xy plane, I would have expected that the xDir, yDir, zDir matrix after rotating around one axis by 90° would consist of unit vectors only.
@adam-urbanczyk, I agree with @marcus7070, this is not about the question in #254 because a change of the rotation axis does not help here. And we are not talking about rounding errors:

orig:  15.0000000000,  -0.0000000000,  10.0000000000
xDir:   0.0000000000,  -0.0871557427,   0.9961946981
yDir:  -0.0000000000,   0.9961946981,   0.0871557427
zDir:  -1.0000000000,  -0.0000000000,   0.0000000000

To further visualize the problem, I added two rects:

import cadquery as cq

x1 = (cq
    .Workplane("front")
    .circle(30)
    .workplane(offset=50)
    .center(15, 0)
    .rect(20, 20)
    .loft(combine=True)
)

x2 = (x1
    .faces(">Z")
    .workplane()
    .rect(9, 200)
    .cutBlind(-40)
)

x3 = (x2
    .faces(">Z[-2]")
    .workplane(centerOption="ProjectedOrigin")
    .rect(9,9,9,9)
)

x4 = (x3
    .transformed(rotate=(0, -90, 0)).workplane()
    .rect(9,9,9,9)
)

So we see here a significant skew.
Where does it come from? Are my assumptions wrong?

[bernhard-42]

Are we sure that this is allowed:

cadquery/cadquery/occ_impl/geom.py

Line 622 in 3cd466a

rotate = Vector(self.toWorldCoords(rotate))

rotate is a tuple of angles. The documentation for toWorldCoords says: "tuplePoint: point in local coordinates to convert." Applying toWorldCoords now transforms a tuple of angles like it would be a point in space.

In my example this line applied:

p = x3.plane
rotate = (0, 90, 0)
Vector(p.toWorldCoords(rotate))

returns Vector: (15.000000000000142, 90.0, 10.000000000000007) which is a combination of coords (15.0 and 10.0) with an angle (90.0).

[bernhard-42]

@adam-urbanczyk @Peque I changed rotate = Vector(self.toWorldCoords(rotate)) back to rotate = Vector(rotate) and the skew is gone. Looks like e7608e1 reverts it but is not merged yet ...

[Peque]

@bernhard-42 Yeah, rotate = Vector(self.toWorldCoords(rotate)) is wrong, and #243 should fix it, but is not merged yet.

I'm kind of surprised this hasn't broken any tests, since that error is above the tolerance used when selecting faces parallel or perpendicular to a direction.

@marcus7070 There were no tests for plane rotations. #235 added one, but was insufficient and resulted in a broken implementation (sorry for that 😅). #243 adds more tests and hopefully results in a better implementation. 😊

[adam-urbanczyk]

Alright, to sum up this a duplicate of #254 . Current implementation is wrong as @Peque noted. You know the workaround (revert changes from #235 ). Let's continue the discussion in #254 regarding long term solutions.