More control of Matrix indeces with matrix()

ID:1376932
 
Sep 14 2013, 4:28 pm
Applies to:Dream Maker
Status: Open
Issue hasn't been assigned a status value.
I was attempting to use the math provided here: http://en.wikipedia.org/wiki/Isometric_projection to test some things.

I was suprised to find that you can only modify the first 6 of the 9 indexes available in a matrix through the use of the matrix() proc.

If possible it would be much appreciated if we had "a" through "i" for the matrix variables as well as being able to use a list of 9 values for a transform.

It would also be helpful if you could display the list of indexes in a transform so that they may be logged and use later as a list rather than requiring to create and apply the matrix each time. For example: If there's a matrix that is the result of several matrix procedures it would be helpful to be able to log the values so that they may be used in other environments rather than having to recreate the matrix via the procedures.

The reason behind all this: It's much easier to create and re-use very complicated matrixes by writing them out from scratch rather than use the built in procs to create them.

If I wished to rotate, scale, translate, etc. (multiple steps) an atoms transform variable it'd be much easier to create a matrix and then apply it once instead of using multiple procedures to build the matrix necessary for it.
Sep 14 2013, 5:15 pm
You can access the first six entries in a matrix and log them, then recreate the matrix manually. If you want to store the values of a matrix, you can, you just have to do it yourself.

var/matrix/M = matrix()
var/list/L = list()
M.Scale(2)
L.Add(M.a,M.b,M.c,M.d,M.e,M.f)
var/matrix/built = matrix(L[1],L[2],L[3],L[4],L[5],L[6])
Sep 14 2013, 6:56 pm
The issue is that there are 9 indexes in a matrix, but we can currently only directly assign 6 of those 9, taking away an entire third of the control over a matrix.


As well, after doing multiple matrix procedures, there's currently no way to retrieve the values of the separate indexes. For example, if I have a matrix and I scale it, then rotate it, there's currently no way for me to get the values of the indexes afterward in order to cut down the process of making these changes.
Sep 14 2013, 7:14 pm
In response to Bravo1
Bravo1 wrote:
As well, after doing multiple matrix procedures, there's currently no way to retrieve the values of the separate indexes.

Those would be matrix.a through f?
Sep 14 2013, 7:21 pm
In response to Kaiochao
Kaiochao wrote:
Bravo1 wrote:
As well, after doing multiple matrix procedures, there's currently no way to retrieve the values of the separate indexes.

Those would be matrix.a through f?

I just realized you could directly read those variables. All right, that works then.


I would still like access to Indexes G, H, and I
Sep 15 2013, 8:08 am (Edited on Sep 15 2013, 8:26 am)
In response to Bravo1
Bravo1 wrote:
I would still like access to Indexes G, H, and I

Keep in mind that they may not exist, as for most transforms the right side is typically just 0, 0, and 1. It's not uncommon to make a matrix 3x2 and just cut them out:

a d 0
b e 0
c f 1

<edit>
Got the indices wrong, doh!
Sep 15 2013, 8:15 am
Indices G,H, and I are just identity values, so you couldn't meaningfully use them if you wanted to anyway.

Without a full 4x4 matrix implementation, you only need 2x3 to perform 2D transformations.
Sep 15 2013, 10:38 am
So if I were to do a complicated set of matrix procs, G H and I are still going to be 0,0,1?
Sep 15 2013, 10:45 am (Edited on Sep 15 2013, 10:50 am)
They won't return any meaningful context to you for your environment. In order to use a 3x3 matrix, you have to have a 3-dimensional environment, which would require a 4x4 matrix to operate on. At least, as far as I understand.

A 2D environment only requires a 2x3 matrix to store transformations, but it requires a 3x3 matrix to operate on them.

The only valuable data in the 3x3 matrix in the context of a 2D coordinate plane, is in the 2x3 subset.

Likewise, a 3D game requires 3x3 matrices, and thus requires a higher order of dimensionality in order to operate homogeneously. Once you expand it to 3x4, it still isn't homogenous, thus requires a 4x4 matrix.
Sep 15 2013, 10:47 am (Edited on Sep 15 2013, 10:54 am)
http://stackoverflow.com/questions/10698962/ why-do-2d-transformations-need-3x3-matrices

Admittedly, it'd be nice to have a complete OpenGL rewrite of BYOND, which would allow us to implement 4x4 matrices so we could so things with the actual quads in the rendering pipeline, but it really is overkill.

The new matrices allow for some really cool things like lighting-fast wall-casting in a first-person game, but they don't allow you to do the floor. It would take either a direct-surface blitting library to handle the floor, or some means of 3D cheating the floor in using 4x4 matrices to manipulate the perspective of the image quad.

But that's unlikely to happen, so I'm quite happy with what we have right now.
Sep 15 2013, 11:58 am
DirectX supports 4x4 matrices as well; the problem is when GDI comes into play, as PlgBlt() only supports 2D affine transforms. However since there is no meaningful perspective, I'm not sure even DirectX's matrix would make a difference; we're using an orthogonal projection, whereas Z would only have relevance when perspective projection is used.
Sep 15 2013, 12:04 pm
...And there I go forgetting the root projection matrix, and the end effect it would have. =/ Touche, sir.