In this post I will:

• Explain how any 3D scene is built when using Minko
• Explain how pixel shaders are integrated in the 3D scene
• Explain how pixel shaders are built using Pixel Bender
• Show you a very simple demo of the kind of effects pixel shaders will provide
• Explain how the demo was built

Here are a two screenshots to show the results:

Phong shading + spheric environment mapping on a 2700+ polygons Lamborghini

Phong shading + spheric environment mapping demo

The Scene Graph API

This API is used to build and manage the 3D scene. Scene graph is the most common data-structure used to build 3D scenes. It is simple to understand and both memory wise and CPU efficient. To explain what the scene graph is, start thinking about Flash's display list. In ActionScript 3.0, the display list is actually a tree. The root of the tree is the Stage and you can add multiple children to it. Each child can be a leaf, such as a Bitmap object, or a container such as a Sprite. One of the limitations of a tree is that every node can have multiple children but each child can have only one parent. This property is what makes it look like a tree: branches (and leaves for that matter...) have only one parent branch.

A direct consequence of that paradigm is that if you want 20 red circles, you will have to create 20 red circles and add them to the display tree. Despite the fact that those 20 red circles will be exactly the same you will still have to create and add all of them to the display tree. Thus, you will use 19 times more memory than what is actually needed. That's where the graph kicks in...

A graph is just like a tree except every node can have multiple parents. You can see graphs as a generalization of trees. But you can also say that trees are particular graphs where each node can have only one parent. Anyway, we can now create one red circle and use it as many times as we need! To understand how this apply to a 3D scene, lets consider the following rendering:

And here is the corresponding scene graph:

There are five things to notice:

1. The figure doesn't show the whole graph (I removed the camera and materials).
2. The Scene Graph API is all about interfaces. You can add new features to the API and still extend the classes you need/want (ie. EventDispatcher).
3. The CubeMesh.cubeMesh, SquareMesh.squareMesh and SphereMesh.sphereMesh nodes, which contain the primitives geometry, exist only once each but are used by many IDisplayObject3D. Therefore there is no useless memory consumption! The same can be done with any node in the graph: containers, display objects, materials, etc...
4. The orange circled nodes apply a (3D) transformation to their children, just like Flash containers apply (2D) transformations to their own children.
5. Z-Sorting is here enabled by two different technics: the drawing order (which is pretty much the same as in a classic-2D-Flash display tree) and the DepthSortContainer3D node. This node takes care of z-sorting by sorting its children using their average depth. This way, z-sorting occurs only when needed and only on relevant geometry.

There a lot to explain about the Scene Graph API! But the main point is to understand how it compares to Flash's display tree and what benefits it provides: lower memory consumption and powerful scene building. You are likely to need to find a way to fit in the Scene Graph API anytime you want to extend Minko to add a new feature. In this precise case I will talk about how pixel shaders fits in.

Pixel shader integration

The first step is to find "where" in the graph your new feature will be used. Close to the scene "root" you will more likely find containers. And the "leaves" are often more tangible objects such as a materials or meshes. A pixel shader is some kind of a material so that's where we should start looking!

In the Scene Graph API, there is a special way to handle materials: the "material stack". It's a part of the graph - a subgraph really - that looks very much like a stack because every node uses an "underlaying" material node. Lets consider the orange box from the previous example:

This figure shows the orange cube subgraph. On this graph I added the material nodes to demonstrate how the material stack works. In this precise case, the stack is made of a WireframeMaterial node and a SolidMaterial node. The first one provides a wireframe rendering and the second one is a solid fill. When rendering, the resulting graphics operations will be the list of all the graphics instructions outputed by each node of the stack. Thus, we will here obtain an (orange) solid fill with a (purple) wireframe. So where does the pixel shader fits in the material stack? Well you might have noticed there are two different kinds of nodes in the material stack:

1. the bottom of the stack is more likely to be a "base material", like a solid fill or a texture
2. and the rest of the stack will be mainly "modifiers". In the case of the orange cube, the WireframeMaterial node acts as a modifier for the SolidMaterial node

Our pixel shader material will be a modifier because it will work on an underlaying texture. Now we know our pixel shader material should be on the top of the material stack we have to know what data it needs and how to provide it!

Pixel shader creation using Pixel Bender

A pixel shader works at the pixel level (true story). Therefore, we need per-pixel data. But because we use Flash's drawing API we don't have a direct access to the actual pixels (I'm oversimplifying but that's the idea). The trick is to work on the material BitmapData itself rather than the screen pixels. Thus, I will now talk about "texels" (texture pixels) rather than pixels (so I guess it should be called a "texel shader" then...). Anyway, our shader will then most certainly always need three inputs:

1. The color of each texel, also called a "diffuse map" or... a texture. Any material will do the trick (we can get a BitmapData out of any material).
2. The position of each texel, also called a "position map".
3. The normal of each texel, also called a "normal map".

The position map will be generated at runtime. It is mainly a BitmapData where each pixel stores the (x, y, z) values of the position of the corresponding texel instead of an (r, g, b) color value. The normal map can be generated at runtime. It can also be any material as long as it provides a relevant BitmapData. This BitmapData stores the (nx, ny, nz) values of the normal of the corresponding texel. Here is an example:

In this example both the normal and the position maps have been generated using Minko's NormalMap and PositionMap classes. This picture is actually a screenshot of a demo Flash application. I wont talk too much about this generation step for now, but its done using Pixel Bender and its lighting fast!

In order to make this data available to any pixel shader, the diffuse, normal and position maps are stored in a one-and-only scene graph node: the PixelMaterial. This node will then provide per-texel data access to its modifiers. We can now implement a real pixel shader on top of any PixelMaterial! Everything we need now is a Pixel Bender kernel that takes our 3 maps (diffuse, position and normal) in input.

The following Pixel Bender filter performs Phong shading:

void
evaluatePixel()
{
        float2 o = outCoord();
        float3 position = sampleNearest(positionMap, o);
        float3 normal = sampleNearest(normalMap, o) * 2. - ONE;
        float3 light = normalize(light - position);
 
        // ambient
        float l = ambient * intensity;
 
        // diffuse
        l += max(0., dot(light, normal)) * diffuse * intensity;
 
        dst = sampleNearest(diffuseMap, o) * float4(l, l, l, 1.);
}

As you can see its really straight forward. This is due to the Scene Graph API which makes it possible to do every computation in local space. Therefore we don't have to care about where those computations happen in the 3D scene.

Demo

Phong shading or reflection mapping are great examples of pixel shaders. The following demo uses both (the white diamond stands for the light source):

Phong shading + spheric environment mapping demo

Phong shading + spheric environment mapping scene graph

And to put it in a nutshell, a few performances considerations:

• Everything is done in real time.
• Thanks to the Scene Graph API, every computation is done in local space. It avoids matrix multiplications by the thousand and gives a significant performance boost.
• The application takes less than 20Mb of memory and weights less than 100Kb.
• There are a total of 6 pixel shaders run at each frame (only the visible faces materials are computed and there are 2 shaders per face).
• Those shaders work on 128*128 pixels diffuse/normal/position maps
• That's a total of 98,304 pixels per frame
• Each frame is "processed" in an average of 10ms. (Core2 Duo U9400 @ 1.4Ghz, Flash 10.1 RC7, Chrome 5)
• That's 9,830,400 pixels per second!
• There is a ~30% performance boost with Flash 10.1 RC7
• The number of triangles does not impact the performances
• Do not hesitate to post your own results (with your configuration of course)!

]]> http://blog.promethe.net/2010/06/09/pixel-shader-demo-using-flash-10-pixel-bender-and-minko/feed/ 11 http://blog.promethe.net/2010/04/09/apple-makes-its-own-compiler-illegal/?utm_source=rss&utm_medium=rss&utm_campaign=apple-makes-its-own-compiler-illegal http://blog.promethe.net/2010/04/09/apple-makes-its-own-compiler-illegal/#comments Fri, 09 Apr 2010 11:21:51 +0000 Promethe http://blog.promethe.net/?p=715

"3.3.1 … Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited)."

This is the very bad (sad) addition (restriction) to the iPhone developers program everyone is talking about right now. And I feel very concerned about this... and now everyone is wondering if software like the Flash-to-iPhone packager, Mono or Unity are definitely banned from the iPhone programming tool-chain.

I never talked about it before, but Aerys is working on a project targeting the iPhone and the iPad (among a lot of other platforms). And this very project is leveraged by some home-made code generation tool. Therefore, we are very scared of what this kind of restrictions might imply for our business.

But as scary as this statement might look at first, it is actually even funnier when you understand it makes any iPhone/iPad application illegal. And it gets even better because even Apple's standard tool-chain finds itself... prohibited!

The reason is very simple: Objective-C, C or C++ never "link" to any library providing the Documented iPhone APIs. Objective-C, C or C++ actually never link to anything. When compiling your code, the compiler creates an intermediary representation of your program in order to make it easier to (eventually cross-)compile it. In the case of GCC, the compiler used to build such applications, those intermediary languages are:

• the historical Register Transfer Language (RTL)
• the tree language GENERIC
• the SSA-based GIMPLE

(Source: Wikipedia - Intermediate language)

This very intermediate representation is built before the symbols resolution and before any linking is done. Thus, linking against the "Documented APIs" has always been done "through an intermediary translation or compatibility layer". And it won't change anytime soon! But, still, I wish good luck to Apple's engineers in their future work to patch GCC and make it "compliant" (sic!).

To me, it is the most obvious sign that Apple doesn't care about its developers (but I was still pretty thrilled to eventually become one of them about a few days ago...). Not because it bannishes any interesting cross-compiling software venture. And not even because any iPhone/iPad developper who knows about other platforms openness and ease of production will feel sick just by reading this kind of restrictions.

No. To me, Apple is losing it all simply because this kind of idiocy can only be written by someone who doesn't have a clue about how a computer/compiler works! Apple started building casual devices and ends up targeting casual developers. Could this be the first sign of how (so called) intuitiveness - when enforced by completely hermeticly closed devices - finally makes people... dumber? So now the real question is "What happens when your developers program EULA is written by a marketing control-freak moron?".

PS : The title of this article was desgined to attract the eye. It is my interpretation of the latest Apple's developers program EULA additions and I might be completely off or wrong. Anyway, the doubt and worry caused by this very fuzzy and unclear addition stands as a major issue for all the companies and developers targeting the iPhone and iPad platforms.

It was inspired by Mr. Doob's Stats class. But my Monitor class is entirely dynamic and you can watch any property of any object.

The following simple (and useless?) code sample show how to track the (x, y) position of the mouse cursor on the stage:

package
{
  import aerys.monitor.Monitor;
 
  import flash.display.Sprite;
 
  public class MonitorDemo extends Sprite
  {
    public function MonitorDemo()
    {
      var monitor : Monitor	= new Monitor(30);
 
      monitor.watch(stage, "mouseX", 0xff0000, 1. / stage.stageWidth);
      monitor.watch(stage, "mouseY", 0x008800, 1. / stage.stageHeight);
      addChild(monitor);
    }
  }
}

And here is the result:

Here is another simple use case: tracking the (x, y, z) rotation of a 3D camera (the actual application is available on the official Aerys website):

The code is open source and available on Google Code. Comments and suggestions would be greatly appreciated!

Rich of this new and incredible ability, Christophe Coenraets posted a small but yet very powerful code snippet to build an HTTP web server using AIR 2.0!

Optimization is always important. But when it comes to 3D for the Flash Platform, it's an everyday battle. The first ideas that come to mind are to avoid:

1. redrawing the same regions : each pixel value must be set once and only once
2. rendering invisible objects : objects that are out of sight still take a lot of CPU horsepower

While Flash takes care of the first one in its very renderer, the second one is not handled. But that is something we can easily address!

The Technic

The method is called "frustum culling". The big picture is that every mesh is approximated using a bounding volume (typically a sphere or a box). If the bounding volume is visible, the corresponding mesh is rendered. The two following pictures show the frustum culling caught in action:

The mesh is visible: TPS counter indicates 18900 triangles per seconds

The mesh is out of sight: frustum culling is acting and TPS counter indicates 0!

1. The frustum

First things first: before performing frustum culling, you need to build the frustum! The frustum is the 3D shape that contains everything the camera can see. It's made of 6 planes and looks like a truncated pyramid:

The view frustum

Each plane is defined by a plane equation: ax + by + cz + d, where (a, b, c) is the normal of the plane and d the distance on that normal. The 6 planes must be extracted from one of the Matrix3D object used to define the transform from one space to another (world to camera for example). Here are the 6 plane equations:

• left: (a = m14 + m11, b = m24 + m21, c = m34 + m31, d = m44 + m41)
• right: (a = m14 − m11, b = m24 − m21, c = m34 − m31, d = m44 − m41)
• bottom: (a = m14 + m12, b = m24 + m22, c = m34 + m32, d = m44 + m42)
• top: (a = m14 − m12, b = m24 − m22, c = m34 − m32, d = m44 − m42)
• near: (a = m13, b = m23, c = m33, d = m43)
• far: (a = m13, b = m23, c = m33, d = m43)

The source matrix you chose defines the coordinates systems of the extracted planes:

• the projection matrix provides planes in view (or camera) space
• the view * projection matrix provides planes in world space
• the world * view * projection matrix provides planes in object (or local) space

2. Bounding volumes

Testing every polygon against the frustum is a very expensive task. In order to speed things up, we will rather test a primitive shape that bounds the mesh: a "bounding volume". Common bounding volumes are spheres or boxes. I'll focus on the first one in the rest of the article.

A bounding sphere is pretty simple to implement: you just need to store the center of the sphere and it's radius. That being said, a BoundingSphere class would just contain the center as a Vector3D and the radius as a Number. When you have all the vertices of a mesh, building the bounding sphere is easy :

public function computeBoundingSphere(myVertices : Vector.<Number>) : BoundingSphere
{
	var min : Vector3D = new Vector3D(Number.MAX_VALUE, Number.MAX_VALUE, Number.MAX_VALUE);
	var max : Vector3D = new Vector3D(Number.MIN_VALUE, Number.MIN_VALUE, Number.MIN_VALUE);
	var length : int = myVertices.length;
	var center : Vector3D = null;
	var radius : Number = null;
 
	for (var i : uint = 0; i < length; i += 3)
	{
		min.x = myVertices [i] < min.x ? myVertices[i] : min.x;
		min.y = myVertices [uint(i + 1)] < min.y ? myVertices[int(i + 1)] : min.y;
		min.z = myVertices [uint(i + 2)] < min.z ? myVertices[int(i + 2)] : min.z;
 
 		max.x = myVertices [i] > max.x ? myVertices [i] : max.x;
		max.y = myVertices [uint(i + 1)] > max.y ? myVertices[int(i + 1)] : max.y;
		max.z = myVertices [uint(i + 2)] > max.z ? myVertices[int(i + 2)] : max.z;
	}
 
	center = new Vector3D((myMax.x + myMin.x) / 2.0, (myMax.y + myMin.y) / 2.0, (myMax.z + myMin.z) / 2.0);
        radius = Math.max(myMax.x - center.x, myMax.y - center.y, myMax.z - center.z,
		          center.x - myMin.x, center.y - myMin.y, center.z - myMin.z);	
 
	return new BoundingSphere(center, radius);
}

3. Point to plane distance

The plane equation (ax + by + cz + d) can be stored as a Vector3D object. Indeed, the Vector3D implements x, y and z but also a w Number attribute. This last one is supposed to store the homogenous coordinate. Nonetheless, we can use those 4 Number attributes to store the (a, b, c, d) values that defines our plane equation.

In order to test whether a bounding volume is inside or outside the frustum, we must be able to compute the distance of this object to the plane. To do so, we use the dot product of the point with the plane normal (which must be normalized first) :

public function planeToPointDistance(myPlane : Vector3D, myPoint : Vector3D) : Number
{
	return myPlane.x * myPoint.x + myPlane.y * myPoint.y + myPlane.z * myPoint.z + myPlane.w;
}

4. The test function

Now that our frustum and our bounding volumes are ready, we can add this little test function that checks whether an object is visible or not:

public function testBoundingSphere(myPlanes      : Vector.,
                                   mySphere      : BoundingSphere) : Boolean
{
	var length : int = myPlanes.length;
 
	for (var i : uint = 0; i < length; ++i)
	{
		var d 	: Number = planeToPointDistance(myPlanes[i]);
 
		// bouding sphere is out of the frustum
		if (d + mySphere.radius < 0.0)
			return false;
		// bounding sphere is spanning
		else if (d - mySphere.radius <= 0.0)
			return true;
	}
 
	// bounding sphere is inside the frustum
	return true;
}

The Experiment

The following experiment demonstrates frustum culling in action (click on the picture to open the application) :

Frustum culling experiment (use the arrow keys to move)

Use the arrow keys to move the robot across the scene. You can notice the TPS counter drops down to zero whenever the character is out of sight (on the near left or near right side of the screen). When the TPS indicates 0, no triangles are rendered and CPU usage drops down to 0%. It actually means that the rest of the rendering process has a minimal overhead!

And it's even more awesome...

This experiment also introduce my brand new mini-debugger inspired of Mr. Doob's work. I replaced the maximum memory footprint counter with a per-second rendered triangles counter (or TPS counter). CPU usage or framerate alone are not absolute measurements but the TPS counter reflects the true performance of the application the old fashioned way: the more polygons per second the better. I also updated the timer to display the processing time and the overall rendering time.

You can compare this experiment to the "old" one I made up a few weeks ago: the displayed 3D model features 30% more polygons but the CPU usage is the same.

The rendering process is done in such a way that absolutely no computation occurs on invisible objects, not even the slightest animation or z-sorting operation.

I enabled dynamic bounding volumes for animated meshes: if you place the mesh on the edges of the viewing space, you might notice that the TPS counter sometimes goes down to zero to raise up again to a few hundreds/thousands of triangles per second. The explanation is simple: the visibility test is done dynamically and follows the mesh animations. If the animation drives the mesh out of the viewing frustum, culling operates and it is not renderered.

But since the 15th of August 2009 AWS requires every request to be signed. It simply means that a "Signature" parameter must be added to each and every request. One might think that the API key should be enough, but this key is inserted in every query URL and can be read by pretty much anyone. The signature is created using the secret AWS password and crypted using the HMAC/SHA256 algorithms so that AWS can be sure the request actually comes from the genuine owner of the API key.

The documentation features a guide to explain the whole signing process step-by-step but as you might have guesses, there is a huge difference between reading it on the documentation and actually implementing it successfully.

Full code right after the jump...

The following class wrap the URLRequest class to provide signed requests to AWS (requires AS3CoreLib):

package com.amazon
{
	import com.adobe.crypto.HMAC;
	import com.adobe.crypto.SHA256;
 
	import flash.net.URLRequest;
	import flash.utils.ByteArray;
 
	import mx.formatters.DateFormatter;
	import mx.utils.Base64Encoder;
 
	public class AmazonRequest
	{
		public static const AWS_NAMESPACE	: Namespace	= new Namespace("http://webservices.amazon.com/AWSECommerceService/2009-01-06");
 
		private static const AWS_KEY		: String	= "your_aws_api_key_here";
		private static const AWS_SECRET 	: String	= "your_aws_secret_key_here";
		private static const AWS_METHOD		: String	= "GET";
		private static const AWS_HOST		: String	= "ecs.amazonaws.com";
		private static const AWS_PATH		: String	= "/onca/xml";
		private static const AWS_URL		: String	= "http://" + AWS_HOST + AWS_PATH;
 
		private var _URLRequest		: URLRequest	= new URLRequest();
		private var _DateFormatter	: DateFormatter	= new DateFormatter();
 
		public function get url() : String {return (_URLRequest.url);}
		public function get data() : Object {return (_URLRequest.data);}
		public function get requestHeaders() : Array {return (_URLRequest.requestHeaders);}
		public function get urlRequest() : URLRequest {return (signRequest());}
 
		public function set url(value : String) : void {_URLRequest.url = value;}
		public function set data(value : Object) : void {_URLRequest.data = value;}
		public function set requestHeader(value : Array) : void {_URLRequest.requestHeaders = value;}
 
		public function AmazonRequest()
		{
			_URLRequest.url = AWS_URL;
			_DateFormatter.formatString = "YYYY-MM-DDTJJ:NN:SS.000Z";
		}
 
		private function parametersSort(s1 : Object, s2 : Object) : Number
		{
			var c1 : Number = (s1.name as String).charCodeAt(0);
			var c2 : Number = (s2.name as String).charCodeAt(0);
 
			return (c1 > c2 ? 1.0 : -1.0);
		}
 
		private function signRequest() : URLRequest
		{
			var vars : Array = [];
			var signature : String = AWS_METHOD + "\n" + AWS_HOST + "\n" + AWS_PATH + "\n";
			var timestamp : String = null;
			var encoder	 : Base64Encoder = new Base64Encoder();
			var secretBytes : ByteArray = new ByteArray();
			var requestBytes : ByteArray = new ByteArray();
			var now : Date = new Date();
			var hash : String = null;
			var hashBytes : ByteArray = new ByteArray();
 
			// build the timestamp
			now.setTime(now.getTime() + (now.getTimezoneOffset() * 60 * 1000));
			timestamp = _DateFormatter.format(now);
 
			vars.push({name: "Timestamp", value: encodeURIComponent(decodeURIComponent(timestamp))});
 
			// add the API Key
			_URLRequest.data.AWSAccessKeyId = AWS_KEY;
 
			// extract and sort parameters
			for (var o : Object in _URLRequest.data)
				vars.push({name: o, value: _URLRequest.data[o]});
			vars = vars.sortOn("name");
 
			// build the string to sign
			for (var i : int = 0; i < vars.length; i++)
				signature += (i ? "&" : "") + encodeURIComponent(decodeURIComponent(vars[i].name))
							 + "=" + encodeURIComponent(decodeURIComponent(vars[i].value));
 
			// build the signature
			hash = HMAC.hash(AWS_SECRET, signature, SHA256);
			for (i = 0; i < hash.length; i += 2)
				hashBytes.writeByte(parseInt(hash.charAt(i) + hash.charAt(i + 1), 16));
 
			// encode the signature to Base64
			encoder.encodeBytes(hashBytes);
 
			// the the Signature and Timestamp parameters
			_URLRequest.data.Signature = encodeURI(encoder.toString());
			_URLRequest.data.Timestamp = timestamp;
 
			return (_URLRequest);
		}
 
	}
}

... and the following example function demonstrates how to use this class to actually query AWS to get album arts from a given album name:

public function getCovers(myAlbum : String) : void
{
	var request	: AmazonRequest = new AmazonRequest();
	var loader : URLLoader = new URLLoader();
	var vars : URLVariables = new URLVariables();
 
	vars.Service = 'AWSECommerceService';
	vars.Operation = 'ItemSearch';
	vars.Keywords = myAlbum;
	vars.Version = "2009-01-06";
	vars.SearchIndex = "Music";
	vars.ResponseGroup = "Images";
 
	request.data = vars;
 
	loader.addEventListener(Event.COMPLETE, requestCompleteHandler);
	loader.load(request.urlRequest);
}

And voila, I hope this will help!

My first post was about the 3D Flash library I'm currently working on : DirectFlex. As I said, it is not a simple 3D engine but a full 3D API like DirectX or OpenGL. As Flash 10 is likely to be available when the first public version of DirectFlex will be released, I decided to rewrite the API's core to take advantage of the new 3D mathematics classes and the hardware acceleration features. This is actually the third time that DirectFlex is entirely rewritten from scratch... but time after time the quality of the work and the performances have improved a lot.

DirectFlex and the good old Flash 9 ...

DirectFlex' developpement started more than a year ago and it was designed to be used in Flash 9. It's first "correct" rendering was a wireframe spinning cube. One year later, it's last Flash 9 version was able to draw up to 3 000 polygons at 20 frames per second.

Here is a screenshot of a flat-shaded 3D model loaded and displayed with DirectFlex. This mesh was actually extracted from Counter Strike 1.6 and is the 3D model of the GIGN skin. With 3000 polygons you can draw this very 3D mesh up to 7 times.

As you can see on the screenshot, the framerate is about 23 frames per second. It's not much, but it is enough to be perfectly smooth inside the Flash player. I could do some ActionScript magic to get a 30 frames per second framerate but that would require a lot more CPU. The most important thing is to get a smooth display without draining to much CPU, and that's exactly what we have here.

Here are two extra screenshots :

Please keep in my mind that those screenshots come from the "old" Flash 9 version of DirectFlex. A lot of changes have been made since. However, those screenshots are a good apetizer... and there is a lot more to come with the new Flash 10 version. As you might have understand, my main objective is to  make sure the "basic stuff" runs as fast as possible. Then some fancy effects will be added...

So what's new with Flash 10 (doctor) ?

Well the drawing API is a bit faster, and DirectFlex can now draw something like 5 000 polygons at 20 frames per second at least without any hardware acceleration. In fact, hardware acceleration in Flash 10 is still tricky and I didn't manage to enable it for now. Flash 10 is still in beta and is a work in progress. Performances are not stable yet and it is pretty hard to make a good guess about the final release capabilities.

Still, I've been running some tests and Flash 10  seams to be capable to compute up to 50 000 vertices. As you can make at least 16 000 polygons with those 50 000 vertices, it is indeed very frustrating to be able to draw "only" 5 000 of them in the end. Now that Flash 10 has a powerful 3D mathematics API, the drawing API seams to be the real bottleneck but I guess hardware acceleration will make it (a lot) faster.

In order to render complex 3D geometry, you'll have to use the underneath 3D API itself. This 3D API is mainly about three classes : Matrix3D, Vector3D and Utils3D. Those implements data types and methods to transform vertices data from a space to another in order to render actual 3D geometry on our very 2d flat screens. And... that's it. We also have the new "Graphics.drawTriangles" method and hardware acceleration, but all of this does not provide what we could call a user-friendly 3D API. But here comes...

DirectFlex is a "real" 3D API that uses the low level Flash 10 3D API to make it look and behave like any other 3D API such as DirectX or OpenGL. DirectFlex implementation and prototyping have actually a lot in common with Mirosoft's DirectX. A lot of concepts and programing techniques of DirectX can be found in DirectFlex. It means that most of the DirectX resources such as tutorials and samples will be relevant and will provide a lot of help to DirectFlex users.

The main difference between DirectFlex and any other third party 3D flash librairy is the simple fact that DirectFlex actually is a 3D API, and not some kind of a "fake" 3D engine. It means that you can work at the lowest level just like you would do it with DirectX or OpenGL : you have a total control on mathematics, algorithms and vertices/primitives data.

DirectFlex core takes care of most of the 3D rendering issues such as mathematics, z-sorting, mapping, and more. Although, because DirectX programming is not something any flash developer can handle, DirectFlex also includes a fully functional 3D engine and a 3D stage that mimics the behavior of the 2D stage of ActionScript 3.0.

Some demo applications, screenshots and a developers's blog will be released... "when it's done"