In this blog, I will keep track of the updates of this site. If you are interested, just subscribe to the RSS feed.
|Inverse Transform without matrices?|
Sat, 23 Mar 2019 22:27:57 +0000
Given an affine transform, expressed as a translation (or position), a scale, and a rotation, how do you compute its inverse?
Well, if you write the transform as a matrix (for column vectors, so the first operation is at the right hand side),
M = T * R * Sthen the inverse is (I'm using a single quote instead of -1 to write the inverse),
M' = (T * R * S)' = S' * R' * T'Can we write that as another affine transform? That is,
M' = S' * R' * T' = T_ * R_ * S_Well, a person from the future wrote in math.stackexchange how to extract the translation, the scale, and the rotation of a given affine transform.
So far, so good. But if you look at the comments, someone comments that the extracted rotation matrix might be a combination of shear and rotation!
This might be a trivial problem, but I never encountered it before. The issue is that, if the scaling is anisotropic, then there's certainly shearing going on in the inverse. That is, you can extract T, R, and S from M using what's described in math.stackexchange, but you can't extract T_, R_, and S_.
What can we do, then?
Well, the translation can still be computed the same. If t is the position in the original transform, then the new position is,
t_ = S' * R' * (-t)and we don't have to use the matrix forms for this. If your rotation is a quaternion, simply invert the quaternion and rotate t with it. Then, divide each component by the scale.
But can we convert (S' * R') into (R_ * S_)? Well, we can use the Singular Value Decomposition to see how it would look like,
S' * R' = U * Σ * V'Σ is a diagonal matrix, so a scaling matrix. But unless V is the identity, I don't see how this would look like an (R_ * S_)
So in the end I bit the bullet and used matrices when I need the inverse and I know the scaling may not be isotropic...
What was I trying to do? I was computing ray to object intersections in an AR sample app. These are computed in the CPU, and it would be costly to transform all the triangles of the object to test the intersection, so I'm converting the ray to model space instead. That's why I needed the inverse of the world transform of the object. You can see the final commit with the bug fix and several unit tests that exercise the different conversions: Fix transform.inverse (VidEngine)
Please message me in twitter @endavid if you have any comments or suggestions!
|Cleaning up my Mac drive|
Fri, 25 Jan 2019 21:43:15 +0000
We accumulate lots of crap in our hard drives. Even more than in our homes, because the "crap" is not usually visible, so we keep storing and storing. Space is not much of a problem... or is it?
It turns out it is a problem for me. Every now and then I get warnings that I'm running out of space and I have to do some clean up. But because I only do this every so often, I always end up spending some time Googling about mysterious big system files, to check whether or not it is OK to delete these.
So I thought I could write a small guide for myself that I can come back to next year. Some parts of it may be useful to others, but some are dev-oriented.
But first, how much space do we have left? You can right-click on the hard-disk icon in any Finder window and click Get Info,
Or from the console, just type,
df -h Filesystem Size Used Avail Capacity Mounted on /dev/disk1s1 234Gi 223Gi 6.7Gi 98% /
Then, if you have no idea where to start, use a tool like GrandPerspective to get a visual overview of the biggest offenders. Here's my hard drive right now,
Big blocks are big files. You can hover over the blocks to find their location in disk. The blocks are also grouped. So you can see all the big blocks on the top left belong to the same folder. To see more details, I just go to that folder in the terminal and type du -h. In this case, that folder is the iOS DeviceSupport folder and is taking 42GB.
So let me start my check list of usual suspects.
A bit of Marie Kondo
While we are at it, we could do some "marikondoning" on our drive. Is that 300MB PDF from 2001 still useful? Do you really want to move it to an external drive? Wouldn't it be better to just delete it completely and reduce entropy? Are you ever gonna come back to it? Have you EVER read it? Do you smile when opening that file? Burn it if not!
There are a quatrillion million small files that won't catch our attention in GrandPerspective because they are small. But they clutter our disk. It takes too much time to sort them once it's become like this. So you could move all the crap to a folder called "unsorted", for instance. That's what I do with the things in my Desktop, to keep it always tidy. Then, just rely on Spotlight to search and find them. But for important things, make sure to keep them tidy in folders with relevant names (e.g. Documents/bills).
And that's my 5-cents! I hope it's useful for others as well.