Jay Austin

I’ve been playing around with the Flash 10 3D API a lot lately and it’s time to break down the pros and cons using some of the stuff I’ve learned. The current implementation lacks a lot of features that you’d normally get for free with libraries like DirectX and OpenGL but hopefully Adobe will keep making improvements with future versions.

Lets talk specifics…

3D into 2D
When you’re using a traditional 3D renderer you build a 3D scene (a.k.a. a list of vertices that exist across an x, y, z coordinate system), set up a viewport, add a few lights and then pass those lists off to the “draw” function. That function looks at the scene through the viewport you defined and calculates how your set of 3D coordinates should be mapped on to a 2D surface (your screen). In Flash, the drawTriangles() function needs the 2D coordinates up front so it’s up to you to do the 3D to 2D conversion. On the bright side the Utils3D class has a handy projectVectors() function to handle most of the grunt work but being forced to keep track of the separate 2D and 3D coordinate lists is a hassle.

Z-Sorting
The trend of passing tedious calculations off to the user continues when you start drawing polygons that overlap when viewed through your given perspective. The “Z” depth (the distance between your camera and the objects in the scene) should determine which polygons (or pieces of polygons) are visible at any given time. In simpler terms, the polygons closest to the screen should be drawn last to ensure that they’re completely visible. Z-sorting is something you usually get for free but drawTriangles() only draws its list of shapes in the order you send it which means the list needs to get sorted before you start drawing. For my projects I maintain a list of all faces in the scene (Vector3Ds) and sort on “w” attribute.  The reasons for this limitation are rooted in the whole 3D to 2D problem and a solution could be rolled into either a more unified draw call or at a minimum a better Utils3D.projectVectors() function.

Here is a short example of the sortOn(“w”) method.

Camera Location
Perhaps the most annoying quirk that I’ve encountered with the new 3D system is the position of the camera in the Debug Flash Player vs. the Standalone Player vs. viewing a .swf in a browser. For some reasons,  matrix transforms on the camera behave differently depending on which Flash player you’re using. This might sound nuts (and it is) but if you move the camera back by ~500 units in the debugger then you’re going to have to move it back ~6500 units for the standalone player to have the same perspective. The fact that Adobe let this problem slip through is a little disconcerting.

If you want to see an example of this phenomenon, check this demo in your browser and then compile the code with the Flash IDE.

Culling
Culling is a mixed back. It’s one of the few features in the API that Adobe implemented really well except for one very fatal flaw. Normally culling is used to only draw one side of a polygon which saves on cycles on the CPU (or GPU). After doing a few quick experiments Flash doesn’t experience a performance hit for “Culling On” vs “Culling Off,” leading me to believe culling is automatic and triangle faces out of view are not drawn. The only time you’ll even need culling  active is when you one side of your triangles to be transparent.

Sadly, the automatic culling doesn’t extend behind the camera so everything in the scene better have a positive Z (relative to the camera) or else. Shapes sitting behind the viewport will cause the Flash Player to lose its mind and start drawing garbage across the screen. This is especially annoying when the standalone Flash player  screws up camera translation and zooms in to the middle of the scene.

Transparency
Transparent shapes are usually a source of headaches. If you cull “unseen” shapes from the scene making some shapes transparent will  break basic hidden surface detection. It also complicates lighting, shadow casting and shading. drawTriangles() handles hidden surfaces, and by “handles” I mean  it draws everything but at least transparency works correctly.

Shaders
The fact that you can use PixelBender to program shaders for Flash is pretty dang cool. The fact that a shader can only be applied statically once per draw call is pretty dang stupid. Let me explain what I mean; normally a shader (vertex, pixel, etc) gets data about each triangle that the renderer is currently drawing. Using that data the shader can perform the necessary calculations to figure out things like lighting and texturing. In Flash you can only feed data to the shader  prior to the draw call and while the call is being executed the shader doesn’t know “which” triangle it’s working on, just that it’s working on a triangle. So, if you want dynamic lighting there only a few ways to get around this limitation (and neither of them are pretty).

One solution is to compute all the shading information prior to calling draw and storing in one giant bitmap. When you’re ready to draw just add in an extra list of UV coordinates and you’re good to go. The drawback is the fact that the resulting bitmap will be huge (assuming you have a large number of faces). The other solution is to call drawTriangles() once per triangle and pass new information to the shader between each call. It’s highly inefficient and it defeats the purpose of a single draw call but it gets the shading done.

Hardware Acceleration
The biggest downfall of the current system is the complete lack of hardware acceleration. GPUs are optimized to draw triangles and yet drawTriangles() operates entirely on the CPU. As a result you can only draw an extremely low and very disappointing number of triangles at any time. My amateur benchmarking (calling draw once per triangle and using a PixelBender shader to calculate N.L lighting) maxed out around ~2000 triangles before the framerate dropped to 1.

So, Flash 10’s 3D is cool but its not going to really take off until they fix some of these problems.