The Back Button

… well, slide-show’s at least.

San Flashcisco recently invited Lee Felarca to come down and speak about his experiences with papervision3d.

Lee has some very cool pv3d experiments posted on his blog “zero point nine“, one being a forward kinematics experiment of a modeled robotic arm.

So, what can you do with the robot arm, well Lee has exposed various keyboard controls that allow the user to move the arm into different poses. Very cool, so what else? Well how about making it run a slide-show? WOAH?! That’s right, Lee had his robot arm at the meeting, running the show! Check it out .. link.

One of the things I’m looking forward to in Flash Player 10 is support for custom bitmap filters created using Hydra. If you’re not up to speed with Hydra, then all you need to know is that it’s a language that lets you define a custom filter to apply to display list objects in Flash much like the filters you see into todays Flash Player. Great huh? Well it gets even better. The new hydra filters are able to produce their results by utilizing the users graphics card, thus taking a huge amount of stress off the CPU and thus upping overall performance immensely.

Hydra is by no means is breaking news in the Flash world but, I just want to share two thoughts on why I’m excited. It’s able to produce some truly awesome bitmap filters. Your imagination (and coding skill) is your only limitation, but for me, the number one reason why Hydra will kick ass is faster alpha tweening! Alpha adjustment is probably the simplest bitmap filter in existence and the one that’s most commonly used in Flash projects today. This alone is enough reason to be excited about Hydra.

My second reason is to do with 3D rendering using bitmap filters. A few months ago I came across a blog post by Paul Ortchanian. In this post he had jumped on to the “me too” Flash cover-flow band wagon but, Paul’s approach is quite different to many clones before it. Instead of relying on a Papervision type 3D engine or applying simple matrix skews, Paul has gone down another route.

Paul decided on using a built in bitmap filter that is currently available in todays Flash Player called, Displacement Map Filter, to skew and size his album art. His online example looks to animate very smoothly and this is without the use of Hydra and the graphics card. Now, just imagine this cover-flow example utilizing a Hydra filter and I think you’ll understand Hydra’s 3D possibilities. Just think what Papervision3D would be like running on the GPU! It’s all very possible, especially now that PV3D-2 has a plugable rendering engine.

Flash Player 10 can’t come soon enough!

San Flashcisco has information about how to obtain 30% of the price of Papervision3D Training that’s happening this weekend in San Francisco.

check it out, click here

I’ve just starting using Papervision3d for the first time and I decided to go head first into the Great White build.

After completing a portion of work in my project I usually run the profiler to make sure objects are being collected. So, after finishing my Papervision3d portion of work, I ran the project in the profiler. I immediately noticed that I had a worry number of PV3D objects still hanging out, taking up a lot of memory. They we’re mainly math type objects such as Number3D and Matrix3D. And after exploring some more using the profiler, I was able to see that the culprit was the MaterialManager. And surprise , surprise, it’s a Singleton.

Now, I’m not one of those people who hate Singleton’s in projects, all I ask is that they keep themselves tidy. So that when a singleton is “idle”, it’s memory foot print is minimal. And yes I understand that “Great White” is in a pre-release status so I’m not on a rant and bitch session here. I would merely like to warm others who are using Great White for projects to be carful.

So, how does MaterialManager leak? It would seem that the following Dictionary just keeps growing and growing with complex Material objects.

private var materials:Dictionary;

And in the way I’m using Papervision3d; I end up with hundreds of bitmap BitmapMaterial’s and WireframeMaterial’s by having Cubes covered in the BitmapMaterial’s fly on to stage and then off again. Once I remove the Cube from the Scene3D, I expected the Material to be GC’ed because I saw no hard deconstruct method. But no, I saw this Dictionary becomes quite large, very quickly.

To work around this problem I temporally commented out the body of the registerMaterial method so that my Material would never be added to materials:Dictionary.

public static function registerMaterial(material:MaterialObject3D):void {
//getInstance()._registerMaterial(material);
}

But you may need to build your own work around if you’re using shaders as the MaterialManager seems to be connected to ShadedMaterial’s. Maybe you could call init() on MaterialManager once you’re finished with your papervision3d portion of the project. Or work closely with MaterialManager when removing objects from the Scene3D.

I’m sure this issue shall be corrected for the final release of PV3D 2 but until then this work around will be working for me.