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.
[ Parent
| on HN ]
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
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.
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).