Runtime Environment

SWF Files
Swf files are compressed, multipurpose packages designed to contain the following data: raster and vector graphics, video, audio, text, fonts, animation, and actionscript code. Swfs can be loaded at runtime whenever necessary and can use both static and dynamic linking based upon the compiler settings. The runtime environment uses security sandboxes for loaded swf files. The security settings primarily limit the extent of filesystem access and cross-domain access that swf files can use. Adobe has provided the swf file format spec and has recently provided the FLV video format spec and has declared that they will provide the RTMP spec as well.

Flash Player & AVM2
The Flash Player runtime is a very light-weight, virtual machine and handles system calls. The Flash Player includes both AVM1 (AS1, AS2, for Flash versions 1-8) and AVM2 (AS3 for Flash 9,10+) which processes compiled Adobe Bytecode (ABC). The term AVM stands for “ActionScript Virtual Machine”*. The Flash Player uses a Deferred Reference Counting (DRC) mechanism combined with a conservative mark/sweep garbage collector. The Adobe VM uses both JIT compiling and code interpretation and may benefit from compile-time bytecode optimizations based upon compiler input parameters. AS3 computational performance is generally closer to Java than Javascript [source]. The player also maintains a variable framerate that reflects the time consumed for each frame update [source]. Each frame update consists of multiple stages that include internal player processing, rendering, and author script processing. The program framerate is the principle metric reflecting application performance.

Development Environment

Actionscript API
The Actionscript API is divided up amongst the Adobe AIR environment, the Flex environment, and the Flash environment and the Flash Player. The source for all the packages are divided up amongst swc files. Swc files are pre-compiled catalogs of classes and assets. They are similar to swf files but they are used for compile-time dependency resolution. Furthermore, the native swc’s predominantly contain code and not visual assets. An overview of the Actionscript packages is kept up to date in the Adobe Live Docs.

The Flash IDE
The Flash IDE was designed for designers, artists and animators. So, it is equiped with a layer system which reflects the stage display list and a hierarchical timeline which reflects the temporal nature of the runtime. The objects placed on the stage are represented by the timeline and can be “tweened” (using runtime interpolated 2D geometric transformations or custom shape morphs). The same timeline is also used for object creation and destruction. All stage instances are confined to a small set of native data types including: MovieClips, Sprites, Shapes, TextFields, Videos, and Bitmaps. The IDE also has a library that contains source objects for all stage instances and even instances that aren’t used on the stage. Flash projects often have several build targets (compiled swf files) that use parts of the project codebase. After Macromedia was purchased by Adobe, the Flash authoring environment has been updated to provide much better interoperability with the Adobe Creative Suite.

Adobe Flex Builder
Flex Builder is an Eclipse-based Actionscript IDE for writing and compiling swf files. Flex Builder is primarily designed to build “Flex” projects which can be written in an interface tagging language known as MXML. MXML is a declarative XML langauge used to define interface elements in a project. MXML files provide the “view” in the MVC software design pattern. Flex Builder also provides plenty of useful features like code completion, syntax formatting, active debugging, memory profiling, and project building that expose errors and warnings during development time. Because the Flex framework is not bundled with the Flash Player, Flex projects must statically link to all swc assets specific to Flex which amounts to greater than 500kb. This is very unnatractive for most users, thus Adobe has provided means by which the download can be significantly decreased. Flex Builder is also used to deploy applications for the Adobe AIR platform. Adobe AIR is a desktop runtime that combines webkit with the AVM2 portion of the Flash Player. AIR can be likened to a closed source Java SE runtime but provides a smaller learning curve and greater accessibility than what comes with the Java ecosystem.

Compiler
Since Adobe has launched the Flex platform they have provided free access to their Flex and Actionscript compiler and SDK. They have also provided open source projects under the Mozilla public license. The compiler (mxmlc) provides an impressive amount of flexibility and customization for swf compiling. It can be configured with command line options or a configuration XML file.

* correction 09-12-2009, I had previously stated that the term AVM meant “Adobe Virtual Machine”, this is a mixup. It actually means “ActionScript Virtual Machine”. Thanks dbam.

My current configuration is Mac OS X 5.2 + TextMate 1.5.7 + Flex SDK 4.0.0.3504. I have two shell scripts in place:

1. /usr/bin/mxmlc
2. A TextMate run bundle set to a hotkey, “command + R”
3. I’ve also have my Flex SDK set to the absolute path of: /Developer/SDKs/Flex/4.0.0.3504

This configuration requires a flex-config.xml in the same directory as the AS3 class file that you’re compiling. When you run the TextMate script (or something similar in your Terminal shell) it will compile the filename you pass in and default to using a config.xml which acts as a local flex-config.xml file. All of these can be customized as needed.

Example Flash 10 3D cube rotation:
[kml_flashembed movie="http://www.calebjohnston.com/storage/fl10_examples/01_cube_rotation/CubeRotationExample.swf" height="260" width="410" bgcolor="#FFFFFF" /]

Obviously, the above swf won’t work without Flash player 10 installed.

Download the source here.

I may be in the (rare?) position of being highly interested in two disparate technologies. The first being an online scripting language standard governed by ECMA (used in Javascript & Actionscript). The second, an open standard for real-time rendering governed by the Khronos Group (OpenGL). In recent days these two languages have faced most unfortunate developments. First the ECMA script 4…

On Nov 7, 2006 Adobe announced the contribution of their ECMA scripting engine to the open source community under the name “Tamarin”. Tamarin is also being used as the JS scripting engine for Mozilla Firefox under the name “SpiderMonkey“. It seemed like a good idea at the time of release. But now look at the situation: we have AVM2, directly connected to Firefox AND the ECMA committee –slowing the progress of Actionscript and the Flash Player (and the internet for that matter). Needless to say, this is a disappointment. But it doesn’t end there…

Though having plenty of contributors, the realm of real-time rendering is primarily controlled by Microsoft, Nvida, ATI/AMD, Apple, and (more recently) Intel. Microsoft hasn’t really contributed to the Khronos Group because long ago they decided to pursue their own 3D graphics rendering API known as Direct3D. The evolution of OpenGL has become painfully slow while DirectX and Direct3D are becoming the (de-facto) standard. Finally, the Khronos group promised to improve the long lost API by introducing an object-oriented structure in stark contrast to its current state machine model. That was in October 2007. Last week the specification was finally unveiled and it remains largely the same. Not only is this a big let down, but it will definitely damage all future 3D software and game development releases for non-Windows platforms (including future consoles). Very unfortunate.

DISCLAIMER: Both of these developments are FAR more complex than what this post outlines -and there’s justification behind both developments. But on the whole, they both seem bad for everybody (or just me?).

Animation
Animation in Papervision3D can be performed the exact same way animation would be performed in 2D. Simply apply any tween or algorithm to an object property (like x, y, rotationX, scaleY, etc) and re-render the scene. But, for imported animations its not quite that simple. Lately Moses’s GoASAP package is being adopted in testing for the Papervision engine. It could soon become adopted by the system.

The Collada DAE Parser
Imported animations come in plenty of flavors but must conform to the same system. That’s the reason the animations package exists. Papervision has long supported externally created 3D assets. You’ll find those file parsers in pv3d.objects.parsers. Although, these importers are nice to have, a big part of Great White was the introduction of the open source project ASCollada. ASCollada is an amazing parser for the standard 3D asset interchange format known as Collada. Collada files are basically very dense XML files that use a .dae file extension. Collada files can be exported from Maya, 3D Studio Max, Blender, Google Sketchup, and XSI. However, level of support for those programs probably follows this order: 3D Studio Max, Maya, Blender, Google Sketchup, XSI. Also, if you’re importing MD2 models, the MD2 file parser will import most animations as well.

You can try it out using the DAE class like so:

import org.papervision3d.events.FileLoadEvent;
import org.papervision3d.objects.parsers.DAE;
daeScene = new DAE();
daeScene.addEventListener(FileLoadEvent.LOAD_COMPLETE, onSceneGeometryLoaded);
daeScene.addEventListener(FileLoadEvent.ANIMATIONS_COMPLETE, onSceneAnimationsLoaded);
daeScene.load("your_scene.dae");
var animChannel:AbstractChannel3D = daeScene.getAnimationChannels()[0];
var frame:uint = 20;
var animObject:DisplayObject3D = animChannel.defaultTarget;
animChannel.updateToFrame(frame, animObject);

Render Statistics
Papervision records all the primary rendering tasks. If you want to monitor rendering statistics, you can have them captured when you execute the BasicRenderEngine instance method “renderScene().” When traced, a typical render report will appear like this:

ProjectionTime:0 RenderTime:1 Particles:0 CulledParticles:0 Triangles:38 ShadedTriangles:0 CulledTriangles:82 FilteredObjects:0 CulledObjects:0

You can use this information to determine how well your scene is rendering. And it could give you ideas on how you can improve rendering by adjusting camera settings, culling plans, and clipping.

Optimization
Great White has gained many huge performance advantages over previous versions of Papervision. One important advantage is that nearly all materials will render a surface to BitmapData. This is great because, as of Flash Player Update 3 (9.0.115, mid-2007) Multicore CPU support has been added to much of the BitmapData operations.

Clipping is a flag added to the Viewport3D constructor in Great White that will force the engine to perform clipping of all objects outside the the viewing rectangle (the viewport). This feature may seem obvious, but a lot of public engines neglect this.

Culling Algorithms
Drawing is the most expensive process that Papervision performs. As such, there are a few different standard methods for removing items from the render queue in any 3D drawing API. This helps speed up render times by removing renderable triangles that would otherwise be drawn. Papervision3D performs backface culling, view frustum culling, and contribution culling but NOT occlusion culling. Occlusion culling is a huge process that is more built into accelerated APIs like OpenGL. Though it can be very difficult to perform well, it can also add extrordinary benefits to rendering performance.

MovieClip Materials
Papervision3D supports interactive, animated, and smoothed MovieClip materials. However, those features come at a cost. You may already be aware that BitmapData smoothing (anti-aliasing) is slower than normal BitmapData rendering. Anti-aliasing algorithms are simply expensive operations and thats the bottom line. The other two features are performance hogs because they require that the Flash player to update the surface BitmapData object on each frame update –instead of reusing the original object that was derived from the MovieClip.

Relative Performance
I’m currently coding lots of Flash player performance tests as they relate to Papervision. Right now I’m only using the following methods for testing: Math.sqrt(), Math.sin(), Matrix3D.multiply3x3(), and BitmapData.draw(). The test is simply a for loop that iterates 9999 times. It looks interesting and helps me make another point about PV3D performance. I’ll have to publish this application elsewhere, but for now here’s a sample of what I’m finding:

Figure A: Performance timetable for 4 operations in a for loop lasting 9999 iterations. BitmapDataObject1 is 40×40, transparent and BitmapDataObject2 is 600×600, transparent. They both draw a single purple circle.

As you can see bitmap drawing is the most expensive operation here. In almost every instance that I can think of, drawing will be the most performance intensive activity in any 3D rendering API. I could explain that here, but it would probably double the size of this post. ;)  In a nutshell, it always helps to render only when you actually need to feature interaction and/or animation. Additionally, actively perform any reasonable operation to limit the number of objects in the scene. Again, the library does a lot for you there, but gains can always be made. Also, a little experience will show you that keeping the renderable area small will help also.

The Papervision3d source SVN location includes the standard AS3 version of Papervision3D (version 1.7 as of this writing). If you look at the branches folder inside trunk you will find version 2.0 which is code-named “Great White”. This series is focused on that branch, and NOT version 1.7. Also, its important to know that Great White is probably the fastest and most frequently changing part of the Papervision source and thus details in this article will likely change over time.

Also, as a convention in these posts, I’ll be putting direct references to actual Google Code hosted repository files inside this page. If you don’t wish to open that repository each time you want to know the path of a class, then simply mouse over the link and look at the link address or the tool tip that shows up for the link. All references to Papervision3D classes assume that all uses of the term “pv3d” refer to the root Papervision3D package.

All Flash demonstrations are interactive. After focusing on the Flash applet, you can use the following key controls to control the camera.

Please note that nothing will promote your understanding of the code better than just reading it yourself. Although that may seem daunting, you’ll end up doing it anyway if you really get into the project. A good place to start might be reading the comments for classes in the folder pv3d.core.proto. If you’ve happened upon this page but are unfamiliar with computer graphics from a technical standpoint, please read Part 1

Geometry
In Papervision, all geometry is basically stored in the form of vertex data (Vertex3D). Collections of Vertices are stored in GeometryObject3D instances. Every DisplayObject3D class contains object information (such as location, transformation, orientation axis, etc) AND a reference to a GeometryObject3D instance. The DisplayObject3D class is the building block of all 3D data in Papervision –much like the flash.display.DisplayObject class is the building block of a 2D stage. However, one important difference is that a DisplayObject3D will not contain any rasterized visual data (as the DisplayObject does in its graphics object). It contains only data that is used by the rendering engine (BasicRenderEngine) and the object’s material (* MaterialObject3D) which is used to draw the object onto a Viewport3D object.

*Note: the actual method performing all drawing operations is NOT MaterialObject3D.drawTriangle but instead any of its subclassses that are overriding that method (for example ColorMaterial.drawTriangle).

Texture Mapping
Up until now, all discussion about 3D rendering has excluded the use of images used on geometric surfaces. This feature, called texture mapping, is very widely used. Unfortunately, it can also be quite an expensive process in terms of CPU cylces. Texture mapping has also evolved to allow for plenty of visual effects like bump mapping, normal mapping, displacement mapping, light mapping and more.

As you may recall from Part 1, all surface geometry in Papervision is divided into triangles. However, since images used in texture mapping are rectangular, something must be done to determine how the image can be mapped onto triangles in order to render the rectangular map as a single image. This is where the UV coordinates come in. A UV is simply a 2D coordinate that represents a location on the texture map that is associated with the 3D point on a triangle. Figure A1 shows this relationship.

Figure A1: Three example UVs for texture mapping a rectangular plane.

In Papervision, all the actual drawing commands exist in the material class being used for an object (as I mentioned above). Please note that two options for texture mapping exist. There’s ‘normal’ texture mapping which is also known as ‘affine‘ texture mapping. And then there’s ‘precise’ texture mapping which would be perspective correct. Normal texture mapping is a bit less accurate but far faster in rendering then precise textures. Exhibit A2 shows an example.

Exhibit A2: Normal (left) vs precise (right) texture mapping in Papervision3D 2.0

[kml_flashembed movie="http://www.calebjohnston.com/storage/posts/textureExample.swf" height="250" width="450" /]

Materials
A Material is a term borrowed from 3D development tools (like 3D Studio Max) that describes a collection of properties that will determine how a 3D surface will be rendered. Materials can become very complicated in production 3D rendering tools, but in Papervision a material has only a few properties. Those properties will determine whether lines, fills and/or a bitmap is drawn and how they’re drawn. The real key component of all materials is the drawTriangle method which is called by the engine during the render cycle.

Lighting and Shading
Light simulation is probably one of the most intricate and complicated aspects of 3D rasterisation. Other forms of computer rendering (like ray tracing) don’t treat lighting the way the rasterisation technique does. The reason is simple, performance. So in order to mimic light phenomena using rasterisation, shaders can be used. With the Great White branch of Papervision, lighting and shading have been added. Outside of Papervision, the term “shader” sort of has multiple definitions. Shaders are used in 3D development tools to determine how light will appear on a surface. But in real-time rendering APIs (like OpenGL and Direct3D) a shader is used to modify the graphics pipeline. There are actually several languages that govern shader authoring. Even Adobe has their own brand of shader language called Adobe Image Foundation. Although shading and lighting are rather complicated features in GPU accelerated APIs, in Great White they’re actually much simpler.

With Papervision, shaders are probably most useful for applying native flash effects (filters and blend modes) to any desired surface. Although, filters are not fully supported yet. Aside from that, applying a shader to a material is basically the same as applying a gradient-like light map to the BitmapData surface. So if you understand gradients and BitmapData objects in Flash, you basically understand Papervision shading as well. There are really 4 types of light maps you can use and those are Phong, Flat, Gouraud, and Cell. For each of those light maps there is a shader. There is also one other shader that can create an environment map. Its the EnvMapShader. It allows one to pass in bitmap objects that are used in combination with the surface texture map. Also you can use bump maps in Papervision3D shaders. See the BumpmapGenerator class. Exhibit B illustrates a simple example of various shaders. While this is not really the same ‘shading’ that happens in video games, with Flash 10, shading could definitely change radically in Papervision.

Exhibit B: Shading examples in Papervision3D 2.0

[kml_flashembed movie="http://www.calebjohnston.com/storage/posts/shadersExample.swf" height="250" width="450" /]

Its also important to note that shading requires a light source. Unlike other popular 3D APIs, there is no default ambient light. And any light sources that are used are not a part of the scene. Instead you must add a light source to the shader and its position is used in determining what the light map looks like. At the time of this writing there is only one light source supported per shader in Papervision3D. Also there is only one type of light to choose from -a point light.

Cameras
Cameras aren’t that complicated in Papervision3D. There are three types of Cameras: free, target, and debug. A free camera is totally unattached to anything that exists in the environment and can be moved ‘freely’. But a target camera will have a focus object within the scene. That object can be moved freely, but the camera will always come along. It works just like a focus camera object would work in a 3D development tool like 3D Studio Max or Maya. And thus a key aspect of that behavior is that if you want to translate a Camera3D object, it will actually rotate about its focus object. The last type of camera (debug) allows for key control, so that you can move the camera around as desired. This is highly useful when you’re building a complex scene or importing geometry from an external editor.

The only three camera-specific properties you can manipulate to control the view are zoom, focus and field of view (fov). The fov is in degrees. Normally 60 is representative of a normal 35mm camera lens. But the debug camera defaults to 90 degrees. Zoom and focus can be determined based on the fov and the camera’s distance to the near clipping plane. Exhibit C demonstrates the interaction of the fov and focus value. Also, here are some rather crude numbers for comparison:

Note: all camera focus values are used with a default debug zoom value of 24. Field of view values are in degrees.

Exhibit C: Demonstration of camera field of view and focus. Use keys r and f to increase and decrease the fov respectively.

[kml_flashembed movie="http://www.calebjohnston.com/storage/posts/cameraExample.swf" height="250" width="450" /]

Stay tuned for more feature dissection in Part 3. In the meantime, download examples source files here.

I have many friends asking me for more information on Papervision 3D. Usually, they’re just genuinely interested in learning about it and also how they can use it. These friends are bright people, but generally unfamiliar with the topic of computer graphics. I’ve consistently directed them to Wikipedia articles that I think will make everything clear to them (in this order):

1. Computer Rendering
2. Rasterisation
3. 3D Projection
4. Matrix Multiplication

Unfortunately, I think people are reluctant to read those articles because they’re half written in math formulas. Those formulas are critical for getting a real understanding of what’s going on “under the hood” but I admit they’re annoying to read if you don’t really want to learn the math. And also, those articles won’t mention a single Papervision class file anywhere (naturally). I’m sure this is a little less exciting for someone who’s into 3D in Flash. Therefore, I’m reviewing and dissecting Papervision3D 2.0 (Great White) in a multi-part series for those who are curious about 3D in Flash.

Part 1 will review those Wikipedia articles and relate them to Papervision along the way. If you’re already familiar with computer graphics as a topic of CS, you may wish to skip this post. Parts 2 & 3 will review the details of many features of Papervision3D. Part 4 will be a set of useful notes and tips for anyone who’s not already experienced with Papervision3D.

An Ultra-Brief Background of Computer Graphics
Drawing an image from a 3D scene using a computer can be done many different ways. However, if its going to be done very quickly in order to allow for animation and/or interactivity then typically a process called rasterisation is best. This term is used to describe the transformation of (vector) data into raster (or pixel) data, such as an image.

A few things should also be understood about the vector data used in rasterisation. It really can be almost anything that defines a 3D entity. However Papervision follows the popular convention of using 3D points oriented into triangles. So if a surface looks like a rectangle, its actually (at least) two triangles –each triangle having at least one face. It should also be noted that in 3D space two more important values are often used: normals and UVs. A normal is short for “surface normal vector” which is a vector value that is perpendicular to the triangle’s face. And a UV is a value that is used to determine how an image can be mapped to the triangle’s face. In Papervision, there can be one UV for every 3D point. And there can be one normal for every triangle.

Rasterisation is a term that is used for both 2D and 3D graphics. Without getting into the real nitty gritty behind what’s going on inside a computer to produce an image on a monitor, we can say that Flash has pretty much always performed 2D rasterisation. But with a 3D engine used, a lot of logic is plugged in to produce an illusion of 3D on a 2D screen.

So what is all that logic? In short, 3D projection, matrix math and display list management. Plus, a lot of performance enhancement, shading, parsers, presets, and the structure of a nice OOP API. Here are the basics.

3D Projection
Ultimately, the task of projection is mapping points which are represented in 3D space in a 2D coordinate system. There are different ways of doing this. Figure A1 shows 2 common examples: orthographic and perspective projections.

Figure A1: two common 3D projections of a cube

When using either projection technique and mapping everything within view to a 2D rectangular plane, a renderable volume is determined. This volume will be the space bound by a cube if projection is orthographic. Or it will be a frustum if the projection is perspective. This space is highly useful for making some key optimizations. Figure A2 helps explain the view volume.

Figure A2: Perspective projection view frustum with view frustum culling.

The process of projection is achieved through transforming matrices. In Papervision (as in most 3D APIs) a 4×4 matrix will represent translation, rotation, and scaling for all axes. If you want to understand the raw math behind the matrix convention in 3D graphics, you should actually be reading the links I posted above from Wikipedia. Otherwise the following section will very briefly review the topic.

3D Matrices
A Papervision 3D matrix is represented in 16 Number values. Figure B helps to illustrate how those numbers are used in a right-handed coordinate system.  With Papervision, a left-hand coordinate system is used. This means that the z axis points into the screen and away from the viewer. This will have some important implications if you decide to import models into Papervision from files generated using common 3D software.

Figure B: Three example matrix transformations

There are also 3 matrices that are used to represent a 3D scene in Papervision: the world matrix, the view matrix (or camera matrix), and the object transform matrix. So when an object is projected, it will go through all 3 matrix multiplications AND any animation matrix operations that are performed. More explicitly, each 3D vertex that exists in each 3D object will have to be transformed by all these matrices to end up as a 2D point in Flash.

Display List Management
When an object is added to a scene it is also added to a render list. That render list is sorted so that each object being rendered appears on the screen at the correct depth. Each renderable object is then drawn to the viewport using the viewport graphics object. NOTE: This means that the final render in Papervision is drawn in a single DisplayObject.

Display list management is also where a lot of performance gains can be made. Many times its not necessary to show all the triangle faces that are in a scene because they don’t exist inside the viewing volume (typically a frustum). Removing objects from the render list because they exist outside the viewing volume is called view frustum culling. There are plenty of other (more advanced) methods used in order to optimize the render cycle. Many of those will be explained in part 3.

Valuable Presets
Simple objects like cubes and spheres that come prefabricated in Papervision are called Primitives. They may not seem so sophisticated but consider how you would describe a sphere in terms of triangles using only 3D coordinates. Not to mention how you would determine all the triangle’s UV coordinates and normals! And if you don’t desire creating your 3D scene from primitives, you can generate your own objects algorithmically or even import them from an external source such as a collada file. That’s very valuable indeed!

Actionscript 3.0 and Performance Tuning

AVM2 Overview

There are definitely some big take-aways in these two documents. I would list them here, but then you might not read them for yourself! ;)

The first document is 74 powerpoint slides (prepared by Gary Grossman of Adobe) which is very useful for getting a quick understanding of AVM2 topics such as garbage collection, the benefits of strong typing, the Actionscript byte code (abc) format, the code interpreter and JIT compilation. For an AS3 developer this is a must-read.

The second document is a bit more dense. It contains 108 pages of more formally described underpinnings of the virtual machine. It focuses a lot on how your AS3 code will ultimately be run as processor instructions. Its a great follow-up to the first document. If you’re a geek, I would highly recommend reading this overview.

As you can see, there’s some disappointing trends. I noticed there seems to be a memory issue -something that must have become unresolved before final launch. The framerate reflects the usage on my trusty Intel 2 Ghz Mac Book Pro. Very unimpressive considering this is a decent machine really. I’m sure there’s a little bit of overhead which came from the statistics activity. Although the experience didn’t seem out of pace with the same one when the statistics class inactive. After considering when the average user leaves the site, I decided to make a second graphic which can be seen here.

And this is a little bit unfortunate. I will confess however that the connection speed on the machine I recorded the statistics with was a very slow DSL. A DSL connection would’ve produced more favorable results (assuming the user wasn’t doing other download work in the simultaneously). Although, as you can see a very large amount of time is consumed by watching a loader which brings me to the point of this post. If you build Flash sites which rely upon a pleasant user experience, then make sure all the content you load is well worth its weight.

Download the Starbucks basic class UML (PDF).

I’ve also conducted a certain amount of performance profiling that I will write up in the near future.

Last night I decided to break out the AIF toolkit again and work some mathy expressions into a filter. Up to this point most of the filters that I’ve seen are along the lines of what you will find in Photoshop’s menus. Those filters certainly aren’t bad, but I’ve always been more interested in how an image can be sampled and reconstructed in a manner not unlike what’s found in the 90′s DJ scene. So with that introduction I’d like to demonstrate my latest filter.

Just like in Flash, you can think of the canvas as a 2D coordinate plane. For this filter I used a few trigonometric and polynomial expressions in combination. Most of the polynomial coefficients are also parameters that you can manipulate which is where all the fun is. More to come, stay tuned.

Download the filter.