Haven’t seen them?  Apparently its because they don’t exist.  According to this bug report it was a known issue but not corrected before the last version of AIR was released.  I spent a good amount of time wondering what I was doing wrong before a friend did a search in the bugs list for me – and voila!

So, my first question: does anyone know a work-around for this issue?  The comments recommend using the HTML component, but unfortunately I need a lot of the interactivity that the TextArea offers that the HTML component doesn’t have.  If anyone has an idea let me know.

If anyone of you aren’t sure where to find bugs for the Flash player, you can find them at bugs.adobe.com. I use to never check the bugs list, as most of the problems are ran into when I was just getting into flash was user error – but now it seems that I probably need to spend more time at the bugs list before wasting hours of time late at night trying to figure out why my img tags disappeared.

Anyways – if anyone has an idea – shoot me an email or a comment!  I’ll be your friend!

No Comments | In: as3, bugs | | #

I made my first JigLib Demo!  Check it out.

If you don't know what JigLib is yet, you are really missing out.  Its a great project I'm proud to be the on the team of.  It is a 3D physics engine (currently only for Papervision3D, but has been ported to Sandy/Away).  It is a port from the JigLib engine done in C.  For more information on the project, check out the blog.

I don't really want to give a bottoms up rundown on how jiglib works, so I'm just going to point out a few things that will help you pull off effects like you see in this demo - both from the jiglib point of view, but also from a general pv3d and programming angle.

The Environment

This environment is actually very simple.  I have a bitmap for the floor, a lamp model, and a bitmap for the cubes.  I dynamically tint the cube materials to give it a little more depth and variety.  One thing you will notice is that each cube, and each side of each cube, gets its own material.  If you are wondering why, I did this to allow for the bullet holes to be drawn directly onto the material.  I use a movie material so that it is easy to just add a bitmap into with a specific blend mode, and then forget it.

The environment for JigLib is very similar.  Each cube is simply a "skin" for a class that represents a cube in JigLib.  This class is called "JBox".  You can think of a JBox as simply the "form" of a cube - it has position and rotation, which are transfered to the object that it is skinning.  This it the general way that JigLib works.  There are unique JigLib objects which use DisplayObject3D's in Papervision as a skin.  All transforms done to the JigLib physics object is then reflected on the DisplayObject3D.  JigLib has physics objects for Planes, Cubes (Box) and Spheres.  It also includes logic to generate a car with wheels, using a special wheel class and an extension of the JBox class.

So, each cube is controlled by a JBox - and the floor is a JPlane for them to bounce on.  There were some hit detection problems I was having with the plane, so I also added a JCube underneath the plane to give extra "floor" for the objects to run into.  This is a hack fix, but it seems to help.  Something else you can play with to help collision is the timing used by the physics engine.   A lower speed will mean that things will move slower, and detect more collisions more accurately.

The Gun Shot

The gun shot is made up of a couple different parts.  The gun itself actually "shoots" where it is looking - which is always 2000 in front of the barrel.  The only time this is changed is when a hit is detected on a cube.  When the mouse clicks on a cube, the target is changed to the exact coordinates of the hit.

The Hit

The actual hit is determined by the mouse click.  Take a look at the following code:

hitPoint records where the mouse was clicked in world space.  Remember, this is only called when a cube is clicked.  We then get the difference between that point and the camera, to get our "force" vector.  To make it a constant strength, we simply normalize it (make it a length of 1), then multiply it by the force we want.  We get our RigidBody from the dictionary I store the references in.  Then, we use the function "AddWorldForce" - which takes two JNumber3Ds - the force vector, and the world hit point.  This function will add the force to the object from world space - which saves us having to convert things into local coordinates.

The Bullet Trail

The bullet trail is a seperate class called LineOut.  I called it LineOut since it fades itself out every frame.  Once its invisible, it removes itself from the scene.  To get the start and end points of the Line between the gun, I pass in two objects - the target that is positioned at the hit point, and the the muzzle flash that is positioned over the gun barrel.  Before we can use the muzzle flash position, however, we need to update its world coordinates:

startPoint.world.calculateMultiply((startPoint.parent as DisplayObject3D).world, startPoint.transform);

Once the world matrix is updated with the current transform, we can use the world matrix to define the start point of the line.  I use a segmented line because it looks better - but feel free to play with how many vertices are actually used.

The Bullet Hole

Since we used a seperate bitmap for each side of the cubes, we can alter them individually.  This has more memory overhead, but I think it more than makes up for it by having bullet holes.  The bullet hole position is determined, again, by the renderHitData that is passed when a cube is clicked.  The U and V properties of the renderHitData tell us the "x" and "y" coordinates of the click on the material.  Once we have that, we can simply add a bullet hole bitmap to our movie, and position it correctly:

We take half the width and height to make sure that the bullet hole is properly centered on the hit point.  One other thing to keep in mind is to define the clipping rect for the movie material when you initially make it.  If you don't, your texture will become skewed if bullet holes go off the edge of the material, changing the size of the texture.

Those are the main parts of the demo - hopefully some things are helpful.  I was hoping to show some fun uses of JigLib - and hopefully spawn some cool ideas in the process.

Here is the Source Code

and

A Link to the Demo

37 Comments | In: as3, papervision | | #

I'm not really sure where the inspiration came from, but I decided to take a stab at doing Motion Trails with Pv3D.  Instead, I ended up with something more like a tail - but left the class name MotionTrail... Anyways - there isn't a whole lot to say on the technique I used here - but I will give a general overview just to save you looking at code.  See the Demo.

The tail is defined by Number3D objects which "chase" each other, with the head node being pinned to the target you are chasing.  Each Number3D, which I've extended into a Trail3D class (its internal - just look in the MotionTrail.as file) - springs after the node ahead of it.  You can control this "springyness" by adjusting the minEase property of the MotionTrail.  The minEase refers to the ease amount of the very last node on the tail - which increases each node up to the head, which has an ease of 1.  So, the lower you set minEase, the slinkier the tail will end up looking.  You can control how many nodes are in the tail by adjusting the "iterations" parameter of the MotionTail class.  You need at least 2.

The tail is actually a triangle strip, which progressively gets smaller the closer to the end it gets.  This 1) lets you use any material you want, and 2)easily adjust the look and feel of the tail all you want. Feel free to override it to affect the width with speed, distance, or any other cool variables you want.  It looked good just tapering so I left it that way.   The triangle strips vertices are adjusted to their corresponding TrailNode, so they always face the camera.  This keeps the tail visible from any direction.  Again, you could change this if you wanted it to be a more obvious flat tail.  My initial idea was to use the delta properties of the adjacent nodes to determine the nodes up vector (find the cross product between the dx/dy/dz values of the nodes on either side of the current node) - but again - I liked how this looks so I left it.

The demo itself just makes use of some bezier curves to keep things moving smoothly.  You will notice the nodes are flocking - but really it is just setting the control point and end point of each node within a certain range - which changes positions when the first object arrives.  You can press "F" to toggle it so that each node has its own unique path.

Anyways - here is the code,

and another look at the demo

enjoy.

23 Comments | In: as3, effects, papervision | | #

At Infrared5, one thing we do to give us a good boost of speed in Flash is using a technique called (at least by me) Bitmap Injection.  The idea behind bitmap injection is to swap out pre-rendered frames of an animated clip into a bitmap object.  This removes the extra draw call of a MovieClip, thus speeding things up.  Since you can simply change the bitmapData property of a Bitmap, it simply reassigns what it is drawing, rather than having to copyPixels or do any of those performance killers.  Since we do it at work, and since Papervision is driven by bitmapData objects - I decided to whip up a quick material which could save your life.

A normal MovieMaterial, when set to animated, redraws the bitmap it is using for every frame of your rendering.  As you can imagine, this costs serious CPU, and if you have too many animated materials, your application will slow to a crawl.

So, I wrote up MovieCacheMaterial.  The name says it all really.  The material draws every frame of the movie into a global array for that particular asset.  Then, if the movie is ever on that same frame again, instead of redrawing the movie, it simply draws the 3D content using the already cached bitmap.  Then, any other DisplayObject3Ds using that same MovieClip will use the same cache as well.  So, your performance on the first loop will be the same as a normal MovieMaterial, but after that, the performance is equivalent to a normal BitmapMaterial - even though there is animation on it!

Check out the Demo

I wrote a hack work-around for the first loop issue, which might be of use to you.  You can call material.ripMovie(stage, frameRate, completeHandler).  You pass in the stage, how fast you want the movie to be ripped into the cache, and what function to call when it is complete.  The material will set your stage FPS to your desired number, then when it has ripped every frame of the MovieClip that was assigned to it, it will call the function you pass in as completeHandler.  This will make it so when you start your application you can have the best performance right off the bat.  Obviously it will take it longer to start up, however, since it has to rip your animation before beginning.

You are amazing Andy - What's the catch?

Unfortunately, there are some limitations to using this material.  The first limitation is that it is a memory hog.  Since you draw every frame of your Movie into memory, that much more memory is going to be used.  To give you an idea of how much that equals:  the animation in the demo above is ~150 frames, and is 512x512.  When it is fully parsed it uses about 140 megs of memory.  Smaller movies will obviously use less.  It is definitely something you need to be aware of however.

Second limitation: it doesn't work with real time dynamic movies or interactions.  Remember, it simply draws every frame of a movieclip.  That content can be dynamic the first loop, but after that, you are going to see exactly what happened the first time over and over again.  This obviously rules out any Virtual Mouse behaviors on a movie as well.  But, if you have a simple animation you want to loop - go for it!

And In the End

One other final thing to point out is that you can control your animation by changing your currentFrame on the MovieClip just like normal.  It won't mess up the caching, so you can pause, play, skip, etc. just like normal.  In the demo, you can press "F" to jump to the middle of the animation - using a gotoAndPlay.

Anyways - thats about all there is to say about it.  You can see the performance difference on the demo.  For me, on 49 planes, i get about 25 FPS with MovieCacheMaterial, and about 5 FPS with regular animated MovieMaterial.

See the Demo Again

and

Get the Source

Feel free to report any bugs.  I probably won't fix any, but it might help others   Also, you might have noticed I bolded certain words throughout the post.  If you can guess why I will give you a free copy of my upcoming top secret application (still a little ways off).

Enjoy!

25 Comments | In: BitmapData, as3, papervision | | #

Ha!  Honestly, the title was just to get your attention.  But to answer your next question, no, there isn't a single line of Papervision in this demo (requires Flash Player 10).  This is, in fact, my first real test with Pixel Bender (and integration with Flash).  I had written one or two a few months ago the day it was released, but this was something that I had hoped would change the way I do some things in Flash.  It was inspired, (and some projection stuff borrowed) by the raycasting work of mike welsh, who made this great raycasting shader, which handled reflections, etc.  While it runs great in the toolkit, it can't work in Flash (but even if it did you would only get about 1 FPS).  What I hoped would be a fast and elegant solution for a client project turned out to simply be a cool little experiment.  Not much application in the real world I don't think - at least not till Flash gets some GPU support for it.

So, what did I learn?

1. Normalize doesn't work in Flash - though it does in the toolkit.  I spent about 4 hours tracking down this nightmare.  My project worked great in the AIF Toolkit, but once I brought it over to Flash, the shading turned into a ghoulish wash.  Turns out that the Flash Player doesn't read normalize.  Instead, you need to do something like this:

float3 vectorNorm = vector/ length(vector);

Or of course, you just do a /= to the original vector.

2.  No Debugging. This is always a struggle when making a shader.  The way you can debug is by simply outputting colors instead of debug statements.  I did end up making some very cool patterns in my filter by outputting various properties as color - but in the end it would be nice to have a simple trace statement.  For example, instead of doing:

out = sampleNearest(src, outCoord())

You can do

out = pixel4(norm.x, norm.y, norm.z, 1.0);

Then the image itself becomes a debug view of sorts.  Its a little less informative than a trace (though it does show trends well), but it helps tremendously when working with shaders.

3.  CPU != GPU.  Running in CPU mode flipped some normals on me.  It worked right in GPU and in Flash.  I read (somewhere) you should test in both to make sure it works all around.  Not sure if this means there will be problems on different computers or not...

4.  Pixel Bender isn't nearly as fast as I wanted.  Sorry... its true.  It sucked going from the 800 FPS Toolkit to the 165% CPU destroyer (dual-core).  Turning the window mode to GPU took about 15% off the CPU, but it still wasn't the performance I was hoping PIxel Bender would bring to the Flash Player.  I found the biggest thing that affected performance was simply how big the image was you were applying the filter too.  Apparently alot of math is faster in AS3 than in Pixel Bender (CPU).  I guess one solution would be to pass in more parameters with some of the math already taken care of.

Some Info About the Demo

I guess first thing to point out is that I use two input images.  src is first input image4, and the one that is automatically passed as an input to the shader.  This image4 is simply the object you are applying the shader too.  The second input, texture, is the texture we want to use for the mapping.  By using two images, we don't have to process every pixel of the texture mapped, if we only want a 512x512 sphere.  In this demo the src image is only 350x350 - much better performance than running it on 1000x500.

Next, the performance sucks.  Well, to be fair, it runs okay - but it won't run on older computers at all, and runs at max CPU on the newer ones.  I have tried some things to speed this up, such as taking the rotation matrix outside the filter and passing it in, but the change was negligible (I didn't see a difference).  So, I opted to create the matrix in the filter per pixel and just keep the filter as self-contained as possible.  If anyone has some tips/tricks to make this filter run faster - let me know!

I'm happy with how it looks - sorry for some of the UV code in the shader itself - in order to remove some precision errors, I had to swap the side axis used for determining rotation depending on the location of the hit.  Makes things look better, though code looks a little worse.

Anyways:

Check out the Demo

and

Get the Source (once again, requires Flash CS4 and Flash Player 10)

Enjoy

17 Comments | In: BitmapData, Flash 10, as3, effects | | #