Friday, February 29, 2008
Tuesday, February 05, 2008
No exclude.xml in Flash AS3
I've been working for R/GA for some time and things have been crazy. The workload has been fairly heavy with little breathing room so I haven't been posting as much.
Here's some thoughts, by others, on some issues I've run into myself. I'm working on the Nikeplus project and one of the big issues with this project is the size of the project. The project has a much longer life than most of the experiential sites I've been working on and requires maintenance as per our client's requests. This of course creates an immediate issue: things have to be coded fast and slim, which of course means there is much less time to solve problems in elegant ways since old code needs to keep running.
One of the issues you run into is requiring classes to be kept up-to-date. In AS2 classes are overwritten when a parent SWF loads a child SWF. This is because the classes are actually created in the _global space.
Here's an AS3 solution that I've recently found that's pretty interesting using the bridge pattern:
http://www.jessewarden.com/2007/09/no-excludexml-in-flash-cs3-for-as3-solution-via-bridge-pattern.html
Here's some thoughts, by others, on some issues I've run into myself. I'm working on the Nikeplus project and one of the big issues with this project is the size of the project. The project has a much longer life than most of the experiential sites I've been working on and requires maintenance as per our client's requests. This of course creates an immediate issue: things have to be coded fast and slim, which of course means there is much less time to solve problems in elegant ways since old code needs to keep running.
One of the issues you run into is requiring classes to be kept up-to-date. In AS2 classes are overwritten when a parent SWF loads a child SWF. This is because the classes are actually created in the _global space.
Here's an AS3 solution that I've recently found that's pretty interesting using the bridge pattern:
http://www.jessewarden.com/2007/09/no-excludexml-in-flash-cs3-for-as3-solution-via-bridge-pattern.html
Tuesday, January 22, 2008
Thursday, November 01, 2007
Emulating 3D Bitmap Transformations (part 2)
(correction)
Okay, so the first time I posted this I was definitely not thinking straight at all. Here's a correction.
So let's take a look at the math involved:
In a scale, pixels (x',y') are given by the following:
x' = x * x_scale_factor
y' = y * y_scale_factor
In a skew, pixels (x",y") are given by the following:
x" = y * x_skew_factor
y" = x * y_skew_factor
If you remember our image is partly scaled and partly skewed. Remember that the images are divided along the line f(x)=x meaning along this line pixels of the skewed picture approach the scaled picture.
So let's pull out that high school math and we'll find that means that:
x * x_scale_factor = y * x_skew_factor
y * y_scale_factor = x * y_skew_factor
By substituting in the line y=x this tells us along the line y=x pixels converge when x_scale_factor = x_skew_factor and y_scale_factor = y_skew_factor.
Okay, so the first time I posted this I was definitely not thinking straight at all. Here's a correction.
So let's take a look at the math involved:
In a scale, pixels (x',y') are given by the following:
x' = x * x_scale_factor
y' = y * y_scale_factor
In a skew, pixels (x",y") are given by the following:
x" = y * x_skew_factor
y" = x * y_skew_factor
If you remember our image is partly scaled and partly skewed. Remember that the images are divided along the line f(x)=x meaning along this line pixels of the skewed picture approach the scaled picture.
So let's pull out that high school math and we'll find that means that:
x * x_scale_factor = y * x_skew_factor
y * y_scale_factor = x * y_skew_factor
By substituting in the line y=x this tells us along the line y=x pixels converge when x_scale_factor = x_skew_factor and y_scale_factor = y_skew_factor.
Wednesday, October 31, 2007
Emulating 3D Bitmap Transformations
I've been looking into 3D through Flash and there's a lot of 3D projects going on in the community, but Flash is currently not natively 3D. Though the new upcoming version of Flash seems very promising.
Before I explain anything credit for this post goes to my friend Steve at BSS who originally showed me this.
So my goal was to figure out how Papervision initially worked. My first assumption is that people were using the flash.geom.Matrix class to perform perspective transformations on BitmapData, but this is not the case. The Matrix class in Flash is only able to create affine transformations.
First let's take a look at affine transformations:
Affine transformations are transformations where:
What We Can Do
What we can do is approximate 3D transformations by approximating a perspective transformation. We'll approximate by slicing our 2D image into smaller pieces and performing transformations on those individual pieces. As a side effect the image may be distorted, but we'll be able to control the distortion if we cut the image into smaller pieces.
Let's experiment through visually. Start with a grid image and slice it into two triangles:
Now let's take a look at two particular affine transformations.

Notice that the pixels near the line P1P4 do not move very much. These are a characteristic natures of these two particular transformations, scale and skew.
So if we take the top portion of the skewed image and the bottom portion of the scale image, it's possible to arrange the image so we're able to move only P4.

Therefore, since our pixels near our slice are able to match up, performing transformations on the individual pieces to allow our lines to converge and we are able to approximate perspective transformations with a certain degree of distortion. For each of the other points we'll simply use the same affine transformations. In my explanation I've only detailed one corner P4.
Controlling Distortion
To reduce the amount of distortion we'll simply create more subdivisions, or tessellations, for some given picture. As the pieces become smaller and smaller the distances between where pixels are and should be become closer and closer.
Here is an example with draggable corners and smoothing:
Before I explain anything credit for this post goes to my friend Steve at BSS who originally showed me this.
So my goal was to figure out how Papervision initially worked. My first assumption is that people were using the flash.geom.Matrix class to perform perspective transformations on BitmapData, but this is not the case. The Matrix class in Flash is only able to create affine transformations.
First let's take a look at affine transformations:
Affine transformations are transformations where:
- Collinearity between points, i.e., three points which lie on a line continue to be collinear after the transformation
- Ratios of distances along a line, i.e., for distinct colinear points p1,p2,p3, | | p2 − p1 | | / | | p3 − p2 | | is preserved
What We Can Do
What we can do is approximate 3D transformations by approximating a perspective transformation. We'll approximate by slicing our 2D image into smaller pieces and performing transformations on those individual pieces. As a side effect the image may be distorted, but we'll be able to control the distortion if we cut the image into smaller pieces.
Let's experiment through visually. Start with a grid image and slice it into two triangles:
So if we take the top portion of the skewed image and the bottom portion of the scale image, it's possible to arrange the image so we're able to move only P4.
Therefore, since our pixels near our slice are able to match up, performing transformations on the individual pieces to allow our lines to converge and we are able to approximate perspective transformations with a certain degree of distortion. For each of the other points we'll simply use the same affine transformations. In my explanation I've only detailed one corner P4.
Controlling Distortion
To reduce the amount of distortion we'll simply create more subdivisions, or tessellations, for some given picture. As the pieces become smaller and smaller the distances between where pixels are and should be become closer and closer.
Here is an example with draggable corners and smoothing:
Verification Mathematically:
For those that are interested, we can prove this mathematically because of the way image data is manipulated mathematically by these affine transformations. I'll talk about this next time for the real nerds.
Subscribe to:
Posts (Atom)
