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

Upgrade and use cgmath #462

Merged
merged 6 commits into from Oct 28, 2017

Conversation

@Xaeroxe
Member

Xaeroxe commented 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

@@ -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.

@Rhuagh

Rhuagh Oct 26, 2017

Member

Weird formatting

@Rhuagh

Rhuagh Oct 26, 2017

Member

Weird formatting

/// Translation/position vector [x, y, z]
- pub translation: [f32; 3],
+ pub translation: Point3<f32>,

This comment has been minimized.

@Rhuagh

Rhuagh Oct 26, 2017

Member

This should be Vector, translation is a movement quantity, but a positional quantity

@Rhuagh

Rhuagh Oct 26, 2017

Member

This should be Vector, translation is a movement quantity, but a positional quantity

This comment has been minimized.

@Rhuagh

Rhuagh Oct 26, 2017

Member

And it's a relative translation from the parent and not an absolute position

@Rhuagh

Rhuagh Oct 26, 2017

Member

And it's a relative translation from the parent and not an absolute position

This comment has been minimized.

@Xaeroxe

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

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.

@Rhuagh

Rhuagh Oct 26, 2017

Member

I think the most compelling part is that it's a relative quantity, not absolute, in LocalTransform

@Rhuagh

Rhuagh Oct 26, 2017

Member

I think the most compelling part is that it's a relative quantity, not absolute, in LocalTransform

amethyst_renderer/src/light.rs
@@ -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.

@torkleyy

torkleyy Oct 26, 2017

Member

Wasn't the goal consistency? So could we maybe just upgrade to gfx 0.17?

@torkleyy

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.

@Xaeroxe

Xaeroxe Oct 26, 2017

Member

0.17 isn't on crates :(

@Xaeroxe

Xaeroxe Oct 26, 2017

Member

0.17 isn't on crates :(

This comment has been minimized.

@Xaeroxe

Xaeroxe Oct 26, 2017

Member

Although I'll add a Todo for when we do upgrade our gfx

@Xaeroxe

Xaeroxe Oct 26, 2017

Member

Although I'll add a Todo for when we do upgrade our gfx

@Xaeroxe

This comment has been minimized.

Show comment
Hide comment
@Xaeroxe

Xaeroxe Oct 26, 2017

Member

Apparently the most recent version of rustfmt-nightly says we were wrong on all of our formatting.

Member

Xaeroxe commented Oct 26, 2017

Apparently the most recent version of rustfmt-nightly says we were wrong on all of our formatting.

@Xaeroxe

This comment has been minimized.

Show comment
Hide comment
@Xaeroxe

Xaeroxe Oct 26, 2017

Member

Hope ya'll are ready for some rebases :/

Member

Xaeroxe commented Oct 26, 2017

Hope ya'll are ready for some rebases :/

@Xaeroxe

This comment has been minimized.

Show comment
Hide comment
@Xaeroxe

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)

Member

Xaeroxe commented Oct 26, 2017

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)

@Xaeroxe

This comment has been minimized.

Show comment
Hide comment
Member

Xaeroxe commented Oct 26, 2017

- [0.0, 0.0, 1.0, 0.0],
- [0.0, 0.0, 0.0, 1.0],
- ])
+ Transform(

This comment has been minimized.

@Rhuagh

Rhuagh Oct 26, 2017

Member

Matrix4::one() ?

@Rhuagh

Rhuagh Oct 26, 2017

Member

Matrix4::one() ?

@Rhuagh

Rhuagh approved these changes Oct 26, 2017

amethyst_core/src/orientation.rs
- 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.

@Rhuagh

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

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.

@Rhuagh

Rhuagh Oct 26, 2017

Member

Matrix3::from_diagonal(self.scale)

@Rhuagh

Rhuagh Oct 26, 2017

Member

Matrix3::from_diagonal(self.scale)

- 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.

@Rhuagh

Rhuagh Oct 26, 2017

Member

Vector3::zero(), Quaternion::one(), Vector3::from_value(1.)

@Rhuagh

Rhuagh Oct 26, 2017

Member

Vector3::zero(), Quaternion::one(), Vector3::from_value(1.)

amethyst_core/src/transform/systems.rs
- 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.

@Rhuagh

Rhuagh Oct 26, 2017

Member

Quaternion::one()

@Rhuagh

Rhuagh Oct 26, 2017

Member

Quaternion::one()

examples/03_renderable/main.rs
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.

@Rhuagh

Rhuagh Oct 26, 2017

Member

.rotate_vector(transform.translation)

@Rhuagh

Rhuagh Oct 26, 2017

Member

.rotate_vector(transform.translation)

examples/05_assets/main.rs
- 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.

@Rhuagh

Rhuagh Oct 26, 2017

Member

in theory, Vector3::from_value(2.), but not necessary.

@Rhuagh

Rhuagh Oct 26, 2017

Member

in theory, Vector3::from_value(2.), but not necessary.

@Xaeroxe

This comment has been minimized.

Show comment
Hide comment
@Xaeroxe

Xaeroxe Oct 26, 2017

Member

Rebased and addressed @Rhuagh

Member

Xaeroxe commented Oct 26, 2017

Rebased and addressed @Rhuagh

@Rhuagh

Rhuagh approved these changes Oct 26, 2017

@Xaeroxe

This comment has been minimized.

Show comment
Hide comment
@Xaeroxe

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.

Member

Xaeroxe commented Oct 26, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@torkleyy

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.

Member

torkleyy commented Oct 27, 2017

I couldn't spot any logical issues, it's just the implied strategy regarding our math API that I'm not so sure about.

@Xaeroxe

This comment has been minimized.

Show comment
Hide comment
@Xaeroxe

Xaeroxe Oct 27, 2017

Member

@torkleyy care to elaborate?

Member

Xaeroxe commented Oct 27, 2017

@torkleyy care to elaborate?

@torkleyy

This comment has been minimized.

Show comment
Hide comment
@torkleyy

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..

Member

torkleyy commented Oct 27, 2017

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

..take this as my approval together with the note that at least two other members should approve this before we proceed.

@torkleyy

This comment has been minimized.

Show comment
Hide comment
@torkleyy

torkleyy Oct 27, 2017

Member

This is the only way we can make progress.

Member

torkleyy commented Oct 27, 2017

This is the only way we can make progress.

@Xaeroxe

This comment has been minimized.

Show comment
Hide comment
Member

Xaeroxe commented Oct 27, 2017

r? @Aceeri

@torkleyy torkleyy referenced this pull request Oct 28, 2017

Closed

Plan for 0.6 release #249

@Xaeroxe

This comment has been minimized.

Show comment
Hide comment
@Xaeroxe

Xaeroxe Oct 28, 2017

Member

bors r+

Member

Xaeroxe commented Oct 28, 2017

bors r+

bors bot added a commit that referenced this pull request 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
@torkleyy

This comment has been minimized.

Show comment
Hide comment
@torkleyy

torkleyy Oct 28, 2017

Member

So why don't we let @Aceeri approve this?

Member

torkleyy commented Oct 28, 2017

So why don't we let @Aceeri approve this?

@torkleyy

This comment has been minimized.

Show comment
Hide comment
@torkleyy

torkleyy Oct 28, 2017

Member

bors r-

Member

torkleyy commented Oct 28, 2017

bors r-

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors bot Oct 28, 2017

Contributor

Canceled

Contributor

bors bot commented Oct 28, 2017

Canceled

@torkleyy

This comment has been minimized.

Show comment
Hide comment
@torkleyy

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+

Member

torkleyy commented Oct 28, 2017

Doesn't seem like @Aceeri is going to review this in the near future, so I have to merge this now.

bors r+

bors bot added a commit that referenced this pull request 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

This comment has been minimized.

Show comment
Hide comment

@bors bors bot merged commit 2602e43 into amethyst:develop Oct 28, 2017

3 checks passed

bors Build succeeded
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

@Xaeroxe Xaeroxe deleted the Xaeroxe:cgmath branch Oct 28, 2017

@Aceeri Aceeri added this to the 0.6.0 milestone Nov 28, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment