Transform Refactor Discussion

(Kel) #1

Recently @jojolepro has put work into Transform separation which can be found in a branch here: https://github.com/jojolepro/amethyst/tree/transform

This is definitely exciting, especially considering the implications that 2d transforms utilizing a fixed point number type could have in helping to solve pixel-perfect rendering problems as well as the possibility of fixed point and f64 in storing information about dynamics systems, that are already always so hungry for any edge in satisfying different sorts of accuracies.

Considering that adding the Real type parameter to 3d transforms, along with adding the dimension suffix to their name to delineate the difference in dimensional spaces are already breaking API changes in core, I believe this would be a good time for another big api change in this space, in writing Transform{2,3]'s as LocalTransform{2,3}'s, and possibly also renaming GlobalTransform's similarly to simply be Transform, such as to emphasize that local transformations are “intermediate” values requiring their TransformBundle to be computed into GlobalTransform's which are to be considered the “actual” value.

This is an extremely important distinction that should be made more obvious in the API. Changes to GlobalTransform on entities with Transform's will currently have those changes overwritten by TransformBundle and there’s no way to know this by looking at the types of these fundamental components (or at their documentation, but that can be addressed independently. I’ve also been thinking up ways to improve explanation of Amethyst’s structure and hopefully I can write those into forum posts/documentation at some point)

0 Likes

(Kel) #2

In Summary:

Currently

  • GlobalTransform - 3d and 2d world transformation matrix
  • Transform - 3d and 2d local transformation

In Refactor

  • GlobalTransform3<N: Real> - 3d world transformation matrix
  • GlobalTransform2<N: Real> - 2d world transformation matrix
  • Transform3<N: Real> - 3d local transformation
  • Transform2<N: Real> - 2d local transformation

Proposed - same as above except

  • Transform3<N> -> LocalTransform3<N>
  • Transform2<N> -> LocalTransform2<N>
    with possibly (but less importantly) also
  • GlobalTransform3<N> -> Transform3<N>
  • GlobalTransform2<N> -> Transform2<N>
    although I’m less sure about the latter.
0 Likes

(Théo Degioanni) #3

I don’t think making the change back to LocalTransform is the bets approach. Besides the fact that it is longer, GlobalTransform are more of an implementation detail than something most users will actively use. It’s better to simplify away the concept, I’m pretty sure you can make a lot of games without even knowing about GlobalTransform.

0 Likes

(Joël Lupien) #4

@Moxinilian

That’s the idea behind rhuagh’s automatic initialization of GlobalTransform.

I want it to stay the same way. The only reason a user would want access to GlobalTransform would be to get the global world pos/rot/scale/layer/dimension of an entity (and possibly apply transformation using those values)

0 Likes

(Joël Lupien) #5

Also I prefer the way it is currently
Transform: local
GlobalTransform: global

It was the other way around before, and was causing a ton of issues and confusion.

0 Likes

(Théo Degioanni) #6

I was replying to the name changes so I think we agree.

0 Likes

(Kel) #7

Ah interesting. I didn’t know that it was like this previously! Well that makes sense then. I think this is more of a documentation story to improve then.

0 Likes

[Help Request] Transform Refactor