• FPS: is it possible to display Half Life 1 graphics in Flash ? I don't know yet... but this experiment is an improvement of the one I posted a while back
• Earth: I always wanted to implement the famous Google Earth in Flash. This might be a good first step! I made this experiment in approximately 1 hour to test out a few new features

Please let me know what you think about those new experiments. Any feedback will be greatly appreciated!

It's been a while since the last post. But I'm back and I decided to release the first DirectFlex demo ever

This demo is quite simple and features a 3D model extracted from the famous Half Life 1 add on Counter-Strike 1.6. The model is made of "only" 740 polygons, which is not much compared to what DirectFlex can do. Still, being able to display Half Life 1 models inside of Flash with a decent framerate brings hope for future developments. Anyway it is a good proof that DirectFlex is (way) faster than any other Flash 3D "engine" out there... but hey! live demo first and then technical stuff... (Flash 10 required!)

First Person Shooter Camera

This demo features one of the camera classes provided by DirectFlex: FPSCamera. This camera mimics the behavior of a any "classic" doom-like FPS game. Simple use the arrows/AWSD to walk forward/backward/strafe. You can also use the mouse to look around. Nothing fancy except the camera class itself which is really lightweight and easy to overload: I actually created a GhostCamera class based on the FPSCamera class by just adding 2 lines of code... All the camera classes are based on the same AbstractCamera class which makes it possible and really easy to switch from one camera type to another in real time in your application. I will release another demo to show how simple the code actually is.

3DS Loader

A good opportunity to show the 3DS loader in action. Loading and parsing are obviously really fast. The 3DS file is embed inside the SWF file which of course makes it even faster. The 3DS loader was built using this documentation.

Texture Mapping

The texture I used is the original one. I just resized it to make the final SWF file lighter. Nothing crazy about it except that it looks perfectly fine without cutting down the framerate.

Embed Assets

The texture and the 3D model files are embed inside the final SWF file. The mesh and texture class provided by DirectFlex can load such embed assets natively. It is very useful when you just want to redistribute your application without taking care of deploying the assets on a web server and dealing with security issues.

Real Time Lighting

As you can see, the back of the model is completely black. It does not mean that the texture is actually black Each polygon is skinned then lighted using a "fake" Phong algorithm. It is a very first draw and a lot of thinking has to be done to make it actually user friendly. Still, because the light and the model are not moving the "real time" part is not really obvious here... I'll try to make it more fancy in the next demo.

About performances

The framerate counter indicates 20-25 frames per second. The application does not force the framerate so the Flash Player runs it at the default framerate (which is supposed to be 24 frames per second). Then, a 20 to 25 frames per second framerate is actually as smooth as it is supposed to be It runs perfectly on my Atom 1.6Ghz processor so I guess any decent computer should run it without any performance issue of any kind.

Known issues

The mouse is not handled properly and its sensitivity will depend on the framerate of the application. If your framerate is to high, looking around might be tricky. I know how to fix that but I'm just to lazy to do it for this first demo

Z-sorting is not (yet) functional and some glitches might appear. I chose the 3D model carefully so that no major visual defects would occur.

Clipping and frustrum culling are not fully implemented. Major artifacts might appear when the model is rendered is the "back" of the camera.

What's next ?

A MD5 (Doom 3 models) loader is on its way and I will certainly try to load Half Life 2 models too. I am currently working with Alchemy v0.5a to build a fast C++ implementation of BSP trees to implement an efficient and reliable z-sorting algorithm. I will definitely post about Alchemy and my whole C/C++ to AS3 work. I will also release a very cool heightmap demo soon, with some source code to show how user friendly DirectFlex actually is. Other cool demos will follow... Finally, the official DirectFlex blog will be launched soon!

Do not hesitate to post any ideas and comments about how smooth the demo runs on your computer for example.

DirectFlex new features and Wii 3D models rendering

The new Flash 10 version of DirectFlex comes with a lot of new features such as:

• New architecture
• Improved performances
• Texture coordinates support
• 3DS files support
• Embed assets (textures and 3D models) support
• Pre-made camera classes

A good example of those new features is the fact that DirectFlex is now able to load and display Nintendo Wii 3D models. To make this new experiment I downloaded "Zelda : Twillight Princess" 3D models. Those models have been ripped from the original Wii game and are easily available on google. Because a picture is worth a thousand words, here are a few screenhots:

Those screenshots are the very first of the Flash 10 flavor of DirectFlex. I chose to render a Goron, a legendary creature of the Zelda universe. But I can hear you wondering : "Why ?! Why a *&*%#@ goron ?! We want Link!". Well the reason is very simple: the 3DS loader and the optimizations I added are still quite experimental and a few bugs remain when I load Link's 3DS model... Too bad! But I am sure I will come up with a solution soon!

But it is not that easy...

The main problem with those Wii ripped models is not the number of primitives itself but the fact that they are not really real-time rendering friendly: they are subdivided in a lot of subsets.  Therefor, they are easier to edit and to manipulate inside a 3D editor such as 3DS Max. The problem is that each of those subsets have to be rendered one after the other and at each frame. Thus, a lot a function calls occur which causes a huge framerate breakdown. A good solution would be to merge all subsets to get only one giant mesh. But usually, each subset must be rendered with a specific material/texture so you can not just blindly merge all subsets together. Hopefully, I managed to implement a bunch of new features that makes it possible and very functional!

This is still experimental but is defenitely worth exploring. I will release a live SWF demo as soon as camera controls will be more efficient.

The Vertex class

3D graphics is about drawing shapes in a 3D space. To describe those shapes, we use vertices. Considering a triangle, each corner is a vertex and will be represented by a Vertex object. Therefore, Vertex objects are basically a set of 3D coordinates that stands for the actual position of the Vertex in a 3D space. Vertex objects also contain other data such as texture coordinates, a color and a normal but we won't complicate things any further for the moment. The following code sample creates a Vertex:

// create a vertex in (x = 42, y = 23, z = 11)
var v : Vertex = new Vertex(42, 23, 11);

The VertexBuffer class

VertexBuffer objects are arrays of Vertex objects. Their implementation is actually quite more complicated because they have some internal optimizations. Still, VertexBuffer objects allow you to create a 3D shape using Vertex objects. Considering that a shape is made of triangles, the corresponding VertexBuffer object will contain multiple Vertex objects where each set of 3 Vertex is a triangle.

Lets take a cube for example. The cube has 6 faces, but each face is a square. As we can draw only triangles, each face will be made of 2 triangles. Our cube is made of 6 x 2 = 12 triangles and each triangle needs 3 vertices to be fully described. In the end, the VertexBuffer of a cube will contain 12 * 3 = 36 Vertex. Each set of 3 vertices describing the triangle to draw. The following code sample create a cube's VertexBuffer:

// create a cube VertexBuffer
var cube = new VertexBuffer(new Vertex(0.5, -0.5, 0.5), new Vertex(0.5, -0.5, -0.5), new Vertex(-0.5, -0.5, -0.5),
                            new Vertex(0.5, -0.5, 0.5), new Vertex(-0.5, -0.5, -0.5), new Vertex(-0.5, -0.5, 0.5),
                            new Vertex(-0.5, 0.5, -0.5), new Vertex(0.5, 0.5, -0.5), new Vertex(0.5, 0.5, 0.5),
                            new Vertex(-0.5, 0.5, 0.5), new Vertex(-0.5, 0.5, -0.5), new Vertex(0.5, 0.5, 0.5),
                            new Vertex(-0.5, -0.5, 0.5), new Vertex(0.5, -0.5, 0.5), new Vertex(-0.5, -0.5, 0.5),
                            new Vertex(-0.5, -0.5, 0.5), new Vertex(-0.5, 0.5, 0.5), new Vertex(0.5, 0.5, 0.5),
                            new Vertex(-0.5, 0.5, -0.5), new Vertex(-0.5, 0.5, 0.5), new Vertex(-0.5, -0.5, 0.5),
                            new Vertex(-0.5, -0.5, 0.5), new Vertex(-0.5, -0.5, -0.5), new Vertex(-0.5, 0.5, -0.5),
                            new Vertex(-0.5, -0.5, -0.5), new Vertex(0.5, -0.5, -0.5), new Vertex(-0.5, 0.5, -0.5),
                            new Vertex(-0.5, 0.5, -0.5), new Vertex(0.5, -0.5, -0.5), new Vertex(0.5, 0.5, -0.5),
                            new Vertex(0.5, 0.5, 0.5), new Vertex(0.5, -0.5, -0.5), new Vertex(0.5, -0.5, 0.5),
                            new Vertex(0.5, -0.5, -0.5), new Vertex(0.5, 0.5, 0.5), new Vertex(0.5, 0.5, -0.5));

The IndexBuffer class

With the previous example, it is quite obvious that a VertexBuffer alone is not the best way to describe 3D geometry. When you look at a cube, the most intuitive idea is that it is actually made of 8 vertices, not 36 ! Considering the resulting VertexBuffer, it is easy to see that vertices are created more than once with the exact same values because of the '3 vertices per triangle' logic. That is why IndexBuffer are handy : instead of describing the drawing order and the geometry in the same (Vertex) buffer, we separate them into a VertexBuffer (the geometry) and an IndexBuffer (the drawing order). Thus, an IndexBuffer is just an array of integers where each value references a cell of the VertexBuffer to describe how each Vertex has to be used. Our cube can then be represented as following :

// create the cube's VertexBuffer
var vb = new VertexBuffer(new Vertex(0.5, -0.5, 0.5),
                          new Vertex(0.5, -0.5, -0.5),
                          new Vertex(-0.5, -0.5, -0.5),
                          new Vertex(-0.5, -0.5, 0.5),
                          new Vertex(0.5, 0.5, 0.5),
                          new Vertex(0.5, 0.5, -0.5),
                          new Vertex(-0.5, 0.5, -0.5),
                          new Vertex(-0.5, 0.5, 0.5));
// create the cube's IndexBuffer
var ib = new IndexBuffer(0, 1, 2, 0, 2, 3,
                         6, 5, 4, 7, 6, 4,
                         4, 0, 3, 3, 7, 4,
                         6, 7, 3, 3, 2, 6,
                         2, 1, 6, 6, 1, 5,
                         4, 1, 0, 1, 4, 5);

The Device class

In DirectX, the Device (also called "context device") is an object that abtracts the graphics hardware. When you want to draw vertices, you give them to the Device and it uses its current configuration to render them. In DirectFlex, the Device class implements the Facade design pattern and is designed to abstract the whole "core" layer. The good thing is that the Device is a major abstraction feature : what is happening to the data stays hidden inside the core layer. If we rewrite the entire core layer, nothing will have to be changed inside the API layer! A Device object is created for each 3D display. The Device can be used in order to :

• set transformations (world, view, projection)
• set materials (color fills, textures)
• draw primitives (VertexBuffer)
• draw indexed primitives (VertexBuffer + IndexBuffer)
• render the scene

It is quite obvious that anything you will try to display will have to interact with the Device... Lets take our favorite cube : it's time to draw it !

// create a device and render the cube's VertexBuffer
var device : Device = new Device(canvas);
 
// draw the VertexBuffer using the VertexBuffer : the first argument describe what kind of primitives 
// we are drawing
device.drawIndexedPrimitives(PrimitiveType.TRIANGLE_LIST, vb, ib);

The first argument of the Device constructor is a Canvas object. This object will be used by DirectFlex to know "where" and "how" it has to draw. This is what you get in the end (I added a transformation to show it's a real cube):

This screenshot was made using the new Flash 10 version of DirectFlex ! This is why it looks that crappy : lights and a lot of stuff are not handled yet.

What's next ?
Next time I will introduce 3D transformations (such as translation, rotation and scaling) and materials.

The Link 3D model was extracted from the Nintendo 64 "Zelda : Ocarina of Time" rom then converted into 3DS format and finally converted into DirectFlex 3D models file format (3DS files support is still a work in progress). The DirectFlex library I used here is still the old Flash 9 compatible one.

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"