Add coordinate system trait and implementations for Vec3 and Vec2

[bitshifter]

This is related to #1663 which proposes changing local_y to local_up and so on. Internally these methods currently rotate Vec3::Y for local_y but if they are changed to local_up then they can now rotate Vec3::UP.

[cart]

I'm a bit torn on this one. I think right/left/up/down are friendlier/more natural names. But idk if the added "trait extension method" complexity is worth it. Its less discoverable and forces users to import it (either via prelude or manually). The cost of that versus learning that y is up, z is back, and x is right (and negating them for the other directions) feels pretty similar.

I briefly considered proposing "opt-in right hand and left hand coordinate system features for glam", which would define the appropriate constants when one or the other feature is enabled. But that probably doesn't solve the documentation / discovery problem. I'm still curious to hear your thoughts on that though :)

[bitshifter]

I was experimenting with ways of doing this without adding them to glam basically. Ideally glam at it's core would be co-ordinate system agnostic, it's not quite there yet though. So I'm trying to come up with ways to have coordinate system specific functionality outside of core glam. I guess a features would be an alternative way, I have concerns about that approach, in that there might be a lot of different combinations so support, also there might be clashes if a project managed to have dependencies with different features enabled (not sure how realistic that is though).

Thinking about the math library we have at work and what is possibly more useful is having constants for the indices of different axes, e.g. SIDE = 0, UP = 1, FORWARD = 2. That won't help with directionality but it's useful for grabbing the correct axis out of a matrix. Those could be usize constants which don't need to be extension methods. That's kind of solving a different problem to these constants, but related. I do find it useful to be unambiguous about these things.

Other co-ordinate specific things that it would be good to move out of glam, or make more general are using Euler rotations and also look at matrix functions. So this PR is also exploring ways of defining those outside of glam, to suit the project that is using them.

[cart]

Yeah I can see feature clashing being a problem. I guess at the end of the day users will probably need to import something to get these values. Maybe an extension trait is the right call.

In the short term I think I'll hold off on merging this as I'm still working out my opinions on it and I'm curious to see what others think.

[alice-i-cecile]

I like this much better than the status quo. While from an end user perspective:

The cost of that versus learning that y is up, z is back, and x is right (and negating them for the other directions) feels pretty similar.

may be true, it's much more challenging to read code defined in terms of +/-z (especially with some padding zeros) than one that uses "up" and "down".

I would ultimately prefer a "typed coordinate systems" approach where these constants are defined within those types, and a common trait joining them all, but I suspect that that will be too heavy of an abstraction for most game programmers to swallow.

But that probably doesn't solve the documentation / discovery problem. I'm still curious to hear your thoughts on that though :)

IMO with an extended book and a chapter on transforms (plus use in the examples) I don't see this being a huge problem. They're also very discoverable through searching "up" on docs.rs, which goes a long way for the users that dive in.

[IceSentry]

At this point you are going to need to rebase, but the code addition are nice and simple.

[inodentry]

I like this and I'd like to vote in favor of merging it. Seems like a non-intrusive usability improvement.

[cart]

Closing as this is unlikely to be merged in its current state and I'm still not fully sold on the approach. Anyone is free to create a new issue if they want to open this conversation.