Thinking of a simple 3d viewing pipeline, you have something like

• Setup geometrie, textures and lights
• Transform local coordinates to camera space
• Clipping against Frustum
• Project and render

They are a lot of helpers that helps you doing the transformation and projection, especially

• flash.geom.Matrix3D
• flash.geom.Utils3D

I assume that Matrix3D.transformVectors and Utils3d.projectVectors are lightning fast, cause you can pass a Vector (sources and targets) to them. A single(!) Vector could contain the entire 3d world geometry as a list of (x,y,z,x,y,z,x,y,z,x,y,z,...). That is why I am thinking that the Flashplayer is able to execute this well formatted list extremely fast! Much faster than calling the methods to transform several Vector3D objects in a AS3 loop.

So far so good. Where is the problem?
The worst thing from the memorys point of view is the clipping part, cause vertices are added and just valid for a single frame (if the Camera or Geometry is moving). A big case for the garbage collection.
Trying to figure out the best data structure for a 3d engine in Flash, I thought of something like this: All 3d world vertices are stored in a single Vector. Furthermore I would also leave some extra space for the expected vertices in the clipping process (increase the Vector length). With this setup, you reserve memory space and there is no reason for the garbage collection to remove used clipping data. You can easily access the clipped vertices with an offset in the Vector.

Note: The Vector would stay fixedSized. It is on you to allocate enough space for the clipping process when you setup.

But it won't work for now
Imagine you already clipped geometry: Next time you transform the Vector into a new coordinate space, all the clipped data from the last frames will be transformed as well. Two simple optional parameter would change that.

Solution
Matrix3D.transformVectors(vin:Vector, vout:Vector, startIndex: uint, endIndex: uint):void
Utils3D.projectVectors(m:Matrix3D, verts:Vector, projectedVerts:Vector, uvts:Vector, startIndex: uint, endIndex: uint):void

Thats it! That simple!
Now you could force the Flashplayer only to transform the necessary range. You simply overwrite the new clipped data in the Vector every frame, project and draw them. If you know the region, where a 3d-object has allocated its vertices you could use the startIndex and endIndex value to transform it at once.

Too late? I guess so. Too bad I started so late...

Update
I created an official feature request at Adobe bugbase. It would be a great feature!
Please vote. It may not be too late.

So far so good, it works now, but I am thinking of all the other stuff, that must be added too. The good thing is that you get a lot of API around to handle Vectors with 3d and texture data in the Matrix3d and Util3D class. And a Vector can contain all the data from the whole 3dscene. Just one method call brings it into several spaces. Even projection on screen is provided.

I am missing of course a zBuffer. My first attempt to sort the polygons in the old fashion way failed. Even on this simple cube... a cube - what the hell... NO MORE ROTATING CUBES!!! haha. Anyway the cube is actually a 3ds model, so let's see, what comes next.

They finally implemented Vector support in my favorite AS3 editor FDT (beta version)! The class Vector is similar to Array, but type-save. Now it's time to bring the new performance boost to our AudioTool and check out the new Graphics API.

A big thank to the FDT team! You guys rock!

Read their blog post.

Afterall...enjoy 1:30h minimal tracks - alternative download at soundcloud

Why Audio Encoding?
We would like give the Hobnox AudioTool users the option to stream a live-session to their Hobnox Library. Unfortunately the Flashplayer doesn't allow streaming data to the hard-drive and we didn't wanted to fill the memory with uncompressed audio material (~10mb/min). We manage streaming by using (a lot of) SharedObjects, slicing the audio data into several packages, which are later transferred to the encoder for uploading.

Why Vorbis?
Vorbis has a better file reduction ratio AND sounds much better than MP3 files. I cannot hear any difference against the uncompressed audio data at Vorbis rate of 128kb/sec. Filesize was the reason in the first place, cause we cannot upload uncompressed audio data. It would take too long. Naturally in the end the server converts the audio file to MP3 that the Flashplayer is able to play it. I would love to see the Flashplayer playing back Vorbis in future releases. It sounds better and it is also able to loop. You know that MP3 is not loopable trouble-free.

Entirely in Flash (No Java anymore):
I admit: My session is actually boring. I quickly setup some beats and just one 303 without any effects to test the Streaming and Encoding. Download the OGG-file here. The next update is scheduled for September, 1st. This may shift as we need to wait for FlashPlayer 10. The current version of the AudioTool works with a Java applet to stream the AS3 generated audio to the sound card. We are looking forward to get rid of it.

Share:
I pretty sure we will share the encoder in time. It still needs some tweaking and optimizations.

Bei der Gelegenheit sollten wir mit Seb ein paar Kölsch schlappen, nicht wahr? Bei einer Anmeldung über Sebs Webseite gibt es 10% Rabatt.

Tschö

Hobnox is not just the AudioTool. We are also inviting for the next evolution contest 2008. This time worldwide.

Hobnox is now open for all. No invitation is needed anymore.
Join us! Connect me! Try the Flash based Noxtools!

My session will be about dynamic sound in Flash, of course. I've added details briefing regarding the changes in FlashPlayer 10 in my slides. I hope to spare the sound system this time, so you will be able to get the full experience of our Hobnox AudioTool Demo, I am going to present more elaborately.