Add support for matrix inverses about handmademath HOT 15 CLOSED

Typically unproject would do a special-case inverse operation without requiring a full matrix inversion to go from screen to view space (camera space). Then a transformation inversion can be done to calculate the camera to world operation. From here there is the option of performing world space computation, or doing an inverse transform operation into model space.

Generally full matrix inversions are avoided in favor of simpler and more run-time efficient transformation inversion. Typically rotation + translation and uniform scale are easily invertible, and non-uniform scaling inversions (as well as perspective inversions) are simply avoided.

So I'd recommend:

• efficient and simple transform inversion (uniform scale, rotation, scaling)
• screen to view (camera) helper
• calc inverse cam matrix helper
• don't even support general matrix inversions. so no skews, non uniform scaling, or other weird stuff

I've implemented these here, feel free to use them as reference:
https://github.com/RandyGaul/tinyheaders/blob/master/tinymath.h#L626-L645
https://github.com/RandyGaul/tinyheaders/blob/master/tinymath.h#L553-L605

It's possible to get away with ray from screen to world space without writing a single general-purpose matrix inversion function (not even the optimized transform inversion).

from handmademath.

The above offers no detail on implementation, so I'll go ahead and offer some suggestions, this may already be what you guys have in mind.

There are many different ways to compute the inverse of a homogenous 4x4 matrix, depending on the properties of the matrix. Generally, the more constraints the matrix is under, the easier it is to compute the inverse.

In this case, "easiness" actually implies speed of computation.

So my suggestion would be to expose a number of different ways to compute the inverse, depending on the type of matrix, e.g.:

OrtonormalInverse (only rotation and translation)
OrthogonalInverse (+ scale)
AffineInverse (+ skew)
ProjectionInverse -- or maybe even PerspectiveProjectionInverse and OrthogonalProjectionInverse
GeneralInverse

I think this level of exposure is fine. If you're trying to use matrix inverse, you should understand the differences between the above.

Also, the general 4x4 inverse does not seem very useful for the problems HMM is trying to solve. I would recommend skipping it, as it is generally hard to do right (and will bloat the code base). Solving systems of 4 equations with 4 unknowns is IMO not very related to the geometry of game programming.

from handmademath.

Done in HMM 2.0 - finally!

from handmademath.

@RandyGaul what are the names of the functions that you were linking? It seems the line numbers went out of sync, and the lib rename seems to have clobbered the history

from handmademath.

Yeah i've always thought our handling of matrices was pretty weak. I think this it would be a great idea to beef them up completely. Now would be a good time to plan on how we want to go about that, since right now im currently trying SSE a lot of our vector math so we dont have to depend on whatever compiler that handmade math is running on to do it for us.

from handmademath.

If we want to make it really robust, I think we should add mat2 and mat3 with all the same features as mat4. It shouldn't be too difficult to do, but I think we should sort out the static/inline/extern thing before we add a gazillion more functions.

Then I figure we can also add Determinant and Inverse for mat2, mat3, and mat4.

from handmademath.

Yeah that plan sounds great honestly. We really do need to figure out the static/inline/extern thing its been put off for a long time now.

from handmademath.

Comment from the Handmade network:

Glad to hear you are looking to support matrix inverses. Currently working with 3D picking and this would be extremely helpful. And since this is a game realated math library a unproject function would be icing on the cake :)

from handmademath.

Comment from the Handmade network:

Just wanted to add a few more details here. So for my project I have been trying to get 3D picking or ray casting from 2D screen coords to 3D world coords working. Almost all of the information available use some type of matrix inverse or unproject function.

Some of the commonly used are from the glm library.
Inverse and Unproject

As for the comments above I am not sure which would be the best way to implement any of these but they seem to be pretty common in 3D games.

from handmademath.

Thanks for the detailed reply. I've actually read several of your blogs but never looked at your math lib because I am compiling with c. However the functions you referenced look pretty easy to convert/learn from, time to study them a little bit.

from handmademath.

@kavika13 oh sorry! I only just now saw your question. And yes I did break my links. Here’s one I promise not to break again.

https://github.com/RandyGaul/cute_headers/blob/master/cute_math.h

The function in question was compute_mouse_ray. There is also a look_at function to compute a camera matrix and its inverse.

from handmademath.

Hello everyone, any improvement on this subject ?
Thank you :)

from handmademath.

@JorenJoestar We more or less concluded inverses are not needed for games for the most part. What specifically are you looking for/trying to do?

from handmademath.

Different things:

1. transform normals. Normally you do the inverse transpose of the world transform of a model, and pass that to the vertex program that uses it.
   Faster than doing that for each vertex of a model inside a shader.
2. Reconstruct world position from depth: multiply homogeneous coordinates for the inverse of the view projection.
3. Any transformation from screen space to world or view space (like for object picking).

I was just hoping to have support for inverse and transpose in the library :)

from handmademath.

Ah, nice list. Though it's not necessary to use a full inverse function, at least, as far as I am aware (I might be wrong though!).

1. As long as it's not a wild matrix with non-uniform scales mixed in, it can be trivially decomposed into translation, scale and rotation. Each individual piece can be trivially inverted, and then pieced back together again as a full matrix.
2. Project screen-space point onto the near-plane, then push it out to your sampled depth along the ray from camera center to the projected point. I gave an example of screen-space to projection plane function somewhere in this thread.
3. Almost the same thing as 2.

HMM_Transpose already exists :)

When computing a world to camera transform, it's also possible to simultaneously compute the inverse without using an explicit inverse function. I also linked to an example of this earlier in this thread.

from handmademath.