I’m starting to cook up a few game ideas with some friends of mine and I wanted to get a sense of what Away3D could really do.  To start, I made this very basic example of Away3D loading a fairly high poly 3DS file with minimal animation.  More specifically, it’s a rotating, 2880 poly, torus knot with a wire frame material.  While Away3D isn’t really made to handle models with this many polys, it gives me an idea of how it will handle a total polycount of about 3000.

Featured Away3D code: Max3DS.load() and WireColorMaterial

Click the image above to access the example.  You can right click on the example and click “view source” to,  you guessed it, view the source.

Originally this project was the main page for savagelook.com, but I decided it to shuffle to “projects” on my blog.  While it is was a very cool showcase of the things I had learned so far using Away3D, Flint particles, FLARToolkit, FLARManager, TweenMax & TimelineMax, its not really practical for a main interface… yet.  Here’s the things I learned in this initial undertaking that I plan to apply to all future projects involving Away3D(Lite), particularly when the average user is the target audience:

• Performance ALWAYS has to be on your mind.  There’s nothing more annoying to users than low frame rates.  Many of my next points relate directly to this.
• Use Renderer.BASIC as your view’s renderer whenever feasible.  You will take an immediate performance hit trying to use the smarter z-sorting renderers (CORRECT_Z_ORDER or INTERSECTING_OBJECTS)
• Control the size of the view.  While a resizeable view that fills the browser seem great, you can take a nasty performance hit on high resolutions.  For example, this project runs like a champ with a standard 800×600 or 1024×768 resolution.  When I jump it up to  1680×1050, though, things start to get a little choppy.
• 3D particles are a whore on resources.  Fake 3D effects with 2D whenever possible.  You can literally get 100x (or more) particles in 2D and maintain the same frame rate as 3D.
• Use simultaneous tweens judiciously.  There were noticeable slow downs in my intro animations when more than one tween was operating at a time.
• Learn your z-sorting and plan it from the beginning.  I can’t tell you how much time I wasted restructuring my scene and code because I didn’t take the time to learn Frustum clipping, ownCanvas, pushback, pushfront, and screenZoffset before starting.
• Interactivity and camera motion impacts performance. Static scenes will allow for far more polys at a good frame rate than dynamic ones.  Keeping the camera static or using mouseEnabled = false on your objects may help.
• Users expect 2D dialogs and text. Use them whenever feasible to convey information to the user.
• Make sure you clean up your unused objects.  ”scene.removeChild(obj)” and “obj = null” should become your best friend.
• Reuse objects and materials whenever possible.  Its a lot easier and less expensive to toggle the visibility of a relatively simple object rather than destroy and recreate it every time.
• Only render when you need to.  When I use 2D layout for the “Bio” section, I stop rendering the covered 3D scene to help performance.
• Use texture baking or similar techniques to fake lighting.  Real-time lighting, while cool, chews up a lot of resources.  If it isn’t critical, fake it.
• Materials with alphas process slower.
• When all else fails, hit the . It may not have the fastest responses, but there’s no better place to get help and guidance.

I’m sure there’s lots more I picked up in the process, but that’s a pretty good assessment.  Hopefully this helps anyone getting started on their own Away3D projects.

I don’t have any specific plans to make version 2.0 of the savagelook.com 3D interface, but I’ve got a few ideas rolling around in my head.  The key factors will be simplicity, speed, more pseudo-3D effects using 2D, and use of Away3DLite.  I’m hoping to really represent Away3D next time.