Spurious displacement when combining copied/transformed objects

I'm having trouble combining object copies rotated about horizontal axes.  In the following geometry a copy of a 'leaf' (CS2) is being made under a rotation about a vertical axis passing through the origin.


After copying, a rotated copy (of CS4) is attempted about a horizontal axis at the upper edge of the leaf:


All looks good so far:


Now we attempt to combine objects after deleting CS4:


The combined geometry places the CS5 copy in an entirely new position, as if translated upward and toward the z-axis (rotation looks unchanged.)  Note that the initial copy operation isn't the issue: the same thing will happen for a translated copy or a brand new object.  Analogous behavior isn't noted when combining copies (objects like CS4) made with a rotation about the z-axis.


Any help would be appreciated.

Any help would be appreciated.

Hi, thank you for submitting the issue. It could be an internal error in the geometry engine (possibly a geometry object internally has the wrong center coordinates). If possible, could you attach or upload it to some shared hosting (for example google drive, wetransfer) the original model (from step 1) so we can reproduce the issue?

I've deduced that under combination, the axis pass-through point is switched to the origin.  This makes no difference in some specific cases, of course, e.g., all axes defined by vector (0,0,1) and points of the form (0,0,z) are identical.  In general, however, the current solution seems to be computing/manually correcting the resulting 3D displacements.  This is problematic if there are many objects an/or configurations, as there are in this case: 32 leaves, each with a different rotation about a different horizontal axis, and multiple sets of those rotations to test.

The basic case is linked below.  The problem can be duplicated by making a rotated copy of CS2 about the axis defined by vector (0,1,0) and point (0,-0.6069,1.02) -- a point on the top, inner edge of the 'leaf' -- by -pi/2 and then combining as B1-CS1-CS2-CS3.  The position of the rotated copy in the combined domain will be as if the rotation was done about the axis defined by vector (0,1,0) about point (0,0,0).

https://drive.google.com/file/d/1pdJXExOb1hXCPfdUmpBu2xcqgNhbkof-/view?usp=drive_link

Incidentally, rotating without copying does not work for me.  It appears to do some rotation, but very slight relative to the amount specified.  Not a big deal to delete originals before combining, but something to note.

Thank you very much for the troubleshooting, and detailed explanation of the issue. We will try to have a fix with the next release due in a few months or so (most likely a "proper" fix will require modifying the internals of the geometry engine so a quick patch probably won't be possible).

In the meantime I guess a workaround could be to export the geometry as a STEP file, and perform the problematic operations in a dedicated CAD software such as Fusion360, OnShape, or maybe FreeCAD (although FreeCAD and FEATool shares the same OpenCASCADE geometry kernel, their implementation is likely different and maybe does not exhibit this issue).

Thanks again for reporting, and I will update this thread when a fix has been found and released. Feel free to submit more issues if you encounter any.

Just to update on this issue, the problem has been identified as due to incorrect unit scaling of the base coordinates for rotation. The issue has been fixed in release v1.16.5.

For earlier releases, a workaround is to redo the scaling and multiplying all rotational base coordinates with 1000 (unfortunately all rotated objects must be reverted to their unrotated state as their rotated position is incorrect internally).

Thanks again for the report and your patience.