Papervision 3.0 – GIT it now!


gitpapervision

If you haven’t read the post over at the Papervision3D blog, you should head over and read it.  We are really cranking on Papervision 3.0 – the new version for Flash Player 10.  I think we have a great start, and best of all, it is on github  so you can watch/contribute to the process!  Head over to http://github.com/Papervision3D/Papervision3D where you can download the project in its current state, or git it so you can start participating.

This is my first time using git, and I must say that it has been very challenging to get started in.  Thinking from a SVN standpoint was a big roadblock for me in truly understanding how (g)it works.  Now that I am starting to really grasp how it works, as well as the commands to make it happen, I must say that I really like GIT!  Managing code, especially between multiple branches is incredibly easy to do.

Anyways – enough about git – hopefully my blog will start to generate a few more posts now that the engine is picking up steam – but don’t hold me too it!



Pixel Bender – The End Of 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 512×512 sphere.  In this demo the src image is only 350×350 – much better performance than running it on 1000×500.

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



AIF Hydra Filters


Hyrda has the potential to really open some doors.  Too bad we can’t test them in flash yet! Check out some of the filters i’ve been making.

If you don’t have the AIF toolkit yet, get it here.
You can also check out the hydra gallery here