News for hackers. Stuff that matters.
Re:Don’t invert that matrix (2010) by rcxdude on Thursday May 12, 2016 @03:50PM (#11686214)
More talking about applications where the matrices are large, like statistics, machine learning (but I repeat myself), signal processing, etc. In games pretty much all matrices are around 4x4, instead of millions by millions.
Re:Don’t invert that matrix (2010) by theoh on Thursday May 12, 2016 @04:37PM (#11686591)
There's an neat technique for fitting RBF representations to dense point clouds. Instead of the impractical matrix inversion, the trick is to solve the linear system with a fast multipole method, similar to the Barnes-Hut algorithm for the n-body problem.

Carr, J.C. et al, "Reconstruction and Representation of 3D Objects with Radial Basis Functions", Siggraph 2001

http://dl.acm.org/citation.cfm?id=383266

Re:Don’t invert that matrix (2010) by majewsky on Friday May 13, 2016 @02:54AM (#11689024)
Another relevant difference is that precision is not nearly as critical in games as in most numerical applications. Errors of a few percent will likely go unnoticed. Graphics implementations therefore usually only use single precision.
Re:Don’t invert that matrix (2010) by vvanders on Thursday May 12, 2016 @03:59PM (#11686290)
Ah, that's the context I was missing, thanks!

In games we can usually just transpose the inner 3x3 R+S, invert scale and handle translation similarly to get a semi-quick inverse.

Re:Don’t invert that matrix (2010) by GFK_of_xmaspast on Thursday May 12, 2016 @04:10PM (#11686367)
This is the difference between matrices that are SO(3) (which have trivial inverses) and matrices that are just GL(n) (which: don't).
Re:Don’t invert that matrix (2010) by Hydraulix989 on Thursday May 12, 2016 @08:49PM (#11687876)
This. Or you know how to calculate the closed-form inverse a priori like with projection matrices (e.g. gluUnProject).