One of the great new features of AIR 3.0 is native extensions. These extensions allow you to build hooks into the native OS that lets you do some things that AIR doesn’t support on its own. One of the best things about AIR is the fact that it can run on so many platforms, E.G. Android, IOS and the Playbook. However, one drawback to this is that AIR must cater to the lowest common denominator and cannot really focus on device specific features. This is where the native extensions come in. They let you write code native to the device that can tap into the cool features that make each device unique. This means, for iOS you would write the extension in Objective C. For Android you could write it in Java. On Android, this could let you push things to the notification drawer and maybe on a Blackberry you could get access to BBM messages and features. You can find a great tutorial for building your own AIR native extensions for Android at Adobe.

NOT ALL SUNSHINE AND LEMONADE:

The work flow for building your own native extensions isn’t too bad but there are a few caveats. Right now there aren’t really tools for packaging your extensions so you need to know a little bit about the command line and building bat files. The other half of this is that the packaging errors can be a little cryptic so be prepared to spend a lot of time googling random phrases and hoping someone else had the same error as you before.

For example, one of the issues I had was with signing my extension. ADT was attempting to generate a time stamp but it kept failing giving me this error: “Could not generate timestamp: handshake alert: unrecognized_name”. The solution was to include “-tsa none” as a -package option in my package.bat.

A second issue was with adt.bat. This bat file executes \lib\adt.jar however on my computer it was pointing to the wrong path when my package.bat tried to run it. The solution was to hard code the path to the jar file rather than use the aliases.

When you’re invoking the native code in AIR and there’s an error, the AIR debugger doesn’t really know how to deal with that. It can be difficult and downright frustrating to debug something when you’re not sure where its failing.

Lastly, like I mentioned before, one of the best reasons to use AIR is the fact that its cross platform compatible. By their very nature, native extensions are not. However, there are still use cases where you could build something in AIR but use a native extension if the OS had a better implementation. It was this last case that lead me to create a native extension for accessing the sharing API in Android.

ShareExt: AN EXTENSION FOR NATIVE ANDROID SHARING

There are several Actionscript libraries out there for building in links to Facebook, Twitter, Flickr etc… in order to share your content but one of the cool features of Android is that it has a standardized API for this. So if I’m deploying to Android why not use something that the users will already be familiar with? With this in mind, I built a native extension for accessing the share functionality in Android from AIR. I won’t say that its fully featured and functional but it handles sharing most mime types. You can pass it an image, video, audio or other file and it will do its best to share with the right tools. It also supports sharing straight text. I built a really basic AIR app that you can side load on your Android device to try it out. The app uses the built in AIR API for file browsing to find a file to share but when it launches the list of sharing apps that’s all Android, baby. Click here to download. If you visit the link on your device it should download and let you install it pretty easily.

You can find the source code for the native extension and the example app on github if you’d like to play around with it. The folder ‘extension’ houses the two halves of the extension. The folder ’shareAirExt’ has the code for the Actionscript part of the extension while the ’shareJavaExt’ has the Java portion. I’ve also included my .bat file. Its mainly taken from the tutorial I’ve linked above but it might be useful to have a working reference.

Once you’ve built the native extension, using it in Actionscript is a breeze. It acts just like any other object from a SWC or library.

/*
Instantiate our Native Extension and share our file with the native extension.
*/
share = new ShareExt();
share.shareMedia(file.name,file.nativePath, mimeType);

WHATS OUT THERE NOW:

Native extensions are the hot new thing right now and developers have only just started to scratch the surface of what can be done. At gotoAndLearn(), Lee Brimelow talks about building a native extension for pushing to the notification drawer on Android.

This example, from Todd Anderson, shows how you can build a native extension to get battery information on iOS.

At as3NUI they have built a native extension for using the Microsoft X-Box Kinect in AIR. This is coolest thing yet and really shows the power of native extensions in AIR. AIR and Actionscript is already a great environment for making games so hopefully, with this great new extension, we can start seeing some Kinect games and installations built in AIR.

Speaking of games Milkman Games has built a iOS native extension for using Game Center in your AIR apps. This should mean a more unified experience of AIR apps on iOS.

This is only the beginning and I, for one, am excited to see what comes next.

UPDATE ON JAN 5th, 2011:

I committed a packaged version of the ANE file to the github repo. You can find the repo here. Or, if you’d prefer, you can download the ANE file directly by clicking here.

When I first heard of PixelBender I was so stoked.

PixelBender is a shader language built for Adobe products. You notice I say Adobe products and not just Flash. Pixel Bender can be used with Photoshop and After Effects also. (probably other products too)

Basically a shader is a “filter” that can be run over an image or data. To get started with PixelBender it’s best to start out with images rather than with data cause it will be easier to get the hang of things.

I’m really surprised we haven’t seen PixelBender being used more in Flash. You can write some really amazing effects very quickly. Of course you could write the same effects using BitmapData however PixelBender will be much faster. Most things in Flash currently only run on one core of your computer. So when you are doing calculations on BitmapData objects it will run on one core. Most computers have multiple cores today and PixelBender is able to run evenly across all your cores. Of course most likely in the very near future PixelBender will be running on the GPU instead of the CPU, which is even better.

So what can PixelBender do (click below):
(Please open the article to see the flash file or player.)

Here’s the PixelBender code to get this effect:

It may look a bit scary because it looks nothing like AS3 or JS or another scripting language. But basically how it works is that this code will run over every single pixel of whatever is passed to it. This is performed in the evaluatePixel function. With this filter we have one image that’s passed to it which is called src.

You can see src defined being defined near the top of the code:

So you may have noticed that with all the variables type comes before the variable name. This is because PixelBender is a C-Style language. What we are saying here is that we’re going to be passing it an image that has four colour components: red, green, blue, and alpha.

In turn right below where we declare the input we define the “output” which is a pixel with four colour components:

Under those two declarations you’ll see a whole bunch of paramaters. Parameters are important! They are the variables that will be accessible in Flash. So if you check out the SWF example you’ll see sliders that are effecting these parameters.

Cool things in the PixelBender language:

• Don’t have to write a lot to get cool stuff
• You can perform calculations on objects with regular data types (float4 col; col+=3.0;)
• Very very fast

Gotchas:

• No looping in PixelBender Flash (there is a bit of a hack that I might talk about later)
• When using floats/Number data types you always have to use “.” so for instance 0==0.0
• float4 is the same as Pixel4
• Hard to start thinking of evaluating pixels and not “pushing” pixels

To get started with PixelBender visit this page:
http://www.adobe.com/devnet/pixelbender.html

So you’ve watched some videos on Unity’s site and you have sort of a grasp on creating scenes.

But now… It’s time… To code! Where do you even begin?

About a half a year ago or so I ended up having to jump into the wonderful world of Unity3D. I literally went through the path of looking at all the resources and video tutorials on the Unity site. By looking at the tutorials and example projects you’ll get a really good grasp of how to make things in Unity.

There’s one thing that was a bit confusing, even after looking at all those resources I mentioned above, and that was the architecture of the Unity3D libraries.

I think the biggest confusion could be if you’re coming from a typical Object Oriented work environment the Unity environment can be a bit odd.

Let’s for instance create an “animal” in a regular OOP environment.

You’d make a base animal class and add functions that represent behaviour of the animal. For instance the functions could be: walk, eat, and poop.

In unity however it’s preferred that you create a “behaviour” class and add it to the animal. So your behaviour class would have functions like: walk, eat, and poop.

So here’s where it gets interesting…

In As3 and other oop languages you would extend animal to create a new animal. For instance if we wanted to create a Dragon object we’d extend our Animal class which has the functions for walk, eat, and poop. After that we’d write a new function breatheFire to the dragon class. So we’re good to go we have a dragon.

Like I stated above in Unity you’re encouraged to create behaviours more and add them to objects. So what we’d do is keep the basic animal behaviour: walk, eat, and poop separate from the breatheFire behaviour. So we’d have two classes AnimalBehaviour which has the basic animal functions and another class FireBreatheBehaviour which is separate from AnimalBehaviour. When we have those two behaviours we can drop them both onto our dragon object and we have a dragon.

So you might be saying at this point what’s the difference? Well let’s say we had another animal the good ol domestic cow. However we want this cow to be able to breathe fire. Well in As3 what we’d have to do is recreate the breatheFire function in the cow class and most likely it would be the same as the function in the Dragon class. It’s a huge waste having to do this type of thing. Why would you code the same thing twice?

In unity if you want to create a fire breathing cow all you’d need to do is drop the breatheFire behaviour onto the cow in the same way as the dragon.

Of course the way Unity works has some flaws. For instance if you were creating very unique behaviours they can’t be applied to EVERYTHING. However overall because of this architecture decision it makes coding for Unity very very enjoyable. Not to mention the fact that you can choose which language you will code in. (C#, Javascript, Boo)

There are different ways to handle compression for the web but here we’ll be looking at unzipping using Flash.

Flash doesn’t handle zip files natively but there are a few libraries available that will add support. The one we’ll be using here can be found at nochump.com

First off we need to actually load our zip file:

private function loadZip():void{
    var loader:URLLoader = new URLLoader();
    //since flash doesn't know what to do with a .zip
    //we need to make sure it just loads it as a
    //binary file so it doesn't try to cast it as text.
    loader.dataFormat = URLLoaderDataFormat.BINARY
    loader.addEventListener(Event.COMPLETE, onLoadComplete);
    loader.load(new URLRequest("main.zip"));
}
private function onLoadComplete(e:Event):void{
     //do stuff here
}

Once we have our zip file loaded we can begin to manipulate it to get at the delicious compressed data it contains.

private function onLoadComplete(e:Event):void{
        // get our data from our loader
        var loader:URLLoader = URLLoader(e.target);
        //create a new Zipfile and pass it our data to decode
	var myzip:ZipFile = new ZipFile(loader.data);
}

Each ZipFile has a property called entries which is an array of ZipEntrys. Each file in the zip has a corresponding ZipEntry. A ZipEntry is basically a data object that contains the file name, size, last modified date and a couple of other properties about the file. To trace the first file name we could just do this trace(myzip.entries[0]);
To actually get at the data we need to use the method ZipFile.getInput(entry) which returns a bytearray of our file.

var entry:ZipEntry = myzip.entries[0];
var data:ByteArray = myzip.getInput(entry);

Once we have a byte array there a few different ways to decode our data. For this example, my zip contains an xml file. We need to convert our data to an XML object. This is surprisingly easy.

var myXml:XML = XML(myByteArray.toString());
trace(myXml);

If our zip contains images it slightly more complicated. The easiest way is to use a Loader’s loadBytes method. This loads a bytearray and decodes it into the correct type (ASDocs). In this case, jpg.

var myLoader:Loader = new Loader();
myLoader.contentLoaderInfo.addEventListener(Event.COMPLETE, onBytesComplete);
myLoader.loadBytes(myByteArray);				

private function onBytesComplete(e:Event):void{
	var loader:Loader = Loader(e.target.loader);
	addChild(loader.content);
}

One major caveat to loading a zip of images is that its quite CPU intensive. While you do save time on load you can end up waiting for Flash to decode your images for you. Also, zipping a bunch of images doesn’t save much space. It does however cut down on the amount of requests you are making to the server.

And that’s all there is too it. Loading compressed files is a great way to compress your load times and make sure your user can zip on through!

The recent F8 conference has brought some new features that will make facebook users happy, such as the timeline and the ticker, but that also means that there will be more work for developers. It also seems like they are trying to make their api more consistant, with other api’s, and in general, which should make development life easier. Although we know from past examples, that that will be a long road. The facebook roadmap doesn’t show much for developing for these new features, but you can bet as time goes on and demand increases, they will be just another roadblock developers are going to have to tackle.

Developing for Facebook is not the most smooth process out there. I commend them for constantly updating the developer tools and making things more consistent, but when relying on a service for our client work, when things go bad, we notice and our clients notice. This more often than not, involves some form of undocumented Facebook update and subsequent calls from the client telling us about it.

Just recently a fellow developer ran into a bit of a problem with her Facebook application. Its seems like all of the sudden the page was no longer validating like normal and was therefor creating an endless redirection loop of trying to get permissions even though it already had them. It turns out Facebook had just implemented an option in the advanced tab of the application settings called OAuth 2.0 for canvas which was defaulted to disabled. Now if Facebook would have set the default to enabled, there would be no problem and i would not be mentioning it in this post, but it wasn’t and many of our previously created apps were now broken because of it. Its also not like the solution was found right away, it took testing and research to figure it out (not done by me mind you), and then the solution had to be applied to most of our old applications.

Another situation occurred on a completely unrelated application, and this time, the fix wasn’t so easy. In fact, there was no fix at all. A few days after the application launched, we get a call from the client saying the application is no longer working. After initial testing, i realized nothing had changed on our end, and nothing seemed to be different in the application, so that led me to believe Facebook had updated the service and in the process added a bug to the system. After hunting down a bug report and informing the client that we have no control over the current situation, our only option was to sit it out and wait until the service wasfixed. Luckily in this case it was no longer than a day or two, but it’s not easy telling the client we have no control, and heck, it sucks as a developer to have no control over the situation.

When i make a normal website, once it has been tested and pushed live, i generally don’t have to worry about it anymore. But working with Facebook changes that situation. You have to be constantly ready to tell the client that Facebook has changed something and we will now have to find a work around to make the application work again. Not without getting stern phone calls from clients who think we have somehow broken it. I’m not going to go into the long list of problems i have encountered while working with Facebook since they can be found all over the internet (ahem: http://salpy.wordpress.com/2011/04/08/the-wildly-inconsistent-facebook/). I just post this so others know what to expect when working with Facebook and that hopefully Facebook will see this and do a bit more testing on existing applications when updating the platform.

There’s plenty of methods to our madness at Jam3 and we want to share some of that with you at the SXSW Interactive conference this coming year. Give them some love and support their initiatives in the talks they aim to present.

The smörgåsbord of topics range from design to tech to production. We’ve got mouthwatering material on creating tools to implement a creative team’s vision, and theories on how “less code is the best kind of code.” We’ve got an in depth look at audio responsive visualizations, and a little digital storytelling production guidance for you broadcast/film folk to cap it all off.

Our People and Talk Titles:
Mikko Haapoja’s “Less Code More Cool”
Aaron Morris’s “Teaching Laziness: Coding Efficiency for Beginners”
Salpy Kelian and Cole Sullivan’s “Audio Visualization: a DIY Guide”
Adrian Belina’s “Producing Digital Narratives for Brands or Film”

Come vote the shit out of this and support your fellow digital peeps in Jam3‘s epic takeover of SXSW’s 2012 best Interactive Conference Ever.

http://panelpicker.sxsw.com/ideas/index/10/company:jam3

See these quick examples:
cubes
lines
starfield

First off, if you don’t know about Paper.js, definitely check it out, its a vector graphics framework built on top of Javascript and the HTML 5 Canvas element. It gives you the ability to easily draw some pretty neat things, and performance seems pretty great as well (usually runs about 60fps). It takes a bit getting used to, but its an interesting approach to the normal javascript development process. Here is the basic setup.

<script src="js/paper.js" type="text/javascript"></script>
<script src="js/main.js" type="text/paperscript"></script>
<canvas id="draw" width="100%" height="100%" resize="true"></canvas>

As you can see, first you include the Paper.js source file, then you include your code file with the type as text/paperscript. This will setup your basic events and also provide your script with the extra functionality and classes that Paper.js uses. You also pass the id of the canvas element you want to draw to with the canvas parameter. That’s pretty much all you need to get you started. Paper.js adds a lot of new classes to use for drawing and also hooks up your events for you so you can get right to the creative part. A complete api reference is available here. My template file usually starts off with some of the more common events, as seen below.

function onFrame(e) {
	e.time // Time in seconds since the app started
}
function onResize(e) {
	view.size // The current canvas size, in a Size object.
}
function onMouseMove(e) {
	e.point; // The current mouse position, in a Point object.
}

I won’t go into too much detail about the basic javascript code, but i will go over some of the basic drawing techniques I’ve used. Path is your basic drawing class, allowing you to draw lines and shapes similar to the flash graphics engine. To control the look of your Path you set fillColor and and strokeColor (they accept CSS values or the colour classes provided by Paper.js like RGBColor). Once a path has been created, it is in the display list unless you specifically call remove(). You can also add your paths to a Group which allows you to control them all with a single function call. I’ll go over how i drew the shapes in each example.

Lines / Source

Lines are one of the easiest things to draw in Paper.js. Simply create a Path, add points to the line by sending a Point object to the add() function. If you would like your line to be curved instead of jagged, simply call smooth() on the Path. To change the thickness and colour, simply set the strokeColor and strokeWidth properties. Note: the smooth() function must be called any time the points change.

path = new Path();
path.strokeWidth = Math.round(Math.random()*4)+2;
path.strokeColor = STROKE_COLOR;
for (var n=0; n<POINTS; n++) {
	path.add(new Point(width/(POINTS-1)*n,start+i*SPACING));
}

The animation of this is a simple sin wave with a multiplier based off mouse position.

Stars / Source

Stars is also a simple application.

new Path.Circle(new Point(0,0),values.size);
initial.fillColor = 'white';

var symbol = new Symbol(initial);
for (var i=0; i<values.stars; i++) {
	var item = symbol.place(Point.random()*view.size);
}

We create an initial circle using the Path.Circle function passing in the center point and the radius. This time, we create a Symbol out of the circle which basically turns our circle into a stamp. We call the function place() on the Symbol and pass in a Point object to create a copy of the item at that location. Since we do not keep track of each item in this project, we can simply loop through the children of the activeLayer which is a property of the project variable (available by default without having to declare it).

var layer = project.activeLayer;
for (var i = 0; i < layer.children.length; i++) {
	layer.children[i].x += values.speed*item.data.scale;
}

The speed of the particles in this example is controlled by mouse position.

Cubes / Source

The cube creating part of this example was taken from the Paper.js examples, but i’ll try to explain whats going on:

Path.RegularPolygon(view.center, 6, 30);

This function creates a 6 sided polygon that has a radius of 30, simple enough, but to create the 3d colouring effect, we have to parse each segment (each segment being a triangle for each side of the shape) into its own Path. To do this, we run through the segments array and clone() each segment into a path and colour them appropriately. This only needs to happen once, as we are then able to simply clone() the Cube that we have created and stored when we want to make another.

The animation of this is just a simple spring effect with a mouse based rotation applied to the container.

I hope these examples have given you a good primer to get started with Paper.js. Now that you have the basics, you are good to go, let your creativity fly. Paper.js allows you to easily create shapes, lines, and even work with loaded images. There is still a lot of unexplored terrain left for me to explore, but here are a few of the examples i came up with after taking a look through the examples posted on the Paper.js website. I’ve also provided the links to the source so you can see how its done.

View Examples

You can check out the official examples here.

Seem’s like I’ve brought the House Of Cards dataset to almost every platform I work with. So it was only logical to use it with my first experiments with WebGL:


To see it in action click below (you must have a WebGL enabled browser):
House Of Cards WebGL

Click on the options on the right to change the way the model looks.

The setting for rendering tris for edges will toggle what geometry will be rendering so if you unselect edges it will stop rendering the “lines” around the triangles.

The colour setting will change the way the model looks. By selecting “Use Model Colours” it will use the colour “intensity” values from the RadioHead dataset. If you select “Use Solid Colour” it will shade the entire model with one colour that is lit with a directional light. Selecting “Show Normals” will render the triangles based on the Normals of the vertices.

Under animation you can turn on and off the wave motion.

This was a fun small experiment but I learned a lot doing it. I’m not 100% sure the Normals were calculated correctly but it seems like it. Regardless… I like how it turned out.

I think Google liked it too since they decided to put it on Chrome Experiments:
http://www.chromeexperiments.com/detail/radiohead-webgl/

However, when you finish writing it you realize that it took you twice as long as it would have if you didn’t worry about horizontal and angled scrolling. Also, now when you use the scroll bar it now takes twice as much set up time just to get a vertical scroll bar. Let’s say instead of 10 minutes, it now takes 20 minutes.  This isn’t a huge deal most of the time but in aggregate it is. If you use the scroll bar class 10 times in one year you’ve spent an extra hour and forty minutes on it. A better idea would be to code a vertical scroll bar and extend the class when you do need the rare horizontal scroll bar.

This is what i call coding for the 90%. This should be your guiding principle when writing code. Worry about the 90% of cases, and deal with the other 10% when it comes up.

This principle can also help guide API development. When creating an API its important to think about how a person will use your API in the future. Rather than include a million constructor parameters to handle every use case think about whats the most important. It may not take much to develop that class but if every time someone uses it they need to configure 10 different options, a lot of time is lost. Like my previous post on writing reusable code, following the 90% principle can help you pick your battles when it comes to writing reusable code. Not everything has to be resuable, just the things that you use a lot.

When I first saw the creative for the site I started thinking “How will we pull this off in HTML?”. As the previous post stated we took quite a few test routes before deciding on doing everything using canvas. Once we had decided on the Canvas method I developed Jam3D.js quite quickly. I think the core of the engine was written in two days or so.

You might be asking why didn’t I just use another 3D engine that’s out there. Well… Generally with projects that have a tight timeline or are high profile I’m scared to use other peoples tools/code. Especially when it needs to be optimized as much as possible. It’s very hard to optimize someone else’s code vs your own. Sometimes to optimize code you have to know every nook and cranny of the code. That’s not to say I don’t EVER use other people’s libraries. (I do look forward to playing with ThreeJS though)

When I was writing Jam3D.js I knew we had to optimize as much as possible but still keep it flexible. To do this you have to keep things as simple as possible.

If you look at Jam3D.js you’ll notice that its really just one array of 3D (x, y, z) points that is being transformed by a 3D transformation matrix and an array that represents those 3D points transformed into their 2D form (x, y). You can’t get more simple then that.

I kept these point arrays as one dimensional arrays of numbers because I wasn’t sure how intensive it would be to do two dimensional lookups on a Javascript array. At every point when developing something that’s processor intensive you have to think of these small details.

In order to keep our sanity we created four classes to help us modify and render Scene3D’s point array. These four classes being Vector3D, Line3D, Circle3D , and CurvePath3D.

Vector3D was the class that would never make an appearance on Björk’s stage, it would never be rendered, but it was used to create all the 3D objects and also used for some calculations in the site. Vector3D is sort of like a 3D point… It has properties such as x, y, z position but I also added in two properties x2D and y2D. x2D and y2D were getters that “reached” into Scene3D’s transformed 2d point array to grabed the “2d” version of a position. Actually the 3d positions also “grabbed/pushed” their values from the Scene3D array.

This simplest shape that we rendered/drew to Canvas I would say was Circle3D. Circle3D really just had two properties one Vector3D and the radius of the circle. Because we were dealing with perfect “spheres” in this site we didn’t have to calculate anything else beside’s the location of a circle/spere. Actually I think because of this the Circles were the fastest item’s to render to screen. Really with just a minimal performance hit.

Line3D you could guess was quite simple too. It really just contains a start and end position vector3d.

Curve3D was the most complex 3D object we were rendering to screen and really was the only one I wasn’t super confident writing. Up until this point I had never written 3D curves. I was a little bit nervous because in actuality it’s not even often I write code to render 2d curves. HAH… But after a bit of experimentation I realized we could render Quadratic or Bezier curves in 3D.

Curves in computer graphics are defined by a starting point and end point and a point that “effects” how we will curve in-between those
points.

Well to be honest the above is a Quadratic curve. A bezier curve has two control points or points that “effect” the curve.

You might’ve noticed that I speak very vaguely about the control point effecting the curve and really because it’s actually very hard to distinctly say how it effects it. The equation for a Quadratic curve is quite simple but it’s hard to judge quickly what a curve will look like by just knowing the the start, end, and control point of a curve. (for you who’ve used Illustrator will know) And because of this reason I was very scared to start coding 3D curves. But it turns out if we translate the 3D points for the start, end, and control point to 2D it looks just fine. Just the way it’s supposed to. Who knew???

So to recap how this whole thing works… We have a Scene3D which contains some arrays defining 3D and 2D positions. Then we have a few classes that hook/reach into those arrays to modify and set those arrays.

But who does the actual rendering? When you write a simple 3D engine like Jam3D.js you have to make the decision will the Scene render objects or will the objects themselves render themselves. If you choose to have the Scene render the items your engine may perform a little bit better but you’ll always have to define how things are rendered in the scene and it’s hard to add in new types of items to render. To be honest at this point I was a bit nervous the creative for Bjork would change and we’d have to start rendering new types of items so I made the decision to have objects render themselves and possibly take a small performance hit. These types of decisions only really happen when dealing with clients but luckily they never wanted new types of items to render.

One nice thing about the creative for Bjork was that all the items are white. You couldn’t tell if the white circle that was in the distance was actually in front of the white line in the front cause they were both white. This was nice because we could skip Z-Sorting completely. This helped a lot since Z-Sorting can be one of the most processor intensive operations.

I knew that I didn’t have a lot of time to write out the Björk site and so I decided that I wasn’t going to write Matrix3D class. Luckily I found a great Matrix class written by Masayuki Daijima Matrices scare people a bit if you haven’t worked with them much. But really you probably all learned this stuff in grade 10 math. HEH. Really matrices are just a set of equations to transform points. (http://en.wikipedia.org/wiki/Rotation_matrix )