Typographic demo combining physics and 3D. A creative variation on the Papervision3D/Box2D method I demonstrated here.

In a recent project I wanted to incorporate some physics with a 3D environment. I decided on Box2DFlash (a port of Box2D), which is a great engine even if the syntax is a little awkward for an Actionscript 3 library.

See the PaperBox2D demo, and the source is available (or right-click on the demo). Hit the ‘d’ button during the simulation to toggle the debug regions for the 2d calculations and see how they are mapped to the objects in 3d space.

Updated 11.20.08, recent api changes in Box2DFlash.

Another Papervision3D demo, this time using VectorVision and the AS3Dmod libraries to manipulate a vector image. Source code is available.

Hmm, I need to update this blog more.

Well I just finished a little interactive demo using Actionscript 3, Papervision3D, and some models I created in Maya. I used a song by Ehma who in his infinite wisdom released the music on Jamendo. I suggest you to check it out, it’s nice!

The Papervision3D guys are running a nice little contest for the title of “PaperKing3D”. I thought this would be good chance to show an example of some of the recent stuff I’ve been working on. Here’s the demo, and here’s the source code.

Read on for more detail about the code and some of the inspiration.

First a word on the inspiration. I come from a photography background so it shouldn’t come as much surprise that in my design work I tend to think of things like a photographer — using space, composition, and cameras. This is why engines such as Papervision3D are exciting to me; they give me a chance to combine all of my interests in photography, graphic design, and programming into one medium. There are also a lot of parallels between programming and photography, namely that they are both fairly technical and require a bit of pre-visualization. The majority of your effort is spent constructing an implementation towards that imaginary goal — manipulating code very much like manipulating light to achieve a photograph. So with those similarities in mind I wanted to highlight the use of light in this demo. I also began thinking of the physical design of cameras themselves and some of the old classics. It almost seems silly that the machine designed to create art becomes a work of art itself, but this happens with code as well. Things of such complexity can be studied and studied creating their own following. So looking around flickr for old cameras I came across a picture of this little gem…

One of Walter Dorwin Teague’s modernist designs for the “Gift No. 1A” during his time at Kodak (a Western New York icon btw). Quite the sporty little accessory to have around your neck in the early 1930’s. This became a good place to start laying out the scene’s look and structure.

The Code

More than likely you’re visiting this page and could probably care less about any background inspiration and want to see how the example works. As I mentioned before, the source code is available so I won’t go through everything, but just highlight some of the more trickier issues.

In a nutshell this scene is just a collada model that I exported from Maya and baked textures onto. Papervision is a fantastic 3D engine but since we are working in a browser with Flash we are very limited by what a software renderer can do. With that in mind we have to create a very low-poly mesh and reduce our triangles count as much as we can. (Pop quiz, what do 3D modeling and type design have in common? Both require that you achieve the maximum expression of a shape with a minimum amount of points.) But, and this is a big but, when modeling the ground and wall planes you’ll be tempted to get rid of all the extra polygons — this is a mistake. We need those extra polys to hold the texture position correctly. [If we didn’t we could turn on precision for the material, but that would slow everything up.] So you may want to do some experimenting with count versus performance, I found a 10 x 10 plane to be a satisfactory compromise.

Another concern in the modeling stage is how the objects are grouped. Before you export your model be sure to combine the meshes you want as one texture and give it an easy name to remember (simply grouping the objects is not enough). This will make it more convenient when assigning your model parts to separate viewport layers later on. Apply a simple lambert shader to the objects and change the shaders name, it’ll be quicker to locate when you’re searching through the collada xml later.

Model, light, render, bake, and export your textures as you normally would. Make sure your models have been UV mapped and keep in mind your textures should be 512 x 512 (1024 if you really need it) for performance reasons.

When loading the images as materials you’ll need to replace the shader name that it’s given within the collada xml. Doing a search for “instance_material” will give you something that looks like:

<instance_material symbol="lambert1SG" target="#myShaderName"/>

You’ll be looking for the symbol name that we’ll add to the material list so we can swap in our texture:

//create material list
var matList:MaterialsList = new MaterialsList();
//convert to a bitmap
var textureBitmap:Bitmap = new myTexture() as Bitmap;
//now swap our bitmap material into the shader name that we found in the collada
matList.addMaterial(new BitmapMaterial(textureBitmap.bitmapData), "lambert1SG");
//once you have your collada loaded then apply the material list
model.materials = matList;

Now we still may get flickering polys with the model and the ground plane. This is a z-sorting issue that we can fix by using Papervision’s ViewportLayers. Andy Zupko has a much better explanation of using them with effects so I won’t repeat that, I’ll just show the relevant parts in my code:

viewport.getChildLayer(model.getChildByName("floor", true));
var wordLayer:ViewportLayer = viewport.getChildLayer(model.getChildByName("words", true));
wordLayer.alpha = 0.8;

The names “floor” and “words” are the names I gave the objects when I combined their meshes earlier. Since in my demo I wanted to simulate caustics I needed to make the model a little transparent. Since you can’t adjust the alpha of a BitmapMaterial I added the model to a separate viewport layer and adjusted it’s transparency there. And since both the floor and the words are being rendered on separate layers we can eliminate the “z-fighting”.

Well I hope that helps someone. The Papervision team are doing a fantastic job but you’ll need to help yourself as well. It’s up to careful modeling and texture optimization that will give you the biggest performance gains.

A number of solutions were discussed, notable was the announcement of Ascender Corp.’s FontEmbedding.com and Ted Harrison’s (of FontLab) EEULAA. Unfortunately the current wave of discussion seems to be following the music industries failed attempts at Digital Rights Management (DRM). I say failed, as previous attempts have been, but what I mean is fundamentally flawed. The premise being that you can control what someone’s remote machine reads and stores, but the technical reality is that only someone with physical access (with applicable knowledge) has the capacity for absolute dominion over the machine. Or to try and apply it more succinctly to the world of fonts — if my eyes can see the typeface on the screen, the computer can also see the typeface. If the computer can see it, it can scrape it, produce outlines, look up a kerning table and write it out to a different name. All of which may even be legal because you cannot currently copyright a letter form, only the “software package” it comes bundled in. There is no format that can overcome this, just like in the “real world” where you cannot stop someone from cutting out letters in a magazine and creating new words.

But to me it seems there is a difference between music, which is format based, and with something like fonts, which is more application based. Let’s say we look a little more upstream to where designers are actually making choices and making typeface decisions. The vast majority are using applications like InDesign, Illustrator, Flash, Photoshop, etc, in short Adobe. So my question is, if Adobe, or any large application developer is effectively acting as a host system for interaction with copyrighted material, don’t they have a certain obligation to restrict offending material? If YouTube gets a complaint about a video infringing on copyright they take it down. MySpace has certain systems in place that will prevent you from uploading a song that matches the metrics of a known song, can’t such a measure be implemented by Adobe? What if there was a look-up system where they could evaluate the metrics of a particular font being used against those listed in a licensed based registry? Even if they did not want to go that route with enforcement, would they not also be in a better position to gauge usage statistics? They could effectively become the primary means of distribution, payment, and royalties — effectively becoming what iTunes is to music.

Of course this is not a perfect system, there will continue to be technical paths around this.  But if you are looking at ways to stop the “casual” pirate then I think looking upstream at the choke points is a better philosophy then trying to use your finger to plug all the leaks that sprout up. You’re going to have offenders, but the question should be how do I make the best out of the current situation by making the most money off regular customers without restricting and alienating them?

There has been a “temporary” page up for the past week in a mad rush to have something done by TypeCon2008. It was functional and highlighted some of the skills I’m trying to showcase. But now that I’ve had another week I’ve reworked the design and interactive code which I think makes it a bit more interesting. It’s definitely a bit hard on the ole’ cpu but I’ve tried to optimize where possible, and really it’s not a site that’s designed to be accessible to everyone on every browser.

I’m going to be adding new stuff to the “portfolio” as I get I can. It’s mostly photography and motion videos at this point but more Flash stuff is in the works. Questions, comments, work? Holla.

Though more importantly to me has been his work at Carnegie-Mellon with human-computer interaction and Building Virtual Worlds. His openness with his work and early embracement of academic publishing on the web is a true help to someone like me. Thanks for your work.

Using an Actionscript class within a Flex component can be a little tricky. The first error I ran into was:

Error #1009: Cannot access a property or method
of a null object reference.

This was a result of using a stage reference within the class to set up boundaries. Since I no longer had access to the stage properties I created two variables within the class to pass the Flex canvas size on instantiation.
The second error I encountered was:

Error #1034: Type Coercion failed: cannot
convert classes::Sprite@8b69259 to mx.core.IUIComponent.

This is because the Flex component will only accept a UIComponent as a child. Since our Actionscript class extends a Sprite we’ll need to place it within one first:

var bouncingBall:UIComponent = new UIComponent();
bouncingBall.addChild(new BouncingBall(myCanvas.width,
                                       myCanvas.height));
myCanvas.addChild(bouncingBall);

This creates a reference UIComponent that we will place our BouncingBall class into which we can now add to our canvas.
An alternative method is to use the rawChildren of the canvas and add the sprite directly to it’s display list. While this works fine, it does seem a bit obscure/ugly. But whatever floats your boat:

var bouncingBall:BouncingBall = new BouncingBall(myCanvas.width,
                                                 myCanvas.height);
myCanvas.rawChildren.addChild(bouncingBall);

The MXML is rather straightforward, though you’ll want to include a clipping rectangle on the canvas otherwise the ball will be dragged all over the screen.
The source code for the above example is available here.