Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upUpgrade and use cgmath #462
Conversation
Xaeroxe
added
project: audio
project: core
project: gltf
project: main crate
project: rendering
type: improvement
labels
Oct 26, 2017
Xaeroxe
requested review from
Rhuagh,
Aceeri and
torkleyy
Oct 26, 2017
Xaeroxe
referenced this pull request
Oct 26, 2017
Closed
[Discussion] Use cgmath as our official math library? #452
| @@ -1,28 +1,38 @@ | ||
| //! Local transform component. | ||
| -use cgmath::{Deg, InnerSpace, Matrix3, Matrix4, Point3, Quaternion, Rotation, Rotation3, Vector3}; | ||
| +use cgmath::{ |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
| /// Translation/position vector [x, y, z] | ||
| - pub translation: [f32; 3], | ||
| + pub translation: Point3<f32>, |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Rhuagh
Oct 26, 2017
Member
This should be Vector, translation is a movement quantity, but a positional quantity
Rhuagh
Oct 26, 2017
Member
This should be Vector, translation is a movement quantity, but a positional quantity
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Rhuagh
Oct 26, 2017
Member
And it's a relative translation from the parent and not an absolute position
Rhuagh
Oct 26, 2017
Member
And it's a relative translation from the parent and not an absolute position
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Xaeroxe
Oct 26, 2017
Member
I can make good arguments in my head for both, so I'll use Vector as you've suggested.
Xaeroxe
Oct 26, 2017
Member
I can make good arguments in my head for both, so I'll use Vector as you've suggested.
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Rhuagh
Oct 26, 2017
Member
I think the most compelling part is that it's a relative quantity, not absolute, in LocalTransform
Rhuagh
Oct 26, 2017
Member
I think the most compelling part is that it's a relative quantity, not absolute, in LocalTransform
| @@ -31,14 +30,14 @@ pub struct DirectionalLight { | ||
| /// Color of the light in RGBA8 format. | ||
| pub color: Rgba, | ||
| /// Direction that the light is pointing. | ||
| - pub direction: Vector3<f32>, | ||
| + pub direction: [f32; 3], |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
torkleyy
Oct 26, 2017
Member
Wasn't the goal consistency? So could we maybe just upgrade to gfx 0.17?
torkleyy
Oct 26, 2017
Member
Wasn't the goal consistency? So could we maybe just upgrade to gfx 0.17?
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Xaeroxe
Oct 26, 2017
Member
Apparently the most recent version of rustfmt-nightly says we were wrong on all of our formatting.
|
Apparently the most recent version of rustfmt-nightly says we were wrong on all of our formatting. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
|
Hope ya'll are ready for some rebases :/ |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Xaeroxe
Oct 26, 2017
Member
Using our cgmath now requires a couple features to be enabled by the person depending on cgmath, should we pub extern cgmath somewhere so they can easily get the right version and features? (I think yes so I've already added it to the PR but I want to hear what others think)
|
Using our cgmath now requires a couple features to be enabled by the person depending on cgmath, should we pub extern cgmath somewhere so they can easily get the right version and features? (I think yes so I've already added it to the PR but I want to hear what others think) |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
| - [0.0, 0.0, 1.0, 0.0], | ||
| - [0.0, 0.0, 0.0, 1.0], | ||
| - ]) | ||
| + Transform( |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
| - forward: [1.0, 0.0, 0.0], | ||
| - right: [0.0, -1.0, 0.0], | ||
| - up: [0.0, 0.0, 1.0], | ||
| + forward: [1.0, 0.0, 0.0].into(), |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Rhuagh
Oct 26, 2017
Member
In theory, you could use Vector3::unit_x() -Vector3::unit_y() etc, but might not be a point tbh
Rhuagh
Oct 26, 2017
Member
In theory, you could use Vector3::unit_x() -Vector3::unit_y() etc, but might not be a point tbh
| @@ -31,16 +33,16 @@ impl LocalTransform { | ||
| /// Combined with the parent's global `Transform` component it gives | ||
| /// the global (or world) matrix for the current entity. | ||
| #[inline] | ||
| - pub fn matrix(&self) -> [[f32; 4]; 4] { | ||
| + pub fn matrix(&self) -> Matrix4<f32> { | ||
| let quat: Matrix3<f32> = Quaternion::from(self.rotation).into(); | ||
| let scale: Matrix3<f32> = Matrix3::<f32> { |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
| - translation: [0.0, 0.0, 0.0], | ||
| - rotation: [1.0, 0.0, 0.0, 0.0], | ||
| - scale: [1.0, 1.0, 1.0], | ||
| + translation: [0.0, 0.0, 0.0].into(), |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
| - transform.translation = [0.0, 0.0, 0.0]; | ||
| - transform.rotation = [1.0, 0.0, 0.0, 0.0]; | ||
| + transform.translation = Vector3::zero(); | ||
| + transform.rotation = Quaternion::new(1.0, 0.0, 0.0, 0.0); |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
| for (_, transform) in (&camera, &mut transforms).join() { | ||
| // rotate the camera, using the origin as a pivot point | ||
| transform.translation = delta_rot | ||
| - .rotate_point(Point3::from(transform.translation)) | ||
| - .into(); | ||
| + .rotate_point(Point3::from_vec(transform.translation)).to_vec(); |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
| - trans.translation = [-5.0, 0.0, 0.0]; | ||
| - trans.scale = [2.0, 2.0, 2.0]; | ||
| + trans.translation = Vector3::new(-5.0, 0.0, 0.0); | ||
| + trans.scale = [2.0; 3].into(); |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
|
Rebased and addressed @Rhuagh |
Xaeroxe
added some commits
Oct 26, 2017
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Xaeroxe
Oct 26, 2017
Member
@torkleyy Since my current design sort of goes against the grain on our current crate structure allow me to explain myself:
cgmath is compiled with a particular version and set of features, it's of the utmost importance that that version and set of features are used consistently throughout not only our user's games but also our internal ecosystem. Otherwise, types that seemingly should be compatible, suddenly aren't. So, in order to guarantee synchronization and reduce the amount of times we have to specify these versions and features all amethyst crates and downstream pull in a cgmath that's re-exported from amethyst_core. This should allow us to drastically reduce the amount of turmoil caused by future upgrades and feature changes.
|
@torkleyy Since my current design sort of goes against the grain on our current crate structure allow me to explain myself: cgmath is compiled with a particular version and set of features, it's of the utmost importance that that version and set of features are used consistently throughout not only our user's games but also our internal ecosystem. Otherwise, types that seemingly should be compatible, suddenly aren't. So, in order to guarantee synchronization and reduce the amount of times we have to specify these versions and features all amethyst crates and downstream pull in a cgmath that's re-exported from amethyst_core. This should allow us to drastically reduce the amount of turmoil caused by future upgrades and feature changes. |
torkleyy
added
status: ready
type: RFC
labels
Oct 27, 2017
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
torkleyy
Oct 27, 2017
Member
I couldn't spot any logical issues, it's just the implied strategy regarding our math API that I'm not so sure about.
|
I couldn't spot any logical issues, it's just the implied strategy regarding our math API that I'm not so sure about. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
|
@torkleyy care to elaborate? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
torkleyy
Oct 27, 2017
Member
Well, I think the arguments on all sides are clear, we've gone over them a couple of times. It seems we can't find any full agreement, so..
|
Well, I think the arguments on all sides are clear, we've gone over them a couple of times. It seems we can't find any full agreement, so.. |
torkleyy
approved these changes
Oct 27, 2017
..take this as my approval together with the note that at least two other members should approve this before we proceed.
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
|
This is the only way we can make progress. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
|
r? @Aceeri |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
|
bors r+ |
bot
added a commit
that referenced
this pull request
Oct 28, 2017
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
|
So why don't we let @Aceeri approve this? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
|
bors r- |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Canceled |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
torkleyy
Oct 28, 2017
Member
Doesn't seem like @Aceeri is going to review this in the near future, so I have to merge this now.
bors r+
|
Doesn't seem like @Aceeri is going to review this in the near future, so I have to merge this now. bors r+ |
Xaeroxe commentedOct 26, 2017
•
edited
Edited 2 times
-
Xaeroxe
edited Oct 26, 2017 (most recent)
-
Xaeroxe
edited Oct 26, 2017
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