4 ms·
Matrix math is just a standardized, regularized way of doing a whole hell of a lot of multiplication and addition en mass. Disassociation is arguably the goal:
by MaulingMonkey 5y ago
Matrix math is just a standardized, regularized way of doing a whole hell of a lot of multiplication and addition en mass. Disassociation is arguably the goal: instead of remembering to add this, but multiply that, but divide this other thing, and subtract that... you just take the dot product of every row of the left matrix vs every column of the right matrix. Is is procedural math... if you optimize for simplicity of procedure.
Optimizing for simplicity of procedure can make computers quite happy, and reduce errors by humans (they can still make arithmetic errors, but will make fewer errors of procedure)... and also lets you build reusable optimizations to that simple procedure (math theory about matricies) that can then be shared across multiple domains (a lot of work has been put into optimizing e.g. sparse matricies.)
Figuring out an intuitive understanding of matrix values can be done, although it depends on the problem domain you're applying them to. My problem domain of choice is computer graphics. Rotating a vertex of a triangle can be done using a 3x3 matrix:
[ ux_x, ux_y, ux_z ]
[v_x, v_y, v_z] [ uy_x, uy_y, uy_z ] = [o_x, o_y, o_z]
[ uz_x, uz_y, uz_z ]
v_{...} is an input vertex position
o_{...} is an output vertex position
Can this be visualized? Yes!
ux_{...} is where a unit x vector (1,0,0) will end up at
uy_{...} is where a unit y vector (0,1,0) will end up at
uz_{...} is where a unit z vector (0,0,1) will end up at
What if I want to add an offset/position to all the verticies? Well, we don't want the multiplication bits then, so we need a 1 to have a noop multiply:
[v_x, v_y, v_z, 1.0]
And then we can use that 1.0 to add a new row to our matrix which will get added to the final output:
[ ux_x, ux_y, ux_z ]
[ uy_x, uy_y, uy_z ]
[ uz_x, uz_y, uz_z ]
[ t_x, t_y, t_z ]
Bam, we added [t_x, t_y, t_z] to [o_x, o_y, o_z]. t_{...} is then easily visualized as the new position where verticies were at the origin (0,0,0) will end up at, and u{...} becomes the position of the unit vectors relative to that origin, instead of in absolute coordinates.
EDIT: Adding a 4th column becomes useful for projection matricies in a way I don't have a super great intuition for... but it also lets us multiply transformation matricies together. This is quite useful: We can simplify "transform this vertex from the original mesh, into it's position relative to this larger model, into it's position in worldspace, into it's position relative to this camera" to "multiply against this single 4x4 matrix that we constructed using matrix multiplication."