ID:2209937
 
Applies to:DM Language
Status: Open

Issue hasn't been assigned a status value.
Make non affine transformations where you can use a list in the transform like this:

transform = list(x1,y1,x2,y2,x3,y3,x4,y4)


Where the points are top right, top left, bottom left, then bottom right.
Let me do the math for this real quick

For affine transform with matrix() the math looks like this:

x' = ax + by + c
y' = dx + ey + f

For non affine it looks like this

x' = x3 + xx4 - xx3 + yx2 + yxx1 - yxx2 - yx3 - yxx4 + yxx3
y' = y3 + xy4 - xy3 + yy2 + yxy1 - yxy2 - yy3 - yxy4 + yxy3
Seems to me like if non-affine transforms were supported, the better option would be to go with a 3D matrix. Then it'd have the benefit of still allowing for easy handling of rotation, etc.
In that case add another 2 vars to matrix.

Add an xy row to the matrix that is multiplied by x*y
An xy term would make the formula non-linear.

Really what I mean is, I don't see any value in leaving the matrix paradigm. Matrices are used for transforms just about everywhere, even directly in the drawing code. Providing four values for the corners would simply mean the engine would have to do the work of turning that into a 3D matrix.

Matrices can be broken down into components, and they can be multiplied together to chain transforms. So they're the right tool for this job.
I'm not sure I see how a 3d matrix would work.

The way 3d matrices work in OpenGL and DirectX is that you have 4 inputs: x, y, z, and w. X/Y/Z is what you'd expect, and W is 1 if it's a position and 0 if it's a vector.

The outputs of the matrix are x, y, z, w, but w is a divisor, so x and y get divided by w, and z is used for the depth buffer.

So either way no matter what you do your equations are not going to be linear. And then you have the additional problem of having to specify a z for each of the vertices.
The matrix operation itself is still linear algebra. Any division that happens is done internally by the GPU to convert x,y,z coords into x,y for display purposes.
Fair enough, that'll work then.
Will the native hardware support for 3d matrices be used or something for this though?
As an aside, the technical term for the type of transformation you're talking about is a projective transformation.
Hmmmmmm....



So this is possible then.