Skip to content
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.

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

Consider exposing math types via `mint` #236

Closed
kvark opened this issue May 26, 2017 · 5 comments
Closed

Consider exposing math types via `mint` #236

kvark opened this issue May 26, 2017 · 5 comments

Comments

@kvark
Copy link
Member

@kvark kvark commented May 26, 2017

https://github.com/kvark/mint

Exposing cgmath types would introduce conflicts whenever cgmath updates faster than Amethyst. More importantly, it would alienate nalgebra and euclid users. The solution I see is to use a neutral standard for math interop, which is where mint comes handy. It's not a math library, so it's not competing with anything. It's not introducing any new types, so it's not even required to be a dependency.

@kvark kvark added the type: RFC label May 26, 2017
@torkleyy

This comment has been minimized.

Copy link
Member

@torkleyy torkleyy commented May 26, 2017

Okay, I'm fine with the general idea of exposing math types like this. Do we want to accept Vector3 or Into<Vector3> types then? I experienced that beginners find it complicated to have such a type, but it makes the usage easier.

@kvark

This comment has been minimized.

Copy link
Member Author

@kvark kvark commented May 26, 2017

On one hand, Into<T> is always implemented for T.
On the other hand, we don't have a strong confirmation yet that Into/From will indeed be provided by the existing math libraries, so perhaps we shouldn't rush into conclusions here.
A safe bet would be to wait and see how the corresponding PRs (into math libs) are going to be accepted, if any.

@kvark

This comment has been minimized.

Copy link
Member Author

@kvark kvark commented Jun 1, 2017

I don't think Amethyst needs to be the first adopter for mint. I'll get genmesh, maybe plane-split and other stuff on it first, see how it goes. It depends on how math authors see it.

@kvark

This comment has been minimized.

Copy link
Member Author

@kvark kvark commented Oct 9, 2017

Ok, Three-rs is now the front adopter for mint, and it seems to work out fine.
In other news, nalgebra got on board 🎉
I think we reached the point where mint could be considered here for real :)

@Rhuagh

This comment has been minimized.

Copy link
Member

@Rhuagh Rhuagh commented Oct 9, 2017

We don't do an awful lot of math internally in amethyst at this point, but Transform, LocalTransform etc could benefit from using mint types.

bors bot added a commit that referenced this issue Oct 28, 2017
Merge #462
462: Upgrade and use cgmath r=Xaeroxe a=Xaeroxe

This upgrades us to cgmath 0.15, uses it where appropriate, and enables the mint feature for it.

You may have noticed that the renderer actually lost cgmath types in this PR, this was a necessary sacrifice to upgrade to 0.15. 0.15 is the only version released with mint support.  Our current gfx version uses cgmath 0.14 so the gfx trait implementations were not compatible with cgmath 0.15.

Closes #452
Closes #200 
Closes #236
bors bot added a commit that referenced this issue Oct 28, 2017
Merge #462
462: Upgrade and use cgmath r=torkleyy a=Xaeroxe

This upgrades us to cgmath 0.15, uses it where appropriate, and enables the mint feature for it.

You may have noticed that the renderer actually lost cgmath types in this PR, this was a necessary sacrifice to upgrade to 0.15. 0.15 is the only version released with mint support.  Our current gfx version uses cgmath 0.14 so the gfx trait implementations were not compatible with cgmath 0.15.

Closes #452
Closes #200 
Closes #236
@bors bors bot closed this in #462 Oct 28, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Engine
  
New
5 participants
You can’t perform that action at this time.