MudLog

It’s been almost two months since my last post. E15 development was in full swing as well as thesis writing. We’re thinking about distributing the binary soon, and we’ll definitely have to rework the website. The best way is to probably make E15:Web as the E15 site. Anyway, this blog is going to close soon. Graduation is on June 6. My thesis was submitted today…so I’m done!

I’ve been spending a lot of time on implementing E15’s texture management. We wanted to have a way to upload textures asynchronously (lazy load) so that when we apply filters to the bitmaps, we don’t have the whole process blocking. This means we need threading, and I went through some rough waters with OpenGL and Cocoa threads.

The design is pretty simple. Whenever a new texture needs to be created, the bitmap is initially split into a series of tiles, then uploaded with mipmaps onto the GPU. For images that require filtering (with Core Image filters) we create a new thread that will create CIImage instances and applies a series of CIFilters. When the image is processed, the CIImage is converted back into bitmap, then sent to a singleton texture manager which periodically uploads the queue on the main thread. There were some confusing implementation details, and I’ll write them down after I describe the result.

So far, I implemented a couple different effects. The top picture shows blurring. Elements look blurry when viewed from far away, but becomes focused as you move close. Using this idea of zoomable user interface, I can show different information on the same quad depending on how far away the camera is. Here’s some captures showing various web pages.

…and here’s the obligatory Facebook shot

Now for some implementation notes. For starters, we need to remember that we need to run all OpenGL calls on the main thread. We will have to spawn a new thread for each texture we want to apply textures to, and have a singleton TextureUploader that will upload textures on the main thread. The real pain is to workout how the images should be constructed and processed when in a secondary thread.

I’ve tried a few different ways, and most of them resulted in unexpected crashes. The one I settled with is the following. During awakeOnNib, a static CIContext is created with the main CGContextRef:

CGContextRef cgContext = [[NSGraphicsContext currentContext] graphicsPort];

_drawingContext = [[CIContext contextWithCGContext:cgContext options:nil] retain];

This is the CIContext in which all the CIImages will be rendered to a CGImageRef. This method seems to be thread friendly.

In order to lazily create the filtered image, and uploaded; the initial bitmap texture that is uploaded is first converted to a CIImage. This image is sent to a new thread, which applies the CIFilters. The finished image will then be converted as a CGImageRef and drawn to a bitmap. The bitmaps are sent to a singleton class TextureUploader, which will upload textures every 500ms if there are any pending uploads. To convert CIImage to CGImageRef, just use this:

- (CGImageRef)cgImageCreateFromCIImage:(CIImage *)cimg fromRect:(CGRect)rect

{

    CGImageRef cgImage;

    cgImage = [_drawingContext createCGImage:cimg fromRect:rect];

    if (cgImage == NULL) {

        NSLog(@”failed to create cgImage”);

    }

    return cgImage;

}

This all seems simple, but it took a lot of trial and error. I hate threads…

E15 is our newest project. It’s a new 3D graphics programming environment where we enable users to control the content and presentation. Our vision of what the web will be in the future. We demoed this at Flash Forward 2007, and just recently launched its website. We’ll be posting new stuff up there.

Finally finished the first application that uses MudSketch. Modster is a graphical exquisite corpse, each of which are drawn by three people. Participants draw a portion of the corpse in sequence: head, torso and leg. Each of the three participants must contribute and submit a drawing – otherwise the corpse will never be completed, making the creation process truely collaborative and participation dependent.

Here’s a simple tool called MITPTyper. Any phrase you type into the text box will render it as Muriel Cooper’s MIT Press logo. I know this is a small project, but it’s going to count as my April project.

I’m going to try and release a new web app every month this year. So far for the month of January and February, there was RunLog and OpenLocker. The web app for the month of March is FakeID.

FakeID is an OpenID server that gives you control over your online identity. With your existing OpenID account, you can use FakeID to create unique online identities. Think of it as an OpenID proxy. Anyway, I just finished it, which means it may be a bit buggy, but so far everything seems to work.

Finally, OpenLocker (formerly PLW Locker) is ready after some months in development. OpenLocker is a multi-functional web application that serves as an OpenID server, and a personal homepage. As an OpenID server, OpenLocker differs from other OpenID authentication servers and attempts to preserve user privacy by using a locker metaphor. The OpenID specs specify only that an OpenID URI be unique to a specific user, but does not specify any authentication method. Usually, an OpenID server manages user accounts like any other web application: with a username (which corresponds to a unique URI) and an alpha-numeric password. Because of this, this method of using OpenID still suffers from security/privacy issues that exist in other username/password systems. OpenLocker uses a geographic locker location (which is unique) as the username and an emulated combination lock as the password.

Beyond its use as an OpenID server, user’s identity URL (connected as HTTPS, once logged in) will provide them with draggable modules, which are individual RSS aggregators. Users can pick from a collection of feeds (like OpenStudio and OpenCode) or enter any valid RSS/Atom URL to display content. This provides a page that can act as a user’s identity page as well as their homepage, where they can begin their daily Internet browsing.

Just a note that OpenCode is now OpenID enabled. You can either use the Login/pass or use your OpenID url to authenticate.

I didn’t go home for the holidays. Instead, I stayed and worked at the Lab. This meant I had a lot of time to get stuff done, and I just launched a brand new web application, called RunLog. RunLog is an application that you can use to log how much you run. If your new year’s resolution is running, this is an application for you!

RunLog uses OpenID for user authentication, and all applications I build this year will use it. Hopefully this means it will be easier on everybody, no more remembering username and password for every different site you use. RunLog is also a social network. Hopefully, by support (or pressure you feel) from other users, it will influence people to keep on going.

I think using OpenID is important. The Locker project I’ve been working on has turned into an OpenID authentication server, and it is fully functional as an OpenID server now. I just need to smooth up some rough edges and it will finally be available for use.

Oh, for anyone interested in using OpenID with Ruby on Rails, I modified the generator that ships with the ruby-openid library which can be downloaded here.

Finally, at the end of term comes the pre-alpha, public release of OpenCode. What does it mean when we say pre-alpha? It means it’s not done, but we wanted to get people playing with it rather than letting it sit on my computer collecting dust. When we say public, it means anyone can sign up and start using it. So…try it out. Let me or Kyle know what you think.

PLW Locker is almost done, I’ll have it ready to go by the end of the year. OpenCode will be the first site to support logging in from the Locker. Everybody, go get yourself a PowerMate and get ready.