WHAT IS A NATIVE EXTENSION?

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.

The first time you open up Unity3D it might be SUPER intimidating. You have an entire 3d “modeler” in front of you and you think “where do I go from here?”.

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)

Load times are a Flash Developer’s nemesis. Even today with download speeds measured in megabits per second, a good developer has to be wary of how slow things are loading. A popular way of speeding up load times are to use a CDN like Cachefly or Amazon. However, these services do cost money and often charge by bandwidth used. An alternative way to speed up loading is to compress your files into a zip file.

This can help load times in a variety of ways. Firstly, downloading a compressed file means less data needs to be transmitted. For example, to build the main voxel model for our site (www.jam3.com) we download a file that is roughly 2MB uncompressed. If we zip it, we can get it down to 25KB. While 2MB will only take a few seconds to download on a high end connection, it is a lot to download on slow one. Secondly, if you compress multiple files in the same zip file you can limit the amount of requests the client and server have to deal with which adds a lot of overhead. If you are downloading lots of little files these small handshakes can add up to a lot of time and every bit helps.

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!

I hate to keep bringing up Facebook, but when you spend a lot of time working on Facebook applications, its the thing that comes to mind most often. And it may seem like I’m continually bashing the platform, but you must agree, a blog post praising Facebook would be much less interesting and much less informative. So here we are.

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.

Jam3’s looking to invade SXSW Interactive in 2012, and we have more ammo and explosive content than a Michael Bay flick.

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

When working in the realm of html, css, and javascript, browser consistency can be a major headache, especially if you are still forced to support the evil known as Internet Explorer 6. But there are a few things you can do to make the process a little easier on yourself. Below I’ll be sharing some of the things that have helped me when building websites for multiple browsers and platforms. Keep in mind though that implementing these are best done before starting a project, they may do more harm than good on an existing website.

First off we will start with CSS. This first one is a bit controversial, some people swear by it, some people hate it, all i know, it helps me out a lot. Using a reset CSS helps make all the base values for things like margin and padding equal across all browsers. Some people claim they end up having to write more code when they have to re-declare bold tags and what not, but the benefits far outweigh the negatives. Starting with a clean slate makes development from that point much easier and removes the need for browser specific hacks. You can also remove some of the reset values to make it more suitable to your development style, all in all, a great way to start off a project. Although, adding this to a preexisting project can cause more problems than it solves. The one i use most is available here.

Another tip for using CSS is avoiding the use of floats. Floats i find are rendered differently in most browsers so i find it best to simply not use them whenever possible, instead relying on positioning elements with top and left. I understand sometimes you may have to use floats, i just prefer to limit they’re use. A tip for using positioning, setting the position to absolute will set the start point of your top and left values at the top left of the browser, but if you set the container div to position relative, the container will still be in the same position, but the absolutely positioned div will have it’s start point set to the top left of the containing div.

Its also important to note the use of z-index on Internet Explorer 7 and earlier. Each positioned element in IE creates a new stacking order, starting from 0, instead of using a global stacking order like most browsers. This can cause problems when you want one element to appear over another, but it is nested deeper in the page. The best way to solve this problem is to keep z-indexed elements on the same level in the html, or if you wish to have it appear over all the content, simply place it right below the opening body tag.

As for HTML, the only real change i make is setting the doctype. Whenever i generate a new HTML page, i make sure the doctype is strict rather than transitional (sometimes set by default). It forces Internet Explorer to behave more like the other modern browsers and generally just makes development easier, This will also most likely give you some problems if changing it in a preexisting project, so its best to start from scratch with this one. The most common doctypes i use are:

HTML: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

XHTML: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

As for Javascript, my best advice is to pick a library and stick with it. Most common Javascript libraries already take into account browser differences so creating functionality for your website becomes a lot easier. From my last post you can probably gather that i am a MooTools guy, but jQuery works just as well in this area, just try not to use both in the same project.

If your starting a project from scratch, take some time to setup a few of the things i have mentioned, and i think you will find you’ll be spending a lot less time doing the terrible chore that is browser testing. I take no responsibility for any headaches you get from implementing these on an existing project

If you have any other tips for taming the web, please add a comment below.

I know I’m not the first to delve into the world of Paper.js, but being such a new technology, i figured it was worth a look. Not to mention that you can do some pretty neat stuff with it on any canvas enabled browser.

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:
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/

If there’s one thing I’ve learned during my years as a Flash developer its that we’re lazy. Coders are always trying to find ways to make their work easier and to write less code. The most interesting thing about coding is that the more experienced you are the less code you probably write on a day to day basis. There are a variety of reasons for this. One reason is that the code they write is simply more efficient than the code written by a less experienced coder. Another reason is that senior coders have been around for so long that they’ve simply written it already. However, the biggest reason I think is having a mindset of always trying to solve the problem with the least amount of work.

A lot of coders want to write code that can be used in 100% of cases. Think about it, you write a function once and you every time you want to accomplish that task you just copy and paste. It’s perfect. This is the holy grail of coding. If you can accomplish this it leaves you to concentrate on only the unique/fun parts of the project. The problem with this is that it can trap you.  Imagine a scenario where you need a have a large piece of text that needs a scroll bar. Realizing that a scroll bar is something you will use again and again you decide you want to write a scroll bar class that can be used for any kind of configuration of scrolling. Vertical, horizontal, even 45 degree angles. This way you’ll never have to write another again. A noble idea.

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 look back on developing Björk I’m surprised by one thing… It wasn’t as painful as I thought it would be.

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 )