Skip to content

fix Ge.Matrix3d.scale3d() #450

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
CEXT-Dan merged 1 commit into from
Jan 26, 2026
Merged

fix Ge.Matrix3d.scale3d() #450

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion PyRxCore/PyAcGe.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1899,7 +1899,7 @@ static AcGeScale3d AcGeMatrix3dGetScaling3d(const AcGeMatrix3d& xf)
AcGeVector3d y;
AcGeVector3d z;
xf.getCoordSystem(pnt, x, y, z);
return AcGeScale3d(x.length(), y.length(), z.length());
return AcGeScale3d(x.x, y.y, z.z);
Copy link

Copilot AI Jan 26, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The 2D version of this function (AcGeMatrix2dGetScaling2d at line 865) still uses x.length() and y.length(), which would have the same issue with negative scaling factors. Consider applying the same fix to the 2D version for consistency: return AcGeScale2d(x.x, y.y) instead of AcGeScale2d(x.length(), y.length()).

Copilot uses AI. Check for mistakes.
Copy link
Collaborator Author

@gswifort gswifort Jan 26, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@copilot open a new pull request to apply changes based on this feedback

Copy link

Copilot AI Jan 26, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider adding a test case for negative scaling to verify this fix works correctly. For example, test that Matrix3d.scaling(-5, Point3d.kOrigin).scale3d() returns Scale3d(-5, -5, -5) and not Scale3d(5, 5, 5).

Copilot uses AI. Check for mistakes.
Copy link
Collaborator Author

@gswifort gswifort Jan 26, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@copilot open a new pull request to apply changes based on this feedback

Copy link

Copilot AI Jan 26, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change fixes negative scaling for axis-aligned matrices but breaks behavior for non-axis-aligned transformations.

For axis-aligned scaling (e.g., Matrix3d.scaling(-5, ...)):

  • Basis vectors: x=(-5,0,0), y=(0,-5,0), z=(0,0,-5)
  • Old: (5, 5, 5) - incorrect, loses sign ✗
  • New: (-5, -5, -5) - correct ✓

For rotated transformations (e.g., 45° rotation, no scale):

  • Basis vectors: x≈(0.707,0.707,0), y≈(-0.707,0.707,0), z=(0,0,1)
  • Old: (1, 1, 1) - correct magnitudes ✓
  • New: (0.707, 0.707, 1) - incorrect, not meaningful scale values ✗

Consider one of these approaches:

  1. If scale3d() is only intended for axis-aligned matrices, add documentation stating this limitation
  2. Use a proper decomposition: sign(determinant) * length() for uniform scale, or sign(x.x) * x.length() for each axis where sign() uses the component with largest absolute value
  3. Check if vectors are axis-aligned (only one non-zero component) and use component if true, else use length()

Copilot uses AI. Check for mistakes.
}

static AcGePoint3d AcGeMatrix3dGetOrigin(const AcGeMatrix3d& xf)
Expand Down