When inverting a matrix, we check that the determinant is non-zero using approx_eq. If the determinant is approximately zero, the inversion fails.

But approx_eq only goes to a precision of 10^-5.

That's problematic, because projection matrices often have very small determinants. This is especially true when the camera is zoomed out very far. In that case, we're transforming a large volume of world space to the clip space volume. Which means that the determinant tends to be very small. (This is because the determinant is the ratio of the two volumes.)

Would it be possible to see a new release sometime soon? I'm trying to trim down dependencies and the rand crate was made optional about a year ago. It would be nice to exclude that when it's not needed.

I'd like to use Aabb2 as a rectangle type in my code, and want the basic representation to match the range of points inside the box instead of the center: struct Aabb2 { top: Point2, size: Vec2 }. Rectangle code is mostly concerned with the edges instead of the center, so accessing those with simple arithmetic that doesn't involve dividing size components by two would be quite nice.

Code that needs the box center can use a method which derives the center point from the top and size data.

Includes #417 r? @brendanzab

Notice how matrix and Euler conversions have stronger types (to ColumnMatrix*<> and EulerAngles<, IntraXYZ> respectively).

I currently am stretching myself quite thin when it comes to projects, and I feel like I am no longer able to adequately steer the development of cgmath going forwards. I am also considering moving to @sebcrozet's nalgebra library for my future projects. I can continue to merge PRs, but I can't see myself contributing much heading into the future. If somebody has the passion or energy to spare to keep things going, I am also happy to transfer ownership of the repository.

Hello all!

I'm incredibly sorry with my lack of involvement in cgmath as of late. I currently have a bunch of notifications in my Github inbox that I have been avoiding clicking on, which is never a good sign! A big problem is that I'm not currently working on any game projects myself which makes it incredibly hard to empathise with current pain-points with the library as it currently stands.

I was wondering if anyone, or a group of people would be willing to take up the reigns of cgmath, seeing as it is obvious that I can no longer invest time in the project? If not I might be able to put up a notice that redirects people to more actively developed libraries like nalgebra or euler.

cc. #419

The corresponding functions have been added to Matrix4 and Decomposed and are now consistent.

Matrix3, Matrix2, and the Rotation trait are only partially updated. The look_at methods on these should probably be renamed to look_to_[lh|rh] as they take a direction vector, not a focus point. Does handedness even make sense for Matrix2?

The older functions have all been left in-tact and marked deprecated. I don't think the old functionality should be removed in the near or medium term.

Pursuant to conversations in #337, #302, and #324, I've implemented Transform for these two matrices. This makes working with the matrices as fully-fledged transformations much easier.

Along the lines of https://github.com/bjz/cgmath/pull/302#issuecomment-211168768, I've also implemented Transform2 and Transform3 for Matrix3, to reflect its potential use as both a 3D rotation matrix and a 2D affine transform.

Transform3 is implemented for Matrix4 as well, and I moved the From impls down with the rest of the From impls, in an unrelated edit which I think nonetheless improves readability of what is now a rather large file.

I'm not positive I've gotten the Transform2 implementation for Matrix3 correct, would appreciate a sanity check :D

Vector +- Vector Point +- Vector Matrix * Vector Quat * Vector ... probably a lot more, but we need to keep the behavior strictly obvious (i.e. not overloading Vector*Vector as a dot product)

Closes #481

This PR leaves the feature enabled by default so that this can be released as a minor version soon. (I would suggest to disable it by default in future versions, but that's another discussion.)

The changes are pretty straight forward with one catch: I changed some use statements to nested imports (otherwise, there would be even more #[cfg(feature = "rand")] lines). Nested imports were stabilized in 1.25 (see the edition guide on this feature). I'm not sure how cgmaths policy on minimum compiler version is. Maybe cgmath already requires a >= 1.25 compiler for other reasons. If my change is a problem, just tell me and I will change the imports back.

Closes #143, #194

Given the interactions on IRC, they cause more confusion than perhaps they are worth. Perhaps we can re-add them in the future with a better API, but for now I would like to focus more on simplicity.

The following traits and types have been removed:

• Rotation types and structs: Rotation, Rotation2, Rotation3, Basis3, Basis3
• Transform types and structs: Transform, Transform2, Transform3, Decomposed, AffineMatrix3

Hello, I noticed that there was no method to normalize a vector where the zero vector maps to itself. I looked at the issues and found https://github.com/rustgd/cgmath/issues/450. I thought I might as well implement it.

Thanks for looking at this,

• Ruairidh

Sometimes it's necessary to calculate inverse + transpose matrix, to calculate proper normals matrix, for example. There are (of course) methods to do this. But (i presume) it is not an optimal solution, because invert methods already contain transpose operation. I suggest to add methods like invert_and_transpose, equivalent to invert but without transpose in last step.

Infinite far planes is a standard trick that actually improves the precision of the Z buffer.

See for instance https://thxforthefish.com/posts/reverse_z/ and https://developer.nvidia.com/content/depth-precision-visualized

AMD Ryzen 7 3700X Windows 10 19044.1566 rustc 1.60.0-nightly (1e12aef3f 2022-02-13)

The other day I was testing sprite performance in my engine and noticed it was a lot lower than usual. Investigated the cause and found it was when I updated cgmath from 0.17 to 0.18.

With 0.17, my benchmark that does 100k translations, rotations, and scales on a Matrix3:

test bench_transform_matrix ... bench: 670,110 ns/iter (+/- 13,076)

With 0.18:

test bench_transform_matrix ... bench: 2,755,590 ns/iter (+/- 10,904)

The bench itself Code for the transform wrapper

Since the transform happens for each sprite, the performance difference adds up quickly.

Using default features with -O2/-O3. Compiler target is x86_64-pc-windows-msvc.

The conversion between a vector and a tuple is defined as follows:

https://docs.rs/cgmath/0.18.0/src/cgmath/macros.rs.html#226-238

impl<$S> AsRef<$Tuple> for $ArrayN<$S> {
    #[inline]
    fn as_ref(&self) -> &$Tuple {
        unsafe { mem::transmute(self) }
    }
}

impl<$S> AsMut<$Tuple> for $ArrayN<$S> {
    #[inline]
    fn as_mut(&mut self) -> &mut $Tuple {
        unsafe { mem::transmute(self) }
    }
}

which is effectively a cast between &[T; 2] and &(T, T) and contains unspecified behavior since the layout of tuples (exept the unit ()) is not defined.

https://doc.rust-lang.org/reference/type-layout.html#tuple-layout

Tuples do not have any guarantees about their layout.