The future of cgmath

[brendanzab]

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.

[brendanzab]

cc. @csherratt @aepsil0n @tomaka @Darkspear7 @cmr

[brendanzab]

cc. @tomaka

[milibopp]

That is interesting to hear. I was thinking that nalgebra and cgmath ought to be unified at some point or at least have a common API in terms of traits. My main incentive to mostly use cgmath so far has been that I felt more people around piston were using it. However, nalgebra appears to be mathematically more rigorous in its API, so independent of your decision I am also inclined to switch to nalgebra.

So I would continue to contribute to Rust's algebra library ecosystem further, but it might make sense to find a common strategy as a community. From my point of view, porting features from cgmath to nalgebra could be the way to go. (Unless cgmath's feature set is a subset of nalgebra's, which I don't think is entirely the case.)

[bvssvni]

Anyone that volunteer to integrate cgmath or nalgebra? This could be done under PistonDevelopers while keeping a fork here to not break code more than necessary. Or else I think we should go for nalgebra and port stuff over/new libraries.

[brendanzab]

@aepsil0n: Yeah, I have been concerned about letting cgmath-rs putter along aimlessly like a zombie when there is a library that is another, superior (in lots of respects) library out there. @daronwilson and I are currently collaborating on a more foundational algebra abstraction, if you are interested. It's a really difficult problem, but @sebcrozet is definitely interested in basing nalgebra on that, once we can figure it out. Maybe you might be able to give us a hand if that interests you?

[milibopp]

Yes, I am definitely interested. I am aware of algebra, it looks like this is the abstraction one should eventually work with. How's the progress there? (Haven't really looked into the code-base.)

[kvark]

This is very sad to hear!

Looking at nalgebra, I don't see anything similar to our Transform trait and Decomposed implementation. Thus, I'm gonna continue using cgmath for the nearest future.

[kvark]

See also: discussion about the differences between cgmath and nalgebra: dimforge/nalgebra#23

[jarrett]

Having tried cgmath, nalgebra, and vecmath, I committed to cgmath for my projects. I'd be interested in assisting with the future of this library, whether that means it continues independently or merges with another library.

I'd also be interested in expanding the functionality of cgmath or its successor library. On top of cgmath, I've implemented some features that should be useful to other game developers, including intersections between lines and 3D AABBs:

https://github.com/jarrett/cities/tree/master/src/math

[kvark]

@jarrett Have you see the Bound trait? Perhaps, you could integrate part of your code by implementing Bound::relate_ray() and Bound::relate_bound for existing bounds.

[jarrett]

Just to clarify, are you saying the Bound trait would gain relate_ray and relate_bound as required or provided methods?

Edit: I'm thinking you mean provided methods. That way so long as a type implements relate_plane, the type automatically gets relate_ray and relate_bound? I think I see a problem there, though. As far as I know, you can't determine whether a line intersects an AABB just by asking whether the line intersects each of the AABB's planes. Often, a line will indeed intersect all the box's planes, and yet it won't intersect the box itself. So it's not clear to me that we can express the intersection between a line and an Aabb3 using the Bound trait. Thoughts?

[kvark]

@jarrett I meant add relate_ray() and relate_bound() to the Bound trait and implement them for particular types (points, spheres, boxes, etc).

[jarrett]

Ok. So they'd be required methods, not provided methods. Correct? If so, then I think that should work.

[kvark]

@jarrett yep, I don't think you can derive one from another.

[jarrett]

Three issues:

First issue: My implementation depends on the line being represented in parametric form. Whereas cgmath's Line3 has a different representation. I'm guessing you don't want to add my custom PLine3 type to cgmath. So one option is to add fields to the Line3 struct for dx, dy, and dz at the cost of extra memory. Another option is to add dx(), dy(), and dz() methods to Line3 at the cost of CPU cycles every time those values are used.

Second issue: Would it have to be relate_bound3 instead of relate_bound? Or is there a way to make that generic? Sorry, I'm still not clear on the big picture you have in mind for the Bound trait.

Third issue: Suppose I have time in the near future to implement relate_bound3 for Line3, but not for spheres etc. Should I just implement relate_bound3 on the other types with a panic? E.g.:

impl<S: BaseFloat + 'static> Bound<S> for Sphere<S> {
    // ...

    fn relate_bound3(&self, bb: &Aabb3<S>) -> {
        panic!("Not implemented.");
    }
}

By the way: Before I go farther down this rabbit hole, where do we stand on the future of this library? Does it make sense to continue expanding its features? Or will it be merged with another library?

[kvark]

@jarrett

1. There is no line in cgmath anyway, it's the Ray, which goes only one direction. What do you need lines for? EDIT: my bad! there is a line...
2. fn relate_bound(&self, other: &Self) -> Relation. Strictly speaking, all currently implemented bounds are 3D, and this would be nice to extend to N dimensions, maybe at some point...
3. You can't implement Bound for your Line3, because it doesn't make for a line to be a bound to anything. Bounds are:
   • Point3 (trivial case)
   • Sphere
   • Aabb3
   • Obb (TODO)

Before I go farther down this rabbit hole, where do we stand on the future of this library? Does it make sense to continue expanding its features? Or will it be merged with another library?

I can't answer for everyone. I don't hear too many strong opinions on the matter (unfortunately). But I'm continuing using it and extending it (all the Bound stuff was added after this issue) for gfx_scene, claymore, and other projects. I can see certain interest from @csherratt as well. We have the access and can develop the library without @bjz participation. I'm not aware of any plans to merge it with nalgebra or anything, outside of vague wishes.

[jarrett]

1. Line does exist. One good use is to represent the mouse position in an orthographic projection. (The way I typically model ortho, the camera has no position. Thus the mouse position describes a line rather than a ray.)
2. I guess I don't understand how you envision the Bound trait fitting together. I.e. which types have the trait implemented, and which types can be passed as the parameter to relate_bound. When I get a chance, I'll take a look at your existing code and see if I can infer as much.

[kvark]

@jarrett yes, my bad, line truly exists ;) We can have a default implementation for relate_line by calling relate_ray twice though, or maybe you'll just call relate_ray on your end. If we are talking about mouse position, it's a single cast per frame, so any kind of conversion to/from a parametric form is irrelevant for the performance.

A Bound was designed like something that encloses a 3D volume, simple as that. The relate_bound I proposed would work on the Self type only. Is it any clearer now?

[kvark]

@bjz Since you are back and hacking in full sail already, perhaps you could comment here to update your position towards the subject? People are still hell of being confused.

[brendanzab]

Sorry! Good thought. Since being kicked up the bottom by @tomaka, I have decided to get back to updating cgmath. I tried nalgebra for a time, and found it hard to use, so I'm going to really try to polish cgmath with a view for improving ergonomics for gamedev use. So closing this now.

[kvark]

\o/ you made my day, @bjz ;)

Regards,
Dzmitry

On Sep 30, 2015, at 19:38, Brendan Zabarauskas notifications@github.com wrote:

Closed #144.

—
Reply to this email directly or view it on GitHub.