Jump to content
  • Advertisement
Sign in to follow this  
devronious

Calculate the inverse matrix...

This topic is 4237 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Advertisement
Quote:
Original post by devronious
How do I calculate the inverse matrix of a typical 4x4 directx matrix?
Well, DirectX should have a function for this, I imagine. If you want to do it yourself, there's plenty of info on 4x4 matrix inversion available online.

Of course anytime matrix inversion comes up it must be mentioned that there are shortcuts for inverting certain types of transformations, and that sometimes you can avoid performing the inversion altogether.

If you need more info, perhaps you could tell us what sort of matrix you need to invert, and why you can't just use the DirectX matrix inversion function (if that is in fact the case).

Share this post


Link to post
Share on other sites
Thanks, Yes I need to do the inversion myself and it is necessary.

for the 3x3 rotation portion of the 4x4 matrix I can simply transpose it. But for the translation or perspective portions I am confused.

matrix is in the form

rxx rxy rxz px
ryx ryy ryz py
rzx rzy rzz pz
tx ty tz 1

The matrix is in the same form of the Microsoft.DirectX.Matrix structure.

I searched the net and had trouble finding something that was at my level of understanding.

-Devin

Share this post


Link to post
Share on other sites
Although again there are shortcuts for inverting certain types of transformation matrices, I would start by implementing a generic 4x4 inversion function, since it will work for any type of (invertable) transform.

I'm sure if you google '4x4 matrix inverse' you'll find example code that you can adapt to your needs. As for level of understanding, if you find yourself stuck on something (such as how to adapt a specific implementation, or understanding the algorithms being applied), you can always get help here.

Share this post


Link to post
Share on other sites
This is the standard inversion formula for a homogeneous transformation (with a new improved white background):



That should also clear up any confusion over how you obtain the new translation. I would also recommend you use a special-case inversion for the perspective matrix, since it's mostly 0's and you'd be wasting a ton of computation using general inversion. When I'm in the lab later today I'll see if I can't whip up the formula for the inverse transform.

For a matrix that isn't in any particular form then you would have to use a general inversion method, which have been discussed.

Share this post


Link to post
Share on other sites
Quote:
Original post by Zipster
This is the standard inversion formula for a homogeneous transformation

BTW: If you want to know if a matrix has the appropriate form for Zipster's equation, check whether the dot products of the first and second columns, and the first and third columns, are both zero, and the magnitudes of each of the first three columns are all 1. (And, of course, that the fourth row holds 0 0 0 1.)

Share this post


Link to post
Share on other sites
Quote:
Original post by Zipster
This is the standard inversion formula for a homogeneous transformation (with a new improved white background):

Hehe...crystal clear on both the 'standard' and 'classic black' themes :-)
Quote:
I would also recommend you use a special-case inversion for the perspective matrix, since it's mostly 0's and you'd be wasting a ton of computation using general inversion. When I'm in the lab later today I'll see if I can't whip up the formula for the inverse transform.
For what it's worth, I've worked out the special-case inversions for both OpenGL- and D3D-style perspective and orthographic projection matrices and could post them for the OP if he likes (if Zipster doesn't beat me to it).

@Zipster: Do you really think it's worth the trouble though? Under normal circumstances you'd only ever be inverting a projection matrix at most once per frame, and more likely only once, period (barring zoom effects or what have you). I would think the performance gain offered by the special-case functions would be negligible, and would come at the cost of additional code that has to be written and debugged.
Quote:
Original post by Sneftel
BTW: If you want to know if a matrix has the appropriate form for Zipster's equation, check whether the dot products of the first and second columns, and the first and third columns, are both zero, and the magnitudes of each of the first three columns are all 1. (And, of course, that the fourth row holds 0 0 0 1.)
A note to the OP: In practice, the above test would need to be performed with appropriate threshold values, as even with an orthonormal basis the results of the computations will almost certainly not be exactly 0 and 1, respectively, due to floating-point error. Also, choosing an appropriate threshold could be a bit tricky, depending on the circumstances.

In most cases though you should know a priori what transformations are represented by the matrix, in which case no such tests are necessary.

Share this post


Link to post
Share on other sites
Quote:
Original post by jyk
@Zipster: Do you really think it's worth the trouble though? Under normal circumstances you'd only ever be inverting a projection matrix at most once per frame, and more likely only once, period (barring zoom effects or what have you). I would think the performance gain offered by the special-case functions would be negligible, and would come at the cost of additional code that has to be written and debugged.

True, but I would think it's not very likely you're going to need general-purpose inversion if you're only working with traditional homogeneous and perspective transformation matrices. Gauss-Jordan can also be a tricky process to implement, trickier than any special-case inversion, especially if you're not familiar with how it works and have to include partial pivoting, etc. And if you already have inversion handled for the rotation/translation/scaling1 transformations, you might as well just do the same for perspective inversion. That's just my opinion though, and to be honest it probably wouldn't be a bad idea to have a general-purpose inversion method implemented for when you're just solving any arbitrary system. But if you're only working with matrices that are of only a handful of known forms, and each one has an inversion process that's faster than general inversion, I don't see any reason against implementing all of them. Of course a "handful" would probably be around 3 forms, since you still have to weigh the benefit of increased performance against the cost of increased coding/debugging, relative to how often you actually use each method.

1Non-uniform scaling requires a slightly more generalized inversion process that wasn't covered.

Share this post


Link to post
Share on other sites
Quote:
Original post by Zipster
Quote:
Original post by jyk
@Zipster: Do you really think it's worth the trouble though? Under normal circumstances you'd only ever be inverting a projection matrix at most once per frame, and more likely only once, period (barring zoom effects or what have you). I would think the performance gain offered by the special-case functions would be negligible, and would come at the cost of additional code that has to be written and debugged.

True, but I would think it's not very likely you're going to need general-purpose inversion if you're only working with traditional homogeneous and perspective transformation matrices. Gauss-Jordan can also be a tricky process to implement, trickier than any special-case inversion, especially if you're not familiar with how it works and have to include partial pivoting, etc. And if you already have inversion handled for the rotation/translation/scaling1 transformations, you might as well just do the same for perspective inversion. That's just my opinion though, and to be honest it probably wouldn't be a bad idea to have a general-purpose inversion method implemented for when you're just solving any arbitrary system. But if you're only working with matrices that are of only a handful of known forms, and each one has an inversion process that's faster than general inversion, I don't see any reason against implementing all of them. Of course a "handful" would probably be around 3 forms, since you still have to weigh the benefit of increased performance against the cost of increased coding/debugging, relative to how often you actually use each method.
Fair enough :) I suppose it's 6 of one, 1/2 dozen of the other, more or less.

I will say though that 'trickiness of implementation' shouldn't be much of an issue, I don't think. Inversion of a 4x4 matrix via Cramer's Rule or Gauss-Jordan is well documented, more so even than the various special cases under consideration (although admittedly anyone with a decent understanding of linear algebra should be able to figure these out themselves).

With Cramer's Rule in particular, the only thing that's at all tricky, IMO, is the bookkeeping (i.e. getting all the matrix/array indices right for the various sub-determinants). However, there are plenty of examples available to check one's work against.

In the end it's probably just a matter of preference - at least the OP is getting some different perspectives on the issue :-)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!