This posting is part 3 of a series. If you find that you’d rather start from the beginning, check out Part 1 and Part 2 first. In this post, I’ll cover Papervision animation, the ASCollada project, render statistics, performance optimization.
Animation in Papervision3D can be performed the exact same way animation would be performed in 2D. Simply apply any tween or algorithm to an object property (like x, y, rotationX, scaleY, etc) and re-render the scene. But, for imported animations its not quite that simple. Lately Moses’s GoASAP package is being adopted in testing for the Papervision engine. It could soon become adopted by the system.
The Collada DAE Parser
Imported animations come in plenty of flavors but must conform to the same system. That’s the reason the animations package exists. Papervision has long supported externally created 3D assets. You’ll find those file parsers in pv3d.objects.parsers. Although, these importers are nice to have, a big part of Great White was the introduction of the open source project ASCollada. ASCollada is an amazing parser for the standard 3D asset interchange format known as Collada. Collada files are basically very dense XML files that use a .dae file extension. Collada files can be exported from Maya, 3D Studio Max, Blender, Google Sketchup, and XSI. However, level of support for those programs probably follows this order: 3D Studio Max, Maya, Blender, Google Sketchup, XSI. Also, if you’re importing MD2 models, the MD2 file parser will import most animations as well.
You can try it out using the DAE class like so:
daeScene = new DAE();
var animChannel:AbstractChannel3D = daeScene.getAnimationChannels();
var frame:uint = 20;
var animObject:DisplayObject3D = animChannel.defaultTarget;
Papervision records all the primary rendering tasks. If you want to monitor rendering statistics, you can have them captured when you execute the BasicRenderEngine instance method “renderScene().” When traced, a typical render report will appear like this:
ProjectionTime:0 RenderTime:1 Particles:0 CulledParticles:0 Triangles:38 ShadedTriangles:0 CulledTriangles:82 FilteredObjects:0 CulledObjects:0
You can use this information to determine how well your scene is rendering. And it could give you ideas on how you can improve rendering by adjusting camera settings, culling plans, and clipping.
Great White has gained many huge performance advantages over previous versions of Papervision. One important advantage is that nearly all materials will render a surface to BitmapData. This is great because, as of Flash Player Update 3 (9.0.115, mid-2007) Multicore CPU support has been added to much of the BitmapData operations.
Clipping is a flag added to the Viewport3D constructor in Great White that will force the engine to perform clipping of all objects outside the the viewing rectangle (the viewport). This feature may seem obvious, but a lot of public engines neglect this.
Drawing is the most expensive process that Papervision performs. As such, there are a few different standard methods for removing items from the render queue in any 3D drawing API. This helps speed up render times by removing renderable triangles that would otherwise be drawn. Papervision3D performs backface culling, view frustum culling, and contribution culling but NOT occlusion culling. Occlusion culling is a huge process that is more built into accelerated APIs like OpenGL. Though it can be very difficult to perform well, it can also add extrordinary benefits to rendering performance.
Papervision3D supports interactive, animated, and smoothed MovieClip materials. However, those features come at a cost. You may already be aware that BitmapData smoothing (anti-aliasing) is slower than normal BitmapData rendering. Anti-aliasing algorithms are simply expensive operations and thats the bottom line. The other two features are performance hogs because they require that the Flash player to update the surface BitmapData object on each frame update –instead of reusing the original object that was derived from the MovieClip.
I’m currently coding lots of Flash player performance tests as they relate to Papervision. Right now I’m only using the following methods for testing: Math.sqrt(), Math.sin(), Matrix3D.multiply3x3(), and BitmapData.draw(). The test is simply a for loop that iterates 9999 times. It looks interesting and helps me make another point about PV3D performance. I’ll have to publish this application elsewhere, but for now here’s a sample of what I’m finding:
Figure A: Performance timetable for 4 operations in a for loop lasting 9999 iterations. BitmapDataObject1 is 40×40, transparent and BitmapDataObject2 is 600×600, transparent. They both draw a single purple circle.
As you can see bitmap drawing is the most expensive operation here. In almost every instance that I can think of, drawing will be the most performance intensive activity in any 3D rendering API. I could explain that here, but it would probably double the size of this post. ;)Â In a nutshell, it always helps to render only when you actually need to feature interaction and/or animation. Additionally, actively perform any reasonable operation to limit the number of objects in the scene. Again, the library does a lot for you there, but gains can always be made. Also, a little experience will show you that keeping the renderable area small will help also.