So, as should be apparent from my last two posts, I’m switching over the front end of my research system to use the Qt GUI framework.  Naturally, since I’m trying out a new platform here, I want to post a simple way to get a triangle up on the screen as quickly as possible.

You can see my previous post for suggestions on how to get Qt set up on a mac, but since the toolkit is so widely used it should be very straightforward to set it up on windows and linux as well.

#include <QApplication>
#include <QtOpenGL>

class HelloGL : public QGLWidget
{
public:
    HelloGL(QWidget *parent = NULL) : QGLWidget(parent) {}
    ~HelloGL() {}
protected:
    void initializeGL() {
        glClearColor(0, 0, 0, 0);
    }
    void resizeGL(int w, int h) {
        glViewport(0,0,w,h);
        glMatrixMode(GL_PROJECTION);
        glLoadIdentity();
        double aspect = double(w) / double(h);
        gluOrtho2D(-aspect, aspect, -1.0, 1.0);
        glMatrixMode(GL_MODELVIEW);
        glLoadIdentity();
    }
    void paintGL() {
        glClear(GL_COLOR_BUFFER_BIT);
        glColor3f(1.0,1.0,1.0);
        glBegin(GL_TRIANGLES);
            glVertex3f(-0.5,-0.5,1.0);
            glVertex3f( 0.5,-0.5,1.0);
            glVertex3f(-0.5, 0.5,1.0);
        glEnd();
    }
    //void mousePressEvent(QMouseEvent *event);
    //void mouseMoveEvent(QMouseEvent *event);
    //void keyPressEvent(QKeyEvent *event);
};

int main(int argc, char *argv[])
{
    QApplication app(argc, argv);

    HelloGL window;
    window.resize(500,500);
    window.move(0,0);
    window.show();

    return app.exec();
}

I went ahead and filled in a full resize stub implementation here, just for the sake of robustness.  I also left some comments suggesting where you want to hook in to capture some of the input.  Of course, there are many more places to capture input, but this is enough to get some basic click and drag camera manipulation implemented.

The really nice thing about the above code, which isn’t obvious unless you’ve used Qt, is that the HelloGL object is just a QWidget.  That means you can both drop it in as a top level window (as I did in the above code), or place it into a widget layout inside another window.  This makes it super easy to start adding some basic GUI buttons, checkboxes, sliders etc. (the reason you’d be using Qt in the first place)

I also hear there’s a way to get floating widgets over the viewport, but that turned out to be a rathole that just wasted a lot of my afternoon.

1. Go ahead and download the installer from the Qt site.
2. Install Qt and note where you created the QtSDK directory
3. Add /…/QtSDK/desktop/…/bin to your shell path.  (This ensures qmake is on the path among other things)

That’s it.  I found a reasonable tutorial here.  BUT, there’s one more slight rub.

If you follow through that tutorial, you’ll see that Qt prefers you to use their own autotool-like cross platform build system.  This usually involves issuing the three shell commands “qmake -project” “qmake” and then “make” in succession.  However, on mac, doing this will get you an app bundle.  What if you still want to be able to print to standard out and launch the program from the terminal in the normal unix fashion?

This can be fixed by editing the project_name.pro file generated when you issue “qmake -project”  Simply add the following line:

CONFIG-=app_bundle

Then the qmake toolchain will generate a nice normal unix program.  If you want to create an app bundle to distribute, just remove the line, and you’ll be all set again.

1. major GUI toolkits have had a lot of people, time, and attention given to them, so they have many more features than you could hope to implement on your own.
2. major GUI toolkits also have a tremendous amount of HCI wisdom and knowledge embedded in them.  If you use a good GUI toolkit, your program will probably be somewhat more usable even if you don’t know the first thing about usability.
3. immediate mode GUIs scale poorly to more complicated interfaces.  They don’t have hierarchical layouts and more complex reactive functionality has to be hand coded.

I figured I should throw something up and warn people away from the siren’s call.

Is TRON a good depiction of cyberspace, Gibson’s “nonspace of the mind”? I’m inclined to say no. Space in TRON is very physical and literal. On “the grid” time and space have their usual relationship: to get from point A to point B requires an amount of time proportional to the amount of space. There are concrete forms, buildings, hallways, corridors.  TRON looks really cool, but it fails to capture much of the essence of computers, the internet or digital interaction.

The problem is that cyberspace is a misnomer.  Almost every attempt to make our online experience spatial has failed.  Chat rooms are not rooms; online “stores” are more like mail-order catalogs; the distance between any two points is the same: a hyperlink.  Despite pervasive use of spatial metaphors, the internet is for all practical purposes simply not a space. Still, the idea of cyberspace persists, an alluring, romantic thought.  What does our massive interconnected network of computers, information, and people look like?  What is its shape, its architecture, its landscape?

192.128.1.4 [GEOCITIES99] from Victor Timofeev’s series Local Area Networks

This artistic question has certainly seen a variety of answers more nuanced than a Disney blockbuster.  Victor Timofeev’s work (pictured above) is one interesting recent variation.  Timofeev depicts websites as ramshackle structures positioned on an infinitely receding, flat and featureless ground, similar to the one used by the Surrealists.  In both cases, this featureless ground is a cue for mental, not literal space.

The Melancholy of Departure — De Chirico, 1914

For me, one of the most tantalizing artistic questions about depicting cyberspace is how to create a spatial representation of something decidedly not spatial to begin with. One clue we might glean from Timofeev and De Chirico is their treatment of perspective. De Chirico intentionally plays with our expectations of perspective in order to better evoke the desired melancholy.  The rising horizon on the right side of the canvas seems depressingly remote, further diminishing the two tiny figures saying their goodbyes.  Meanwhile, Timofeev constructs a ramshackle stack of rooms in order to depict the chaotic personalization and incoherence of Geocities in the early days of the internet.  By arranging the rooms at disparate angles, Timofeev denies us any unifying, central point of perspective, without resorting to flattening out the canvas. In both cases, the results violate our expectations of space, of perspective without going so far as to obliterate it entirely. (as for instance Picasso did)

However, both of these examples rely heavily on a fixed perspective, a fixed viewing point within the scene.  Could we create some kind of interactive exploration of “the nonspace of the mind”? How might we manipulate perspective profitably in an interactive environment, or at the very least, in a video?  What conceptual or emotional effect might these manipulations produce?

I’m a little confused… if a real matrix is not symmetric, there is no guarantee of a real eigenvector (e.g. take a 2-d rotation matrix), so what did you mean “I expect that other arguments along similar lines are possible for non-symmetric real matrices”?

As it turns out, I’ve been spending quite some time repairing my own understanding of linear algebra.  What I should have said is, I expect to find similar arguments for normal matrices.

Normal is a terrible name of course.  Are other matrices weird? non-conformist?

Unfortunately, I haven’t figured out how to pin down a similarly elementary flavored proof for normal matrices.  Instead, I’m going to present an argument for another branch of the family tree: (so to speak) orthonormal matrices.

But first, I realized my last post might have jumped in a bit too deep all at once, so I’m going to try to err the other way and cover some more basic linear algebra this time as well.  Bear with me and let me define orthonormal matrices before I talk about their eigenanalysis.  I’ll give two definitions and suggest why they’re equivalent.

One standard approach is to think of the columns as vectors in .  For instance, take the vector space , aka. “yes, that convenient mathematical model for the space we live in.” We might have the matrix (courtesy wikipedia)
We say a square matrix like this is orthonormal when the column vectors are all length and are pairwise orthogonal.  More symbolically, for every column vector , (equivalently ) and for any two distinct column vectors and , their dot product is .  This gives a simple computation we can perform to check that the above matrix is in fact orthonormal.

But, I’m a graphics person, so let’s make a picture.  I’ll go ahead and plot the three column vectors (labeled ) relative to the standard basis vectors , and .

As you can see, the column vectors appear to be unit length and orthogonal to each other.  If we place them in correspondence with the three standard coordinate vectors (axes) then we can think of the column vector basis as a rotated image of the standard basis.  That is, our matrix is encoding a rotation transformation.  This is how we get our second definition of an orthonormal matrix.

If we want the effect of multiplying by an orthonormal matrix to be a “rotation” (whatever that means in -dimensional space) then it should probably have the following properties. (A) transforming a vector shouldn’t change its length and (B) if two vectors are orthogonal before transforming them with our matrix, then they better remain orthogonal after transforming them.  These two conditions translate to the following properties

• For all vectors ,
• For all vectors ,

In fact, we can now see that the first condition is a special case of the second.  We can express the second condition in a more algebraic sounding way with the phrase “an orthonormal transformation is a transformation that preserves the dot product.”  We can get an even nicer algebraic characterization if we do a little symbol pushing.

Now, the only way that the rightmost equality is gong to hold is if we can just remove from the middle.  But we can do this precisely when the identity matrix.  Aha.  That’s a great definition, now we don’t have to talk about column vectors or any sort of vectors whatsoever.  Slick!

(It turns out that you can get the equation for orthonormal matrices from the first definition I gave too.  The trick is to realize that the entry of the matrix product encodes the dot product between the th and th column vectors.)

OK, now that we’re all chummy with orthonormal matrices, I want to state the key theorem for their eigenanalysis.

Theorem: Given an orthonormal matrix , () there exists a two dimensional subspace of “fixed” by .  In other words, there exist vectors so that for any linear combination , the vector is also a linear combination of and .

Since we defined an orthonormal transformation to preserve length, this means we can think of ‘s effect or action on the subspace as a rotation.  Combined with some other (simpler) theorems, we can arrive at the punch line of orthonormal eigenanalysis:

Every -dimensional rotation factors into a series of independent -dimensional rotations.

This is a fascinating geometric fact, but it’s usually buried behind this mess about “complex eigenvalues.”  Continuing my theme, you don’t need complex numbers, polynomials or lagrange multipliers to prove this theorem.

proof:
To start, why don’t we just leverage our previous result about symmetric matrices.  In order to do this, we have to “symmetrize” our orthonormal matrix: .  Since is symmetric, we know that it must have some maximal eigenvalue and eigenvector so that

This tells us that the three vectors , , and are linearly dependent.  Geometrically, they all lie in the same plane.  However, we really want to focus on , not , so let’s go ahead and “rotate” this arrangement of three vectors by :

(You can check that if and only if , but I’ll just assume that’s already been proven here.  You may also want to note that this is the key point at which we invoke orthonormality.)  Squint, and you should see that this equation tells us that if we keep rotating by , then we start becoming linearly dependent after the second rotation.  We just need to dot our ‘i’s and cross our ‘t’s now.

Let and .  Then,

There is obviously a lot more to be said about the consequences of this theorem for , , and dimensional rotations, but I’ve already said more than enough for a single post.

For those of you that have had complex/imaginary numbers tacked onto your curriculum like an aluminum spoiler on a stock Honda Civic, I really think you should teach the Mandelbrot Set.

Such a perspective is of course hogwash.

I know for a fact that a much more geometric (and in my opinion illuminating) interpretation of eigenanalysis is possible.  However, I had never seen a clear exposition from first principles that one could reasonably expect to present in a beginning linear algebra course.  Every explanation of the geometric perspective that I’ve seen has been post-hoc or relied on machinery like Lagrange multipliers—an unwelcome diversion.

I would not be surprised if someone else has come up with this proof before.  However, I was not able to quickly find a reference for it.  It makes no appeals to (a) the characteristic polynomial, (b) matrix polynomials (c) complex numbers or (d) Lagrange multipliers.  I have only treated the real-symmetric case, although I expect that other arguments along similar lines are possible for non-symmetric real matrices.

Theorem: Let be an real symmetric matrix.  Then there exists an eigenvector with eigenvalue .  In other words, .

the proof:

We will hinge this discussion on the maximization of a function , constructed from the matrix .  Let be a real-valued function defined on input vectors constrained to lie on the unit sphere.  In other words, we impose the constraint .  To begin with, we note that the function is continuous and defined everywhere on the unit sphere.  Since the sphere is a bounded domain, must attain a maximum for some pair of unit vectors .

Now, I claim that if is a maximal pair, then must lie collinear with .  To see why, rewrite the dot product defining as . Since , we may independently maximize the other two terms and .  Once a maximizing is chosen, is optimized to be by choosing collinear with .  This gives us the identity .

Now, since our matrix is symmetric, must also be a maximal pair, since .  This gives us the identity .  In general, symmetry usually makes it possible to swap and .

Now, before we get to the finale, I’d like to take a brief break to reflect on one of our earlier observations.  Recall that .  In our previous argument we concluded that both and better be true of any maximal pair.  Although we didn’t note it at the time, this means that for our maximal pair .  By symmetry, we can then observe that .  That is, and are equally stretched by .

Finally, we are ready to bring things to a head.  I claim that is an eigenvector of with eigenvalue .

The intuition:

Of course this proof, while rigorous, hardly gets at the appropriate intuition.  Either before or after the preceding proof a teacher would be remiss not to mention that the function has elliptical level sets (when the matrix is positive definite), and then to give a visual demonstration of what these maxima of the function really are.  They identify the axes of the ellipse—the eigenvectors—while the eigenvalues reflect the radii associated with each axis.

If someone is already familiar with the method of Lagrange multipliers, then the preceding argument can be mostly elided.  However, working around them avoids a major digression into multivariable calculus.

I just got this hot link from the c0de517e blog (now on my blogroll):

http://mollyrocket.com/861

The video’s 40 minutes long, so—let’s be honest—you’re not going to watch it. I’ll try to give you my best explanation of what I heard, but I’ll probably butcher the idea.  However, I’m planning to try this in my next research project, so maybe I’ll have some more concrete experiences to write up in the future.

Ok, here goes. A traditional GUI system, such as TCL/TK, QT, FLTK, Cocoa, Carbon or the Windows GUI system works something like the following: Create a window object.  Then, create widgets (GUI elements/objects e.g. buttons, text-boxes, sliders) which are registered as children of the window.  Keep making more widgets, and organize them in a hierarchy.  Now, Every time you create a widget, you have to do a bunch of things: (a) You have to construct the object in some fashion.  (b) You have to set some parameters. (e.g. button text, position, size) (c) You have to register a callback—code that is invoked when (for example) the button is clicked. (note: I’ve been using callbacks for drawing the triangle in my GLUT/OpenGL triangle series) Finally, (d) you have to tell the widget to display itself.

This is a lot of trouble and code. The rampant use of callbacks ends up fragmenting your UI code across multiple lexical scopes.  It can also introduce concurrency issues, since you have no control over when these callbacks get invoked.   Dynamically adapting your GUI to your user’s behavior (e.g. switching menu screens in a game) is difficult, since UI elements have to be created, destroyed, registered, unregistered, hidden, displayed and so on.  This proliferation of seemingly decoupled widgets can also encourage spreading your GUI code across many different files and modules—which can often be a detriment to understanding.

The key idea of immediate mode GUIs is to centralize all of your GUI code in a single DoGUI() function that gets called every frame.  DoGUI() should work just like Draw() does right now. You, or some system just calls DoGUI() as the first item in your render loop.  Inside of DoGUI(), you call routines like DoButton(). Just like with a DrawTriangle(…) or DrawLine(…) function, you pass in the vital data for the button in question, and the DoButton() function returns a boolean telling you whether the button was clicked this frame or not.  Using a simple conditional, you can react to a button push: if(DoButton(…)) { handle button click }.  DoGUI() is just a list of all the GUI widgets you “do”.  It’s up to you how you choose to organize the data for the widgets.  That data belongs to you and your application, not the GUI library.

This approach makes it really easy to remove or add GUI elements.  At about 22:30 into the video Casey (the Molly Rocket guy in the video) explains, “I can do culling… I don’t have to delete the item, I don’t have to disable it. I don’t have to hide it. I just simply don’t call it that frame. I don’t have to know how many of these there are. I don’t have to create [UI elements] for it ahead of time.”  That’s really cool. You can basically change the entire GUI from frame to frame without having to fight the GUI toolkit.

Casey makes some more interesting points. This approach integrates well with 3d and components that don’t know about or care about UI stuff.  Take for example a rendering module/library. Talking about 3d objects, he points out that “almost always they have some way of doing ray picking. And they can always render themselves. That’s all you need to turn them into an immediate mode widget.” So now we can have 3d buttons and interface elements exposed via the same API as our 2d GUI elements.

Something I did not know, but I’m very glad to know about now:  Speaking about traditional GUIs in modeling/design applications, Casey says “…to the point where even in professional 3d applications, often you have two totally separate systems: one for the 2d user interface, one for the 3d user interface. That’s crap.” Yes. Yes it is.

Immediate mode GUIs sound like a really good idea for real-time applications in particular (design/games), since you’re already redrawing every frame. You can do crazy stuff like floating buttons over characters etc.

I haven’t looked at it, but someone at Nvidia has made an immediate mode GUI library available that they use for their graphics demos:
http://code.google.com/p/nvidia-widgets/

So if you want to try it out, maybe that’s a good place to start looking.

I hadn’t heard before, but Demetri’s group recently released this ambitious paper: Comprehensive Biomechanical Modeling and Simulation of the Upper Body

Some particularly cool papers from day 1:

Jonathan Cohen, Sarah Tariq, and Simon Green. Interactive Fluid-Particle Simulation using Translating Eulerian Grids. link
The talk started with some very useful high level observations and motivation. Jonathan emphasized that our goal should be scalable physics, not just fast, realistic physics. Sequential algorithms are insufficient. Parallel algorithms alone are also insufficient. We want parallel algorithms that produce better looking results as hardware gets better. There were some cool ideas here: Use Gallilean invariance to replace translations of the simulation grid with fluctuating boundary conditions (modeling the entrance/exit of matter from the volume). Apply the fluid simulation to particles with less influence as you move towards the edge of the grid. This gets around the simulation/fluid in a box problem. Cool tidbit: They used this technique for jetpacks and one of the guns in the videogame Dark Void.

Christian Miller, Okan Arikan and Donald Fussell. Frankenrigs: Building Character Rigs From Multiple Sources. link
(Full disclosure: I know all of the authors fairly well from my time at UT Austin.) This is an end-to-end system for (semi-)automatically rigging and skinning character meshes. I didn’t know this, but rigging and skinning is tedious for experts and nearly impossible for everyone else. The idea was to take a data-driven approach and leverage previously skinned and rigged character meshes (of which game and movie studios have plenty lying around). The input meshes are cut into limbs and then appropriate limbs are matched to the target mesh and stitched together. Hence the name: Frankenrigs. One very interesting observation: The method handles non-manifold, non-closed meshes, which is the way almost all artists’ meshes come. Christian actually ran into this problem when comparing to previous work: He couldn’t because the past work didn’t work on non-closed meshes.

Samuli Laine and Tero Karras. Efficient Sparse Voxel Octrees. link
This paper had a really killer demo. They managed to voxelize and render at reasonably high fidelity the NVIDIA street scene and the Sibenik cathedral scene. Along with the Gigavoxels paper, this makes it look like adaptive resolution voxel grids may be gaining a lot of traction. The contributions here were mainly an efficient ray marching algorithm, and effectively handling and filtering normals. The authors have open sourced the code base, so if you’re looking to get your hands dirty with some voxel rendering and/or research, this might be a good place to start.

Also, there is a lot of snow here: