Conceptualising a 3x3 (with houdini)

Posted 27 February, 2013 Anthony Tan (staring at yet another render. But still loving it for some reason..)

« previous | next »

tags: matrix

Something I worked on just by way of demonstration in an FXPHD class forum (HOU206 with the awesome @Nick_Nimble) on matrices, thought I'd repost it here since it works nicely as general information.

Specifically, we're working here with a 3x3 rotation matrix, and I'm trying to give a better feel for how a 3x3 can be built up to describe rotations/scales/skews and the encapsulation of the information.

Things you need (want)

I'll add in images, but it's going to be a LOT easier if you have houdini to access the .hip file. Also, something of note - we're using row-oriented vectors. Not column vectors. If that meant nothing to you, no problem. If it did, that should stop you from wondering why the frick certain things look transposed. Now, onto the semi-verbatim quotes.

One handy way to look at a 3x3...

... is to see it in essence as a pack containing three vectors that describe the nature of a 3D space (basically - the axes^) and that it's a supermagicallyhandy way to describe how to convert your current X/Y/Z axes into a new set of axes (or more formally, transform your current space into a new space).

You're effectively defining a 'new' rendition of 3D space, so when you apply the matrix (i.e. multiply it), you're moving all the points from the old 3D space, to your new 3D space, but keeping their relative positions the same.

here's the hipfile: 20kb. Huuuuge.

(this is where it gets a but Houdini-ish, screenies in for those of you who just want to read, but it's really more for play rather than offline image viewing)


If you look at the no_change SOP, you'll see I've labelled out row U, V, W and origin and set them accordingly. If this starts looking like an identity matrix, then you're dead set right, since it does nothing to the input. First thing to try here would be to change row U to 2,0,0. Note how the X axis has now stretched, along with the cube? That's because we've just said that in our new 3D space, the X axis is 2 units long, so an object coming from the old 3D space where X was only one unit long needs to be stretched out so that all the points stay at the same relative position to each other. Have a play with the other rows, and you'll see the same characteristic. Hold off on changing any of the zeros for a mo though.


Just for completeness, have a play with the translate one now. I've set the new axes to be scaled by 1x, 2x, 3x for the hell of it, and you can change any of the origin values and watch it slide around. What we're doing here is defining the new (0,0,0) position of your 3D space. Logically, if a point was at 0,0,0 in the old space, and our new 3D space has an origin at 2,3,4, all our points should be shifted by that amount


Righto, time for some more fun. Have a look at skew. In this case, I've made the new X axis no longer at right angles to the other two, and have rotated it around Z by 45 degrees. If you play with the values in Row U (or any other row for that matter) you'll find that the positions of points 1, 2, and 3 always match (or match with an offset if you apply a change to the origin).

..and Rotate

Rotates are a pain but I've just done up a formula keyed to $F so it spins around on the Y axis for effect. Don't worry about where those automagic formulae come from (if curious:, but hopefully you're seeing how rotations work - like transforms, they keep all the points aligned relative to each other in exactly the same way, but as a group they point in a different direction... but again, once you get down to it, all you're doing is defining where your X and Z axes are in the new 3D space.

Finally, if you look at the half_the_rotate SOP, I've frozen the third row, and if you scrub the timeline you'll see that it's skewing your cube, just to reinforce the idea that you get skew when you mangle your axes relationship to each other, rotation requires you preserve the axes' relationship. Skew requires you to break em. (and scale requires you to keep them, but change the lengths..)

In conclusion..

So yes, this is one way to visualize how your vectors are containing rotation information, and also skew, translate and scale information. Hopefully that sorta helps? If i can handwave/explain/clear stuff up more, yell. Or if it's confusing - yell at me - after writing this I've noticed I've slipped between one or two different terminologies, but i don't think it'll be too bad..

Transferring information (like colour) between particles
Nuke LDPK node upgrades to v1.7
tags: matrix
^axes is the correct plural of axis. Really.