Jacob Eiting

Displaying Animations in OpenGL on iOS using Bink and Shaders

Mon, 10 Sep 2012 08:53:00 -0400

I’ve discussed before the issues with fluid 2D animation in an iOS game before. Memory, load time, bundle size, and hardware limitations all contribute to making traditional sprite sheet animation on iOS difficult. We were able to just get by with them in the early days of MinoMonsters. Then the evolutions happened.

Suddenly we needed more space for our monsters. With the hard limits presented by sprite sheet animation, we couldn’t fit more than half of an evolution animation on a full size texture sheet. The device simply could not bear the memory load required for monsters of this size. A different approach was needed.

One Word: Video

Each animation is taking up too much memory. We are holding every frame of the animation in memory for the entire duration although only one frame is visible at a time. The contents of a single frame make up only 3% of the total texture sheet area. That is 97% wasted memory. How can we cut down on this waste?

Video.

There has been a lot of engineering effort invested making computers capable of playing video. What does video actually mean from a software perspective? Video playing pipelines work something like this (my understanding of it at least, I’m probably wrong):

This process occurs each frame, the next frame is pulled from the video file and decompressed, this often involves applying diffs pulled from the video file to the previous frame, the video data is then in a state of several images that represent the different channels of the final frame (i.e. RGB). The color planes are then recombined using either built in hardware or in software. The resulting image is then sent to the display. This process repeats at the framerate of the video, producing a smooth image. The advantage of a system like this is that each frame is pulled from the video file on demand. The only memory required for video decompression are few buffers to hold the color planes and a destination buffer for the final composite. More on this later.

A video codec is not something that you can just whip up from scratch, at least not in a startup environment. The system that compresses, stores, and decompresses the image data must be heavily engineered in order to remain efficient yet small in file size. This was not something we could do on our own.

Enter Bink

There are tons of video codecs out there. Apple’s iOS APIs support about 20 of them out of the box. iOS even has many built in facilities that take advantage of the h.264 hardware on the phone for fast video decompression. Unfortunately we ran into a major issue with most of these formats, the lack of alpha support. Most video codecs were never designed with transparency in mind but MinoMonsters requires it for compositing monsters with the background environment. I then recalled something I’d seen on the back of retail game boxes and on splash screens before:

Bink Video. What is this mysterious framework who’s brand I recognized instantly? After reading the marketing copy it looked very much like our solution. A self contained video codec that supports video with alpha, optimized for games AND they had just released an iOS versions. Yes, please.

What Bink Does

Bink is made up of a proprietary video format and codec. The codec can be embedded directly into your application via a static lib, avoiding any dependencies on iOS versions. The C framework then gives you facilities for opening these files, decompressing them, compositing them on the CPU and some examples on how to get the final products on to the screen (which is very platform dependent). After verifying the resultant video files would be small enough, we proceeded with implementing a new rendering system using Bink.

The Bink Pipeline

Our first attempt at rendering with Bink looked something like this:

Many video frameworks don’t maintain the video in RGBA channels instead opting for a lesser know Y cR cB A representation. This representation consists of a luminance channel, two color channels, and an alpha channel. The reasoning behind this being the human eye can not perceive compression in the color channels as easily as it can in the luminance channel. This allows the 2 color channels to be compressed more heavily and even to be stored at a smaller resolution then the final video without sacrificing quality.

The first step in rendering a Bink video is decompressing these color planes. Below are examples of the separated color planes for a frame of a MinoMonsters animation:

These images then have to be recombined in order to produce the final resultant frame. The simplest way of doing this is by combining them using built in Bink methods which do the compositing on the CPU (utilizing some of the vector hardware in the iPhone processor):

Following CPU composition this image then has to be uploaded to the GPU for display in our OpenGL context, no problem.

The Performance

Well, there was one problem. This approach was slow. We were now asking the CPU to decompress a video file and then to recombine it, pixel by pixel, before uploading it to the GPU. The CPU based approach is plenty powerful if you are only displaying a single video. In MinoMonsters we are always playing at least 2 videos and sometimes 4. We also started to run up against the limits of GPU bandwidth as we were uploading a full texture every frame. But there was another way.

Loving the GPU

The GPU is built for this kind of work, taking data buffers and operating on them in parallel. Using the GPU to recombine the image, the pipeline becomes slightly modified:

The key difference here being: We upload each color plane to the GPU as a separate texture. Then, through the powers of OpenGL, we recombine the frames into a render texture which is already on the GPU. We are then instantly ready to display this frame.

YcRcBA Compositing in OpenGL

Recombining the color planes in GLSL is fairly straight forward process. It can be entirely represented with a matrix multiplication and a post bias addition. After several iterations, I found this to be the most efficient method of transforming the color vector in GLSL on iOS:

Each color component of the YcRcBA vector is pulled from its individual texture which have been uploaded to the GPU straight from Bink. The components are then combined into a vector and transformed. The alpha component does not need to be processed and goes straight to the resultant fragment. The fragment color is then passed down the rendering pipeline to eventually be ‘rendered’ to a framebuffer bound to a texture. This allows us to use the result in rendering without a download and upload step, saving considerable amounts of time.

Pure Savings

In my previous post I explored the memory costs of using traditional sprite sheet animations. An animation in that system typically ran upwards of 16 MB of memory. We can compare that to Bink.

Let’s examine a worse case scenario: an image that takes up the entire screen (as some of our attacks do!). The Video file itself is fairly small, on average of about 500KB. We open the entire video file into memory to reduce filesystem read times. The next memory budget item is the buffers Bink requires to do decompression. Bink requires 2 buffers for each color plane due to the nature of the Bink decompression algorithm. The luminance (Y) and alpha planes are 960x640 and 8 bits per pixel, for 614k each. The color planes are only half the resolution of the luminance and alpha planes, 480x320 at 8 bits per pixel, for 153k each. This is a total of 1.5 MBs per frame buffer. Bink requires 2, so that brings us up to 3 MB. 3MB is great but we aren’t quite done yet. Each animation has 4 associated textures on the GPU for uploading the color planes. These make up another 1.5 MB. The final memory requirement is the destination texture, at 960*640 and 32 BPP this knocks us back another 2.4 MBs. This brings us to a grand total of 7.5 MBs total memory for a full screen animation. This is the absolute worst case scenario and we’ve achieved a 56% reduction in memory usage!

This sizable reduction was enough to eliminate memory crashes for the vast majority of our users. I am convinced that it played a big part in pushing our app to the 5 star threshold.

The Costs

All these savings aren’t free, aside from the Bink licensing fee (which was not bad), we have taken a lot of load off the systems memory and pushed it onto the CPU and GPU. This did lead to a marked decrease in frame rate on the iPhone 4 and 4th generation iPod. Is it still playable? Absolutely, but you can feel it. We squeezed as much performance as we could out of these devices but we just aren’t able to push back up to that 60 FPS gold standard. Our compromise was to lower the target framerate to 30 FPS. This gives us smoother overall framerate which, I think, is preferable. The iPhone 4S has no problem keeping which gives me faith that as new hardware is released, frame rates will once again reach 60 FPS.

Solving Problems

Implementing a Bink based rendering system was no small feat for me and our team. My personal understanding of OpenGL was basically zero before embarking on this journey. Many concepts had to be learned from first principles (read: the red book). The going was slow but we emerged out the other side with something that solves our problems. This is what we do as software engineers. Sometimes there is a better way. You just have to figure it out.

Acknowledgements

This project was one of the most ambitious engineering efforts I’ve ever done. It would not have been possible if not for the rest of the MinoMonsters team, for clearing the road for me, letting me dive into the bowels of the OpenGL stack. Also a big thanks to the team at Bink, they were nothing but helpful and responsive to my questions during the integration process.

Programming is Hard

Thu, 06 Sep 2012 02:02:00 -0400

How do I learn to program?

As a software engineer I am often approached by people with the question “How do I learn to program?”. It fills me with an excitement that is hard to describe. I get the privilege of revealing to someone the agony and ecstasy of building software. From here I jump into the usual diatribe, discussed later, about how to get started. The wannabe student typically walks away with a mixture of excitement and dread as I have revealed to them that there is no secret. The only fact that anyone needs to accept is this: Programming is hard.

How hard?

Any new ‘trick’ that a person wants to learn can generally be assigned some difficulty level. At the low end of the spectrum we have tasks that are trivial for adults, these would include things like washing dishes, sorting objects, simple cleaning tasks, basic manual labor. These things can be taught in minutes if not seconds. Beyond that we have tasks which may take a few hours to learn, driving a stick shift, driving a boat, folding clothing, operating a machine press. These tasks, while trivial, increase in their nuances and sophistication. A working ability for these skills can be developed in an afternoon. Beyond this, we have skills that take days: landing an airplane, parallel parking, juggling, riding a unicycle, carpentry. These are skills that can be developed to a basic, functional ability over the course of a few days to a week. Programming, on the other hand, will take you months.

What makes it so hard?

This is a good question. I’m not entirely certain why I’ve watched so many people struggle in the infancy of their learning but I think the core problem is the inability to create visual/physical analogs for what they are doing. In all of the minute/hour/day tasks listed above, they are manipulations of systems that the learner has direct visual or tactile feedback from. Pushing this thing, moves that thing. Shifting to this gear pushes me into my seat. Every action is met with a flood of stimulation that allows the brain to more quickly adopt pattern recognition (also known as learning). With software, especially in the early stages, the effects of ones actions are much more obscured. Perhaps it is an interface issue, text is not the most informative I/O yet is the interface of choice when learning to code.

What takes a lot of people off guard is that they are expected to solve problems in this abstract space. Give someone a physical puzzle, like getting a couch out a door thats too small, and they will excel. Remove the physical couch and the door replacing them with programming abstracts and suddenly the person doesn’t know where to begin. The brain is lost in the void of signaling for what is actually happening inside the machine. Programming is not just learning to solve problems; it is chipping away the mystique of the machine and developing an understanding of the consequences of your inputs.

How long until I am good?

A Case Study

Out of my own interest I’ve taken a look at my own experiences to figure out exactly when I reached the tipping point of being less confused about writing code.

Fall 2005: I receive an undergrad research position in college, spend a few weeks for the better part of a year getting sockets to work in C. (100 hours)
Summer 2006: I receive $500 bucks to write a ruby on rails page for a realty company, the quality is really low. (40 hours)
Fall 2006: Begin taking computer science classes, many tiny projects. Still so confused. (200 hours)
Summer 2007: Land an internship at Cisco, spend summer writing test scripts in TCL for IP phones, starting to slightly understand things. (200 hours)
Fall 2007: Return to research position and being writing a real time PubSub system in python, wrote tests, think I am getting things. (500 hours)
Fall 2007: Launch of facebook platform, wrote a handful of crappy facebook apps, hosted from parents’ basement. (50 hours)
Winter 2008: iOS SDK announced begin working on analytics tool for iOS apps which become AppLoop. (500 hours)
Summer 2008: Published Paddle Ball app on the app store and sold off some other apps I wrote. (200 hours)
Fall 2008: Return to research project and begin building complete telescope control systems on top of my PubSub system. (500 hours)
Spring 2009: Land first real job as a programmer.

I think some of these numbers may be gross under estimations (I spent A LOT of time on AppLoop) but before I was able to feel comfortable taking a salary for producing code I had in the neighborhood of 2200 hours of experience. I think I finally started to ‘get it’ around hour 1700, before that I was just stabbing around, typing until I got results. For comparison, I received my pilot’s license with only 60 some hours of training. Twenty two hundred hours is a lot of time, not quite Gladwell’s 10,000, but getting there. It takes time, a lot of time. Left out of this was the fact that I was simultaneously minoring in computer science, which added an un-calculated amount to my hours.

100 Bad Projects

An artist friend of mine once relayed to me a quote:

“Everyone has a 1000 bad drawings inside of them. The sooner we get those out, the sooner we can start making better drawings.”

The same holds in programming. Maybe 100 bad projects but there is nothing you can do but get them out of you.

Between my work, homework, and research I was probably at about the 100 project mark when I started be a little less confused about what I was doing. There is nothing I can press more on the new learner than to try and push through these 100 projects as quickly as possible. Build a little funny script, a twitter bot, a single serving site, a simple iPhone app. All of these projects are within the reach of the fresh-out-of-tutorial-land newby, you just have to grab them and run. Then keep grabbing. A hundred times.

My Typical Spiel

When someone comes to me with the nebulas I want to learn to program I usually send them some variation of the following theme:

Get Involved
Get Learning
Get Making

Get Involved

Start reading hacker news every day (not all day), even if you don’t understand it. Observe the hacker in its natural environment, try to keep tabs on things you see a lot of: JavaScript, Rails, Clojure, RabbitMQ. Go to user groups, CocoaHeads or for ruby. Get immersed in the field. If you want to be a programmer, start hanging out with them. Convince yourself you are a programmer.

Get Learning

The tools out there are just getting better and better for learning how to code. Codecademy can teach the basics. Getting a good book and working through it will jumpstart the process. I can’t emphasize enough the working through it part. Most books have challenges, some so complicated it may even knock out one of our 100. Getting your money’s worth from the books is highly recommended. My favorite books for learning iOS are by Hillegass. On the web side is seems this tutorial is really good. Pick one and finish it. No matter how confused you are. Keep doing it until it makes even a little sense. Devise your own challenges. Push yourself.

Get Making

Nothing is going to get you closer to being a programmer than writing code. No book can teach like the experience of realizing the errors in your ways. Every new project is a chance to avoid the mistakes of the past and do it right. This process never stops. Make coding a part of your routine. Eliminate distractions that allow you to do anything else.

Programming is Hard

There is no way around it. There is a reason the demand for programmers exists. Keep pushing and keep making.

The Problem with Animation

Wed, 05 Sep 2012 02:07:00 -0400

Our Style

I’ve been working on MinoMonsters for over a year now. From the beginning we knew we wanted to have full motion, hand drawn animations. Giving our monsters that lush, Disney quality that hadn’t been seen on iOS at the time.

No problem, right?

The only approach that would seem to support our stylistic desires was rasterizing our animations out frame by frame. Taking the raw animations files (created in Flash) and exporting each file as a static PNG. We then would take the PNGs and reassemble them using TexturePacker to create texture sheets. Poking around, this seemed to be the standard for 2D animations on iOS (especially with coco2d).

We would run our SWFs through TexturePacker and out the other side we would end up with something like:

Every frame of the animation is placed into the same final image. This is done so that we only have to upload the animation onto the GPU once and can then display each frame in rapid succession, simply telling the GPU from where in the texture to draw our sprite. This gives texture sheet animations the advantage of having essential zero cost of advancing frames. We had done it. We had brought our monsters to life, but at what cost?

The Costs

The OpenGL ES implementation on iOS has a few limitations that effect the way textures can be used:

Textures must be an even power of two in dimension. (i.e. 512, 1024, 2048 pixels)
Textures must be square. (This requirement was only on older, 2nd gen iOS hardware)
Textures must not be larger that 2048 by 2048. (half that on SD hardware)

These constraints result in two conditions: either our textures will need empty space to satisfy the first two constraints or they will be too large to fit in a 2048 by 2048 space. Issues, but not deal breakers.

Sprite sheets are fast to animate at the cost of memory. How much memory? Well it depends on two factors:

The size of your texture. (i.e. 2048x1024)
And the format of your texture. (8 bits per pixel, 16 bpp etc.)

Animations running up to three seconds can easily need a 2048 by 2048 texture sheet. For our animations, we restricted our artists to using a limited palette of colors (meaning no gradients). This allowed us to use a limited color space, reducing the bits per pixel by a factor of 2. For each channel of color we used 4 bits (rgba), this gives us a 16 bits per pixel. A quick calculation shows that 2048 * 2048 * 16 ~ 67 MBits ~ 8 MB. Each animation that is open has the potential of using upwards of 8 MBs of memory. On an iOS device, this is a significant portion of the memory available for applications.

When a texture is opened from disk we must first open it into application memory to unpack it from the texture file. We then upload it to the GPU. While uploading the texture to the GPU we now have 8 MBs in both application and video memory allocated for a total of 16 MB of memory for just one animation. A spike of 16 MB is more than enough to set off iOS’s memory warning system. Leading to warnings, or worse, jetsams. (This WWDC video does an amazing job of covering how memory management works on iOS.)

The Crashes

We proceeded to launch with this architecture and unsurprisingly we heard from a lot of our users something like:

“This game is amazing … even with all the crashes.”

Every one of these reviews was like a punch in the soft spot. Didn’t they understand that their app was being jettisoned? It wasn’t my fault, images are big, they take lots of memory! It worked fine on iPhone 4 (lots of memory) and iPhone 3GS (a quarter the resolution) but we were really getting hammered on the 4th generation iPod which was blessed with 4 times the resolution of its predecessor but only twice the memory. We knew why these crashes were happening, but I felt my hands were tied to do anything about it.

The Constraints

Beyond the piss poor app stability, our artists were having to work in an artificial box. In order for animations to fit in the required size constraints they often had to be adjusted or sized down. Want to do a full screen fireball? Sorry, that will take up too much space on the texture sheet. Our artists had to constantly be considering this nebulous limitation imposed by a 2048x2048 packed texture sheet (nearly impossible to judge roughly). Also, not only were the length and bravado of our animations limited, the ‘physical’ size of the monsters was limited. Meaning larger monsters, simply would not work. Sorry fatty…

2D Animations Sucks

The bottom line, 2D animation in a game is hard. Unlike a 3D game where you texture a model once, then sling it around like a digital marionette, 2D animation requires pixel perfect crafting for every frame. Every new angle, new sizing, or even new placement of your art requires reprocessing from raw assets. This can quickly lead to bloated app memory, reduced stability, and oversized bundles.

Dr. Shaderlove or: How I Learned to Stop Worrying and Love the GPU

In part three I will discuss the techniques and technology we used to solve this problem. (Hint: It involves bending the GPU to our will.)

Love the GPU

Thu, 30 Aug 2012 02:54:00 -0400

For many programmers the GPU is a part of the system shrouded in mystery. A realm best left to heavyset bearded types who toil away in the deep recesses of the gaming industry. With all the abstraction on top of the GPU, all but a few programmers can live out their daily lives without so much as a thought about how the things they make are actually rendered. Living behind these abstractions is fine, until you reach a limit, usually one of performance. When reaching these limits it can be really helpful to have a basic understanding of the GPU.

My experience is solely working with OpenGL, I sort of see the GPU and OpenGL as one in the same. I attribute this to my only hands on experience with graphics hardware being carried through OpenGL commands. If I have committed some gross semantic fallacy please call me out on it, nerd.

Function

The function of the GPU is very simple at a high-level. It provides an interface for the computer (CPU) to display colors in a grid on a display. The GPU at its most basic level takes commands from the CPU and sends pixels to the display. How the GPU sends its data to the display is not of much interest to the developer as it is extremely platform dependent and basically inaccessible. The CPU side of the GPUs function is where we take interest.

Interface

Because of the diversity of hardware implementations of GPUs, one basic abstract is usually held. That is that the GPU and the CPU are separate entities in which access occurs over a client/server model. In this case the GPU is the server and the CPU the client. Anytime the CPU wants something out of the GPU it sends a message, usually asynchronously. Anytime the CPU wants data (images) to be drawn to the screen, it must first send it to the GPU. This process is known as upload. In general the GPU and the CPU do not share memory (though they may share the same physical memory, access is limited). Anytime the CPU wants to share data with GPU it must be uploaded. This is one of the first ‘aha’ moments I had when working with the GPU. Anytime your app opens an image file and wants to draw it, that data must first be pulled into memory, converted into raw bitmaps, and uploaded to the GPU. Want to change that image? Fine, but first we must upload a change to the data. Nothing the CPU can touch directly can have an effect on what is being drawn. This leads to some interesting design constraints.

Architecture

When opening up a book on OpenGL for the very first time the reader is often met with a diagram that looks like this. Which an expert on the internals of a rendering pipeline may consider essential to using the APIs. This massively complicated system can be broken down into a few key ideas that help demystify the inner workings of the OpenGL rendering pipeline. OpenGL has some basic abstractions that get used over and over again. The most important of these is probably the buffer. A buffer is just an abstract for data storage, usually arranged in a visual way (i.e. x and y). One of the very important buffers in the pipeline is the framebuffer. Framebuffers are encapsulated rendering destinations. There is typically a default framebuffer which renders out to the screen. An application can have several framebuffers used for drawing to textures as well. More on this later. The second of the important objects in the GPU is the texture. A texture is simply a raw data buffer, living in the GPU. Textures most commonly come from data uploaded by the GPU but can also be generated by the GPU itself.

Drawing

How does the drawing actually occur? Well, for the most part, each ‘frame’ the CPU issues a bunch of commands, that boil down to, draw this texture here, draw that texture here, etc. (things are different in the case of a 3D application but similarly simple). The CPU binds to the framebuffer it cares about, issues commands to draw certain textures or primitives, and thats it. If a single framebuffer is being used, the rendering loop is just that, bind, draw, display, 60 times a second or so. If multiple framebuffers are in use the order of things may go something like, bind framebuffer that renders to a texture, draw things, bind main framebuffer, draw rendered texture, present main framebuffer.

Shaders

So we have buffers of image data on the GPU (images) and we have a place to draw them to (framebuffer) how does the pixel data in texture actually make its way to the framebuffer? Once the positioning and depth of the contents of pixels in the destination buffer have been decided, the GPU uses (on a programmable pipeline at least) a small program called a shader to determine what color actually ends up in the destination buffer. Shaders started out as assembly programs written for specific graphics hardware to control the behavior of the rendering pipeline at the lowest level. OpenGL Shading Language (GLSL) allows the developer to use a C like language to tell the GPU exactly how every fragment should be processed. This is where the magic of getting the GPU to do what you want lives.

Bending the GPU to Your Will

Lets say you have a 2 2D arrays of data you need to perform an operation on. Say you need to, for simplicity sake, average the corresponding fields in each array. If you were to do this on the GPU it would look something like:

for (int x < WIDTH) {

for (int y < HEIGHT) {

result[x][y] = (array1[x][y] + array2[x][y])/2;

}

This would get the job done, while blocking the CPU, not taking advantage of several cores etc. You could rewrite this to take advantage of multiple CPUs or you could just let the GPU handle it, the CPU is built for doing operations on multidimensional data.

To do this same thing on the gpu you would first upload each array as a ‘texture’:

glTexture2D(array1);

glTexture2D(array2);

You would then render an object of similar dimensions as your array, and use as a fragment shader something like this:

glFragcolor.r = (sampler2D(array1).r + sampler2D(array2.r))/2;

Now, if we rendered this to a texture we could then download the texture from the GPU and bam, we have our array of averaged data.

This example is a little contrived, but the GPU is an amazingly powerful piece of hardware that is often underutilized. Doing image manipulations, realtime video processing, or crazy data crunching can take advantage of the power of the GPU.

Further Reading

If you are interested in getting deeper into the OpenGL stack, start with the red book. It didn’t really make sense to me until the 4th of 5th time cracking into but it is really thorough and covers OpenGL and graphics hardware completely.

For some cool tricks with shaders you may want to checkout the GPU Gems series of books. Amazing tricks and hacks for bending the GPU to your will.

Stay tuned, in a future post I will reveal how, by bending the GPU to our will, MinoMonsters is able to bring 4 monsters to life in full animation on a mobile device.

Merry Christmas

Tue, 14 Dec 2010 18:38:32 -0500

Merry Christmas

Jake and Sarah are in Europe

Tue, 24 Aug 2010 03:58:17 -0400

Jake and Sarah are in Europe

A Man After My Own Heart

Mon, 12 Jul 2010 10:58:21 -0400

[Steve] draws a rectangle. ‘Here’s the new application,’ he says. ‘It’s got one window. You drag your video into the window. Then you click the button that says burn. That’s it. That’s what we’re going to make.’ “

Customer Service

Fri, 09 Jul 2010 11:48:19 -0400

Every morning I wake up and go downstairs to the coffee shop in my building. I order 1 iced coffee and 1 banana. Today, as I was walking away, nomming on my banana I soon realized that the inside of said banana was black, rotten, and inedible. I usually don’t complain about a minor disappointment in food service because it usually means a lot of work for the staff. If say my dish was not to my liking exactly, I am not going to demand another dish. Who cares, its still food.

But this was different.

I had ordered a banana which would be only food for the next 4 hours or so. Without this banana I was likely to have a terrible morning of zombiness and hunger. I returned to the counter and kindly showed the barrista that, after biting the first few inches off my banana, the center of the banana was rotten. Not mushy, extra sweet, over ripe rotten but the kind of rotten that makes you expect a worm to emerge.

“Hey, this banana’s rotten in the middle, can I grab another?”

“WHAT? AFTER YOU ATE HALF OF THAT ONE?”

“I’m sorry?”, I say, slightly confused.

“Yeah take one, its fine, don’t worry about it.”

“Ok…”, I sheepishly grab what looked like a fresher breakfast banana.

Why do I feel like the asshole here?

You sold me a rotten banana, which, who cares. Its hard to guarantee fruit, but, do not sell me rotten fruit and then scowl at me for kindly asking for replacement.

Kiss your customers ass. They are your boss.

I hope Buckeye Donuts sells bananas.

String Theory

Mon, 22 Mar 2010 16:23:23 -0400

“If we zoom in far enough, we see that the particles are actually little rubber bands.” - Complete Idiots Guide to String Theory

This is so wrong. This implies that there is some magical phenomenon that would allow you to directly observe the physical structure of a string. It cannot be observed, so don’t imply that it can. You should say that particles act as if they are made up of tiny strings vibrating at different frequencies.

SEKURITY!!!!!!!

Thu, 28 Jan 2010 09:44:57 -0500

I get this emails every couple of weeks, they crack me up.

Sometimes I get emails about space security, those are even better.

For more information on the presentation topics or to a electronic copy of the brochure by email.

3rd Annual
CYBER SECURITY CONFERENCE

Emerging Strategies, Challenges, Needs & Technologies

Washington, D.C. - March 23-24, 2010

FEATURED PRESENTERS INCLUDE:

- Mr. Tim Harp, SES Deputy Assistant Secretary of Defense for C3ISR & IT Acquisitions

- MG Susan Lawrence, Commanding General, NETCOM/9th Signal Command, US Army

For more information or to view the conference speakers, please visit our website: http://www.ttcus.com/cyber-security/

Plus Over 24 Leading Experts from: DASD/NII, NETCOM, NCDOC/USN, AF/24th, DHS, USCC, Joint Staff, NIST, US CERT, DoJ, NSA, FBI/NCIJTF, Cisco Systems, Harris Corporation, Deloitte, BAE Systems, Northrop Grumman, Intel, Boeing, General Dynamics, Mantech Security & Mission Assurance, IBM, US Cyber Consequences Unit, and RAND Corporation examine:

- Latest DoD & Government Cyber Security Policies, Strategies and Imperatives

- Understanding Current Threats to DoD and National Networks & How to Defend against Them

- Emerging IT Procurement Requirements & Acquisitions Strategies

- Learn the National Vision for Critical Infrastructure Protection, including Homeland Security and Energy

Sponsored by American Institute of Engineers

Coordination by Technology Training Corporation

For sponsorship or to exhibit please contact mmin@ttcus.com

To be deleted from this list - please reply with writing “cancel” in the subject line.

Technology Training Corporation
1960 East Grand Ave, Suite 1225
Los Angeles, CA 90245

Green Rectangle - A distributed payment and commerce...

Tue, 01 Dec 2009 15:44:51 -0500

Green Rectangle - A distributed payment and commerce system.

Highly scalable. Offline cashing. Guaranteed transactions.

The future of giving people money.™

Investor? Contact me.

First Instrument Lesson

Thu, 29 Oct 2009 17:59:57 -0400

On October 28th I had my first instrument flying lesson with Kathy. An instrument rating is a much different than the private certificate. Getting your private certificate you spent most of your time learning how to fly, straight and level, climbs, descents, turns, landings, etc. These are considered primary skills. Just like dribbling and passing are to basketball, basic ‘stick and rudder’ skills are the back bone to the rest of your flying game. The private certificate only required a limited ability to do other, more precise, activities. Basic instrument flying is taught in the primary training. Basic means: if you aren’t paying attention and fly into a cloud, do this and you won’t spiral into the ground.

Flying on instruments, then, could also be considered a primary skill. During primary training, you learn to fly the airplane on reference to what you see outside. By referencing the angle between the wing and the horizon you can determine your pitch and roll of the airplane. By this method you learn to do all the previously mentioned ‘primary skills’. Instrument flying requires you to disregard the sights and sensations that you learned fly on and to rely on the mechanical gadgets that are in the cockpit. More than just disregard these sensations you must teach yourself to ignore them. The mind is incapable of sensing its orientation and motion without visual reference. Often you find yourself thinking you are in an orientation but the instruments tell you something different. Your body feels like its turning but, in fact, the instruments say otherwise. The first time this happens can be very disconcerting.

When flying on instruments, the outside world and your relation to it are summed up with the following picture.

From left to right we have:speed, orientation, altitude, rate of turn, heading, rate of climb.

The most important instrument of all of these is the attitude indicator (top middle). The attitude indicator has replaced the comforting view of the ground that was used when first learning how to fly. Done right, the attitude indicator is all that you need to keep the dirty side down and the pointy end forward. With the attitude indicator you would be able to tell how you were oriented in pitch and role but the it provides no indication of direction or heading. The heading indicator, directly below the attitude indicator, provides this.

Using these and the other 4 instruments an instrument rated pilot is capable of flying the airplane from point A to point Z with only seeing the airports at each end.

Yesterday I had my first lesson to become an instrument rated private pilot. A cold front had just moved through and a low pressure trough settled across the mid-Ohio region. This caused instability which lead to an overcast cloud layer at about 1000 feet above the ground. A terrible day for visual flying but excellent for an instrument flying lesson. Kathy filed a flight plan for us and actually handled most of the procedural things. When flying on instruments, you can no longer use the ‘see and avoid’ method of not running into other airplanes. The burden of providing separation then falls on the controller. The controller is responsible for keeping you and other aircraft from trying to fly through the same spot. Because flying on instruments requires this added layer of protection, a flight plan MUST be filed with specific intentions declared. The controller can then do what is necessary to provide separation.

Kathy handled copying our clearance from clearance delivery (a controller) and I handled calling ground and getting the airplane started, off the ramp, and into the sky. Once airborne we were given our usual turn north and handed off to the approach controllers from the tower. (The tower only controls who can land or not, the approach controllers actually handle the people in the sky.)

At some point in our climb out we flew some place I had never flown before: the inside of cloud. And for anyone interested, the inside of cloud looks something like this:

Very little to look at.

From here we continued to Appleton, a navigational beacon used for aviation. We practiced holding patterns for about an hour. Holding is basically flying around a point, waiting for further clearance.

Instrument flying is a very different ball game, much more cerebral and precise than what is required for visual flying. I am continuing with the instrument rating because:

1. I am a sucker for learning new things

2. It should serve to make me a better pilot

3. It gives me an excuse to go to the airport and fly

4. It is another rating that will never expire

So here I go again. The celebration of my new certificate has been pushed to the wayside as I dive into the books again and go from knowing an entire subject to being a neophyte. But this is the stuff that makes me tick.

( I will be writing a post shortly on my use of FSX as a training aid: the hardware, the software, and how I use it. )

Learning to Fly

Sun, 25 Oct 2009 21:13:00 -0400

Today I completed my private pilot training by passing the private pilot checkride. It has been one of the most fulfilling experiences I have ever had. I began my training this past summer. I decided I wanted to take lessons, this is going to sound really nerdy, after playing Microsoft Flight Simulator all winter and becoming slightly obsessed. Eventually, the rush of a playing a game about flying wore off and I sought more. I played around with the idea of taking lessons for a few weeks. I really wanted too but was afraid mostly for my safety. I mean, people die in these things all the time, right? I dug into some research, trying to justify to myself (mostly Sarah) that flying little airplanes was safe enough. After searching around and reading many peoples’ take on the question I came across a statistic that put me at ease. The chance of the average american dying of an accidental death is about 1 in 20. The chances of a lifetime pilot being killed by flying is 1 in 50, less than the normal accidental death rate. So, the chances of dying in an accidental death OR dying in a plane crash can be calculated by the sum of the two probabilities minus the product. This brings my chance of accidental death from 5% to 7.9%, I can live with that (just don’t tell my life insurance provider).

Once I’d convinced myself that I wasn’t putting myself in harm’s way, I set out to find a flight school. Turns out if you punch ‘columbus flight instruction’ into the googles the first thing that pops up is ‘Columbus Flight Instruction’. (Awesome SEO, right?) It intrigued me because Kathy, the owner and sole instructor, operated out of Port Columbus, an airport dominated by airline and corporate jet traffic. Rather than letting this scare me away I thought it would be a good learning environment. I thought: learn to fly with and talk like the big boys right away, and you won’t develop a phobia of large airports. Also, Port Columbus is the closest airport to my house, another very important criteria. Long, frequent drives can put a damper on your attitude.

I filled out Kathy’s online form and the next thing I knew she called me to schedule an introductory flight. This happened on June 26th. Kathy took me up, flew around downtown, went out of town a bit and turned around. After we landed, Kathy asked what I thought. At this point I knew it was something I was going to do. That day I bought a log book, a text book, plotter (for navigation), slide rule (for performance calculations), and some charts.

After this I scheduled as much time with Kathy as possible. Every day after work that was available I would snatch up. I wrote an iCal script to send an email automatically, two weeks in advance to schedule a lesson. (Kathy only schedules two weeks in advance.)

Everything went swimmingly until we started doing landings. Landings are hard, this is something you learn very quickly. It is hard to take a object moving at 60 MPH, that has 6 degrees of freedom, and put it on the centerline of a piece of pavement without hurting anyone or anything. After about 30 or so landings you start to get it. I would say it is about as hard as parallel parking a car. Really hard at first but is a skill that can be improved. And just like parking, sometimes you just don’t get it right and you have to try again (go around)

Eight lessons after the intro flight and 70 landings later, Kathy had me pull over to the ramp, got out of the airplane, and let me solo around the pattern. An exhilarating experience that is deeply etched in my memory. When you first lift off the ground you are filled with this sensation of ‘Oh my god. What have I gotten myself into?’ Then, after landing safely, you taxi back to the ramp and realize that your knuckles are white and your knees start to shake.

From here things moved into the ‘post solo/pre cross country’ phase. We learned many different things, not all pertaining to ‘stick and rudder’ skills. Things like, radio navigation, charts, uncontrolled airports, simulated instrument conditions, short and soft landings, emergency procedures, etc. In the mean time Kathy and I did two ‘dual’ cross countries in preparation of the solo cross countries required for the certificate. These were to Cincinnati and Holmes county. After completing these Kathy endorsed me for my solo cross countries. We ended up doing a short one to Sidney, Ohio on September 14th, and a long one to Findley and Mansfield on October 5th. The rest of our time consisted of reviewing for the flight test and doing ground preparation for the oral exam.

On October 18th, Kathy endorsed me to take my flight test and on October 25th I received my private pilot’s certificate.

It wasn’t cheap, but also wasn’t absurdly expensive. For anyone interested I am going to detail the total costs for me to receive my PPL, along with other metrics.

First Lesson: July 5th

Certificate Received: October 25th

Total Period: 112 days

Number of Lessons: 35 + 6 Ground Lessons

Total Hours: 62.9

Solo Hours: 11.5

Rental Costs: $94.25 per hour

Instructor Costs: $45 per hour.

Total Instruction Cost: $8,565

Materials (books, headset, charts, etc.): $500

Examiner’s Fee: $300

The costs are high. I have spent the majority of my income this summer on getting my license ( and aviation related iPhone apps), but I do not regret doing it. Being a pilot is something you never lose, as long as you have a biannual flight review by an instructor and can pass a medical exam every five years you will be a pilot for life. If you are considering it at all, just do it. Save the money up first, and do it. The more compressed the training the more you retain and the faster it will go, ultimately saving you money. Putting the time in on the ground will also save you a lot of time. Read aviation books, find some aviation related mailing lists or forums, listen to aviation podcasts (Uncontrolled Airspace is great, some very experienced and colorful hosts.), look at airplanes that are for sale, join AOPA and/or EAA, watch One Six Right. Being immersed in the subject really accelerates the training process.

Hope some of you found this information interesting and maybe even useful. If you are thinking about it at all, drop me a line and I will try and convince you to just do it. Drop me a line even if you aren’t thinking about and just want to tell me how crazy I am.

"I dunno. Guy’s a million times more intelligent and successful then I’ll ever be. But I kind of hate..."

Tue, 06 Oct 2009 17:26:56 -0400

“I dunno. Guy’s a million times more intelligent and successful then I’ll ever be. But I kind of hate how he’s seduced a generation of self-satisfied people with bachelor’s degrees into gorging on his horn-rimmed buffet of insouciantly bloggable cocktail party facts. It’s like meth malteds to the thin-boned lads who worship at his probably large Canadian feet.”

- Merlin Mann re: Malcolm Gladwell

Photo

Wed, 23 Sep 2009 10:10:13 -0400

E. Leonard Jossem passed away several weeks ago but his shared...

Tue, 15 Sep 2009 12:12:45 -0400

E. Leonard Jossem passed away several weeks ago but his shared disk lives on.

Dr. Jossem was an emeritus professor here at Ohio State. He worked on the Manhattan project and a number of other noteworthy endeavors.

Shiny Bird

Mon, 14 Sep 2009 09:36:43 -0400

Shiny Bird

Bike

Wed, 09 Sep 2009 11:40:22 -0400

Bike

Great video for the aspiring home builder or anyone else...

Wed, 02 Sep 2009 16:42:49 -0400

Great video for the aspiring home builder or anyone else interested things of a mechanical nature.

East Arcadia State: 2009 MindSetter Sheet

Mon, 24 Aug 2009 16:54:56 -0400

The dorm in the background is at my alma mater, Ohio State.

youlooknicetoday:

At the dawn of each academic year, East Arcadia State University prepares our instructors and staff by curating some facts and observations about the generational differences that are peculiar to our incoming freshman class. By understanding how the world looks to them, we hope to provide the best possible educational experience. In other words:

How have things “always been” for East Arcadia’s incoming class of ‘13?

First, let’s kick off the ought-niner MindSetter with the hard and painful facts.

Folks, there’s no nice way to put this: many of these kids are young and uneducated.

Recent data conducted by the prestigous Van Hœt Group suggests that many of the 17- to 20-year-old students who comprise the fattest part of our freshman curve are not yet 21 years old; many are barely older than 16. But, it gets worse.

Van Hœt has aggregated, analyzed, and cross-referenced historical data suggesting that as late as September of 1960, at least 40% of the students entering college for the first time did not have a Bachelor’s or Master’s Degree — let alone the extensive post-doctorate experience we all now understand to be critical for the long-term success of dodging costly loan repayments. Today that number is over 90%. You heard right. That’s “ninety.” With a “b.”

So in sum, these kids are mostly under 20, completely hopeless, probably armed, frequently drunk or high on I-don’t-even-want-to-know-what, plus they already can’t afford the education that they haven’t received with the money they haven’t figured out how to not pay back. It’s literally that bad. Today. Here.

But we keep our chins up at East Arcadia. It’s one reason everyone loves scarves and complains of chronic neck pain.

Students entering college for the first time this fall were generally born in 1990. Some were born earlier or later than 1990. Our youngest student is a Fulbright Scholar and surprisingly robust preemie who, because he was born last week (36 weeks pre-term), will be our sole tenant in the spanking new Petri Hall. We think the nurturing culture there will suit “Li’l Jacob” well.

That said, for all of these students, Thomas Aquinas, Rutherford B. Hayes, and Petrarch have always been dead. Bob Hope and Guy Lombardo have always been assumed to be dead (N.B.: both are, indeed, now dead).

Many other people have also been dead, but space and costly mimeograph expenses preclude our typically exhaustive accounting. Thanks in advance for understanding (especially if you’re the obese tenured “atin-lay ofessor-pray” whose entirely avoidable 4th cardiac event singlehandedly sent the entire college’s insurance premiums through the roof. Keep inhaling those pork rinds, Professor. Sic Semper Pork something).

Anyway.

So, our big, annual question: How’s life always been for this year’s incoming class at East Arcadia?

Copper has always expanded when heated. Although, it’s also always been less satisfying as a snack than, say, a Hot Pocket or a slice of cold lamb with a little sea salt and a dash of fresh ground pepper

March has never been called “Burkina Faso” which is one possible reason so few of our students choose to attend Spring Break on whatever continent that place is

Phones have always had some sort of technical facility for sending and receiving the sound of the human voice while one is nude, dining, or just quietly masturbating to a well-loved 1978 facebook

Elephants have always been the one thing most people associate with Hannibal’s famous attack, although almost no one knows why, but they still sing that song “Baby Elephant Walk” and make really obvious Silence of the Lambs jokes until security arrives

Golf has always been a costly diversion for tedious white people who dislike their children, but enjoy drinking near sprinklers and pesticides

Anilingus has always been something many people of all ages are nervous to ask for (even if it’s for an anniversary or your birthday or because you literally caught your so-called “spouse” doing it to a civil servant like she was eating corn on the cob and Jesus Christ right there in your own goddamned house where your fucking kids sleep at night. Or what have you)

Laser bird shoes and the dangerous nesting boxes that are used to store their colorful waste have both always never been invented yet (for now)

Tattoos have always been more permanent and cost-effective than an equivalently regrettable t-shirt — especially given the rising popularity of the japanese symbol that someone in rubber gloves whom you just met after Tiffany’s “Sex in the City” themed engagement party while you were admittedly pretty drunk has told you means “Um….’one…ness…of…brave…spirit…woman…hearts…and peace.’ Yeah. It’s Kanji.”

Oceans have always been a sloshy, watery, unnavigable presence, teeming with dragons, non-white immigrants, and rich deposits of Lorenzo’s Oil, all floating in completely unknown locations somewhere between the better documented but much smaller big, landy parts of the continent things

Jetpacks and moving sidewalks have always been a lazy way to frame false dichotomies about society, technology, and the complex ways that resource scarcity do or do not hew to century-old pulp fiction and coloring books. Related:

Steampunk has always been a diverting way to make something pedestrian a little less useful by adding a makebelieve brass thing and some polished wood. (Don’t miss our collection of Jules Verne’s infamous “Felching Jars” and “Walnut Poppers” in the rear of the Lisagor Library, [Wing B]. Ask for “Betty”)

Three-card monte has always been a socially acceptable urban application for soiled cards and shoddy, collapsible tables. (FACT: This is why East Arcadia’s marching band still plays Joplin’s popular “Pump the Suckers then Boogie with the Booty Rag” before every football game)

For this class, mentioning the music of Mozart has always been a subtle means to evoke sophistication in a way that many people are too polite to call out as proof that the mentioner is so full of shit because did you know that Amadeus actually has enough plot holes and factual errors that it might as well be called Ooooo, Look at Me! I’m Fucking Peter Schaffer, and Apparently I Couldn’t Distinguish Mozart and Salieri from Fucking Simon and Garfunkel Unless I Had a Goddamned Flashlight, Five Viennese Rent Boys, and a Giant Bouquet of Edelweiss Up My Ass. Wheeeeeeeee, Mozart Something Something!

Lists have always been a great way to turn a bunch of bullshit into some fast web traffic. So listen to an okay funny podcast called You Look Nice Today (iTunes). As the school year begins, you can start out by learning more about East Arcadia in an episode entitled, “Vachina.”

East Arcadia:
E Somnus Cholera. (Et Leonem)

Photo: Thanks to InsoOutso